Комментарии 19
Как тут не вспомнить «общую шину» :) www.ashmanov.com/pap/bubble#p4.9.2
НЛО прилетело и опубликовало эту надпись здесь
Не так все однозначно. Если платформа применяется к узкому кругу задач, а не позиционируется как универсальная, то плюсы от ее применения перевешивают минусы. Другими словами, на платформе 1С можно эффективно решать учетные задачи, но не нужно писать сайты и порталы, писать драйверы устройств и т.д.
Могу предложить такую альтернативу: создайте универсальную базу исходного кода. Но вместо того, чтобы наследовать и использовать ее в каждом новом проекте (что приведет к межпроектной зависимости), просто каждый раз делайте ее форк. В таком случае у Вас будет надежная стартовая точка, но при этом Вы свободно вносите изменения, не беспокоясь о том, как они отразятся на других проектах компании.
Если перенести это на ООП получается вы говорите не пользуйтесь наследованием, делайте копипасту )
Форк я думаю все же позволит «мерджить» удачные изменения, в случае, если они ВСЕ ЖЕ ПОТРЕБУЮТСЯ в каком-то другом проекте.
А так…
Ну я попытаюсь перенести на ООП, то что пытался донести автор.
У нас есть волшебный класс TObject, который управляет деревом детей, сигналами/слотами и, например, логированием (понимаю что странно).
Он используется в двух проектах и все замечательно. Потом компания стартует третий проект с использованием этого же класса, который является веб-сервисом. И для поддержки RPC, класс TObject модифицируется. Сигналы-слоты теперь работают немного по-другому. Прогон тестов не выявил регрессий, но спустя месяцы от клиентов первых двух проектов приходят баги, на которые уходят уйма времени.
А так…
Ну я попытаюсь перенести на ООП, то что пытался донести автор.
У нас есть волшебный класс TObject, который управляет деревом детей, сигналами/слотами и, например, логированием (понимаю что странно).
Он используется в двух проектах и все замечательно. Потом компания стартует третий проект с использованием этого же класса, который является веб-сервисом. И для поддержки RPC, класс TObject модифицируется. Сигналы-слоты теперь работают немного по-другому. Прогон тестов не выявил регрессий, но спустя месяцы от клиентов первых двух проектов приходят баги, на которые уходят уйма времени.
А может просто надо в проектную документацию фреймворка включить некоторые принципы расширяемость и ограничения вида «данный фреймворк НЕ РЕШАЕТ задачу вида бла-бла. Эту часть делайте сами»?
По-моему, суть данной статьи сводится к утверждению:
«Если взять трех крутых чуваков и задать им написать универсальный крутой фреймворк, они потратят кучу времени, выдав продукт, из которого потом кучаобезьян простых разработчиков сделают дрянь, модифицируя его в стиле „кто во что горазд“
И это, конечно, бывает, но выводы в статье феерические:
1. Не пишите крутые фреймворка (потому что их вам испортят эти… другие девелоперы)
2. Крутые фреймворка — зло!
А может быть решение другое? Может быть стоит нормально проектировать фреймворк и не позволять в него вносить изменения, которые сломают основные принципы его функционирования?
По-моему, суть данной статьи сводится к утверждению:
«Если взять трех крутых чуваков и задать им написать универсальный крутой фреймворк, они потратят кучу времени, выдав продукт, из которого потом куча
И это, конечно, бывает, но выводы в статье феерические:
1. Не пишите крутые фреймворка (потому что их вам испортят эти… другие девелоперы)
2. Крутые фреймворка — зло!
А может быть решение другое? Может быть стоит нормально проектировать фреймворк и не позволять в него вносить изменения, которые сломают основные принципы его функционирования?
Я в этом и не согласен с автором и согласен с Вами. Так что ничего добавить не могу)
> А может просто надо в проектную документацию фреймворка включить некоторые принципы расширяемость и ограничения вида «данный фреймворк НЕ РЕШАЕТ задачу вида бла-бла. Эту часть делайте сами»?
То, в лучшем случае, ваш фреймворк прикрутят только для логирования, вынуждая новоприбывших учить его весь.
А в худшем… Вы всё равно не напишите список задачу он НЕ решает, и будет «да у нас почти тоже самое, надо только чуть-чуть допилить»…
> не позволять в него вносить изменения, которые сломают основные принципы его функционирования?
И он в принципе будет не нужен никому, кроме изначальных заказчиков, да и то только первые 3 года. Жизнь не статичная. У вас под каждый проект(если вы не 10 сайтов в неделю лабаете, конечно) будет свой фреймворк, только без копипасты.
Форк — это способ повторного использования кода с низкой связностью. Минусы тут следствие плюсов, баг исправленный в одной копии не чиниться в другой. Но для старого, отлаженного в бою, кода это не так страшно.
То, в лучшем случае, ваш фреймворк прикрутят только для логирования, вынуждая новоприбывших учить его весь.
А в худшем… Вы всё равно не напишите список задачу он НЕ решает, и будет «да у нас почти тоже самое, надо только чуть-чуть допилить»…
> не позволять в него вносить изменения, которые сломают основные принципы его функционирования?
И он в принципе будет не нужен никому, кроме изначальных заказчиков, да и то только первые 3 года. Жизнь не статичная. У вас под каждый проект(если вы не 10 сайтов в неделю лабаете, конечно) будет свой фреймворк, только без копипасты.
Форк — это способ повторного использования кода с низкой связностью. Минусы тут следствие плюсов, баг исправленный в одной копии не чиниться в другой. Но для старого, отлаженного в бою, кода это не так страшно.
И он в принципе будет не нужен никому, кроме изначальных заказчиков, да и то только первые 3 года
Если некая библиотека не может быть использована повторно в аналогичном проекте или расширена без модификации основного кода для включения дополнительных возможностей, значит она плохо спроектирована.
Большие фреймворки должны писать люди, которые способны их писать. Те, у кого не хватает на это способностей, не должны мнить себя гениями.
> Если некая библиотека не может быть использована повторно в аналогичном проекте
Конечно может. Аналогичного проекта не найдёте.
> или расширена без модификации основного кода
Это, кстати, весьма дорогое требование. Впрочем, расширяема она будет всё равно не там, где надо за любые деньги. Водопад — он и есть водопад.
> Большие фреймворки должны писать люди, которые способны их писать. Те, у кого не хватает на это способностей, не должны мнить себя гениями.
Сразу хочется спросить, достаточная ли у вас «способностей» для столь категоричных заявлений? Чем докажете?
Конечно может. Аналогичного проекта не найдёте.
> или расширена без модификации основного кода
Это, кстати, весьма дорогое требование. Впрочем, расширяема она будет всё равно не там, где надо за любые деньги. Водопад — он и есть водопад.
> Большие фреймворки должны писать люди, которые способны их писать. Те, у кого не хватает на это способностей, не должны мнить себя гениями.
Сразу хочется спросить, достаточная ли у вас «способностей» для столь категоричных заявлений? Чем докажете?
Чем докажете?
А кто вам сказал, что лично я претендую на подобное звание? А даже если претендую, с чего вы взяли, что я считаю себя уже достойным его?
Я отношусь с огромным уважением к людям, способным проектировать сложные системы правильно. Стремлюсь у них учиться с тем, чтобы однажды, если удастся, встать рядом с ними. Пока у меня это получается с очень переменным успехом — я стараюсь объективно оцениватьсвои результаты.
Но для того, чтобы утверждать, что «фундаментальное программирование» — удел далеко не каждого кодера, не обязательно быть Никлаусом Виртом. И не всякий, кто говорит «немногим дано» считает себя одним из тех, кому «дано». Вы меня неверно поняли.
> И не всякий, кто говорит «немногим дано» считает себя одним из тех, кому «дано». Вы меня неверно поняли.
Это вы меня неверно поняли. Я спросил какие у вас способности утверждать «немногим дано» и можете ли вы это доказать.
Резать правду-матку в интернетах — удел далеко не каждого.
Это вы меня неверно поняли. Я спросил какие у вас способности утверждать «немногим дано» и можете ли вы это доказать.
Резать правду-матку в интернетах — удел далеко не каждого.
создайте универсальную базу исходного кода
Сразу вспомнился Яндекс со своим универсальным БЭМ-набором блоков на все проекты.
Общий код (а лучше общие проекты сборок .NET с полезными автономными классами, компонентами ) — это правильно. Они должны быть максимально автономными, чтобы крайне нечасто хотелось там что-то править или улучшать. Но если «форк» — кроме защиты от того что «в них ничего не сломали» вы получаете еще и эффект «ошибки живут вечно, пока вы не смержите их исправление».
А вот если один из проектов требует нечто такое, что уже «не лезет» на платформу, то вероятно, это тот случай, когда от платформы именно на этом проекте нужно отказаться.
Юнит-тесты спасут, но у кого есть желание-время-деньги их писать?
А вот если один из проектов требует нечто такое, что уже «не лезет» на платформу, то вероятно, это тот случай, когда от платформы именно на этом проекте нужно отказаться.
Юнит-тесты спасут, но у кого есть желание-время-деньги их писать?
Вторая проблема – это интересный феномен, который я назвал «Синдром крутого разработчика» («Smart Guy Disease»). Я встречался с ним много раз в разных компаниях. Заключается он в том, что самые фатальные ошибки, которые наносят наибольший ущерб компании, почему-то всегда делаются самыми лучшими ее разработчиками, а не посредственными.
Какое удивительное по своей тривиальности наблюдение! А чего вообще мог ожидать автор? Того, что серьезный судьбоносный просчет в архитектуре будет допущен нанятым вчера интерном? Почему специалист-разработчик не понимает, что наиболее серьезные ошибки всегда делают люди, на которых возложена наиболее серьезная ответственность?
Я всегда восхищался статьями вида «X — зло!», потому что их ценность обычно ровно такая же, как у статей «Делайте всё с помощью X». Но почему-то если вторые в сообществе считаются демонстрацией недальновидности автора, то первые активно тиражируются и всерьез обсуждаются.
Мы живем в мире, когда «всё уже написано». Если вы хотите использовать язык программирования C++, то для него есть stl и boost. Что? boost — зло? А может, вы его готовить не умеете? Или, скажем, библиотека (фреймворк) GLEW, которая грузит OpenGL и позволяет с ним взаимодействовать. Она универсальная. Зло? Или может ее заново переписать?
Всё в реальности определяется спектром задач и дизайном фреймворка. И если дизайн плохой, то результат будет плачевный. Также результат будет плачевный если взять инструмент и попытаться с его помощью решать не предусмотренную автором задачу. Я вслед за известным русским мыслителем называю это «проблемой мартышки и очков». Так что главное зло — люди, которые не умеют пользоваться вещами, а не те, кто эти вещи создает.
В некотором смысле универсальную платформу можно сравнить с языком программирования. Всем понятно, что язык должен проектироваться исходя из каких-то глобальных принципов и не поддаваться на провокации отдельных проектов, реализованных на нём. Тут, конечно, всё дело во внутреннем стержне менеджеров или архитекторов универсальной платформы и их прозорливости. Ведь одним из важных принципов является принцип — сохранения обратной совместимости. Даже если надо исправить ошибку в платформе, но если это исправление приведёт к вот этому эффекту у пользователей платформы:
в один прекрасный день Вы в своем проекте обновляете версию платформы до последней и обнаруживаете, что весь проект сломанТут надо трижды подумать что делать с этой ошибкой — быть может есть другой вариант решения, а сломать всё — последнее дело. Ещё один полезный принцип — открытость интерфейсов платформы. Если пользователю не подходит что-то из платформы — пусть напишет сам (возможно, хуже, но своё которое ему понятно как устроено).
Спасибо за комментарии! Тема довольно дискуссионная. Как переводчик, я не могу сказать, что разделяю всю оригинальную риторику автора, но в целом, критика именно «универсальных супер-платформ» обоснованная. Во всем должна быть мера, сами по себе платформы — не являются злом, но если они создаются, они не должны становится слишком универсальными и глобальными.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Универсальные платформы это зло