Универсальные платформы это зло

[Alex_At_Net]

Как тут не вспомнить «общую шину» :) www.ashmanov.com/pap/bubble#p4.9.2

[an24]

Не так все однозначно. Если платформа применяется к узкому кругу задач, а не позиционируется как универсальная, то плюсы от ее применения перевешивают минусы. Другими словами, на платформе 1С можно эффективно решать учетные задачи, но не нужно писать сайты и порталы, писать драйверы устройств и т.д.

[dmitry_hidden]

Могу предложить такую альтернативу: создайте универсальную базу исходного кода. Но вместо того, чтобы наследовать и использовать ее в каждом новом проекте (что приведет к межпроектной зависимости), просто каждый раз делайте ее форк. В таком случае у Вас будет надежная стартовая точка, но при этом Вы свободно вносите изменения, не беспокоясь о том, как они отразятся на других проектах компании.

Если перенести это на ООП получается вы говорите не пользуйтесь наследованием, делайте копипасту )

[mapron]

Форк я думаю все же позволит «мерджить» удачные изменения, в случае, если они ВСЕ ЖЕ ПОТРЕБУЮТСЯ в каком-то другом проекте.
А так…

Ну я попытаюсь перенести на ООП, то что пытался донести автор.
У нас есть волшебный класс TObject, который управляет деревом детей, сигналами/слотами и, например, логированием (понимаю что странно).
Он используется в двух проектах и все замечательно. Потом компания стартует третий проект с использованием этого же класса, который является веб-сервисом. И для поддержки RPC, класс TObject модифицируется. Сигналы-слоты теперь работают немного по-другому. Прогон тестов не выявил регрессий, но спустя месяцы от клиентов первых двух проектов приходят баги, на которые уходят уйма времени.

[bigfatbrowncat]

А может просто надо в проектную документацию фреймворка включить некоторые принципы расширяемость и ограничения вида «данный фреймворк НЕ РЕШАЕТ задачу вида бла-бла. Эту часть делайте сами»?

По-моему, суть данной статьи сводится к утверждению:
«Если взять трех крутых чуваков и задать им написать универсальный крутой фреймворк, они потратят кучу времени, выдав продукт, из которого потом куча обезьян простых разработчиков сделают дрянь, модифицируя его в стиле „кто во что горазд“

И это, конечно, бывает, но выводы в статье феерические:
1. Не пишите крутые фреймворка (потому что их вам испортят эти… другие девелоперы)
2. Крутые фреймворка — зло!

А может быть решение другое? Может быть стоит нормально проектировать фреймворк и не позволять в него вносить изменения, которые сломают основные принципы его функционирования?

[mapron]

Я в этом и не согласен с автором и согласен с Вами. Так что ничего добавить не могу)

[areht]

> А может просто надо в проектную документацию фреймворка включить некоторые принципы расширяемость и ограничения вида «данный фреймворк НЕ РЕШАЕТ задачу вида бла-бла. Эту часть делайте сами»?

То, в лучшем случае, ваш фреймворк прикрутят только для логирования, вынуждая новоприбывших учить его весь.
А в худшем… Вы всё равно не напишите список задачу он НЕ решает, и будет «да у нас почти тоже самое, надо только чуть-чуть допилить»…

> не позволять в него вносить изменения, которые сломают основные принципы его функционирования?

И он в принципе будет не нужен никому, кроме изначальных заказчиков, да и то только первые 3 года. Жизнь не статичная. У вас под каждый проект(если вы не 10 сайтов в неделю лабаете, конечно) будет свой фреймворк, только без копипасты.

Форк — это способ повторного использования кода с низкой связностью. Минусы тут следствие плюсов, баг исправленный в одной копии не чиниться в другой. Но для старого, отлаженного в бою, кода это не так страшно.

[bigfatbrowncat]

И он в принципе будет не нужен никому, кроме изначальных заказчиков, да и то только первые 3 года

Если некая библиотека не может быть использована повторно в аналогичном проекте или расширена без модификации основного кода для включения дополнительных возможностей, значит она плохо спроектирована.

Большие фреймворки должны писать люди, которые способны их писать. Те, у кого не хватает на это способностей, не должны мнить себя гениями.

[areht]

> Если некая библиотека не может быть использована повторно в аналогичном проекте

Конечно может. Аналогичного проекта не найдёте.

> или расширена без модификации основного кода

Это, кстати, весьма дорогое требование. Впрочем, расширяема она будет всё равно не там, где надо за любые деньги. Водопад — он и есть водопад.

> Большие фреймворки должны писать люди, которые способны их писать. Те, у кого не хватает на это способностей, не должны мнить себя гениями.

Сразу хочется спросить, достаточная ли у вас «способностей» для столь категоричных заявлений? Чем докажете?

[bigfatbrowncat]

Чем докажете?

А кто вам сказал, что лично я претендую на подобное звание? А даже если претендую, с чего вы взяли, что я считаю себя уже достойным его?

Я отношусь с огромным уважением к людям, способным проектировать сложные системы правильно. Стремлюсь у них учиться с тем, чтобы однажды, если удастся, встать рядом с ними. Пока у меня это получается с очень переменным успехом — я стараюсь объективно оцениватьсвои результаты.

Но для того, чтобы утверждать, что «фундаментальное программирование» — удел далеко не каждого кодера, не обязательно быть Никлаусом Виртом. И не всякий, кто говорит «немногим дано» считает себя одним из тех, кому «дано». Вы меня неверно поняли.

[areht]

> И не всякий, кто говорит «немногим дано» считает себя одним из тех, кому «дано». Вы меня неверно поняли.

Это вы меня неверно поняли. Я спросил какие у вас способности утверждать «немногим дано» и можете ли вы это доказать.
Резать правду-матку в интернетах — удел далеко не каждого.

[bigfatbrowncat]

Вы всерьез полагаете, что утверждение «не всякому человеку дано создавать шедевры» нуждается в доказательстве?

Либо вы слишком оптимист, либо странно шутите.

*Ушел рисовать Джоконду и параллельно доказывать, что P=NP*

[areht]

Ну если вы тукую простую вещь доказать не можете — что кто-то способен фреймворк создать вы тем более не докажете.

[Ohar]

создайте универсальную базу исходного кода

Сразу вспомнился Яндекс со своим универсальным БЭМ-набором блоков на все проекты.

[darthandrew]

Общий код (а лучше общие проекты сборок .NET с полезными автономными классами, компонентами ) — это правильно. Они должны быть максимально автономными, чтобы крайне нечасто хотелось там что-то править или улучшать. Но если «форк» — кроме защиты от того что «в них ничего не сломали» вы получаете еще и эффект «ошибки живут вечно, пока вы не смержите их исправление».

А вот если один из проектов требует нечто такое, что уже «не лезет» на платформу, то вероятно, это тот случай, когда от платформы именно на этом проекте нужно отказаться.

Юнит-тесты спасут, но у кого есть желание-время-деньги их писать?

[bigfatbrowncat]

Вторая проблема – это интересный феномен, который я назвал «Синдром крутого разработчика» («Smart Guy Disease»). Я встречался с ним много раз в разных компаниях. Заключается он в том, что самые фатальные ошибки, которые наносят наибольший ущерб компании, почему-то всегда делаются самыми лучшими ее разработчиками, а не посредственными.

Какое удивительное по своей тривиальности наблюдение! А чего вообще мог ожидать автор? Того, что серьезный судьбоносный просчет в архитектуре будет допущен нанятым вчера интерном? Почему специалист-разработчик не понимает, что наиболее серьезные ошибки всегда делают люди, на которых возложена наиболее серьезная ответственность?

Я всегда восхищался статьями вида «X — зло!», потому что их ценность обычно ровно такая же, как у статей «Делайте всё с помощью X». Но почему-то если вторые в сообществе считаются демонстрацией недальновидности автора, то первые активно тиражируются и всерьез обсуждаются.

Мы живем в мире, когда «всё уже написано». Если вы хотите использовать язык программирования C++, то для него есть stl и boost. Что? boost — зло? А может, вы его готовить не умеете? Или, скажем, библиотека (фреймворк) GLEW, которая грузит OpenGL и позволяет с ним взаимодействовать. Она универсальная. Зло? Или может ее заново переписать?

Всё в реальности определяется спектром задач и дизайном фреймворка. И если дизайн плохой, то результат будет плачевный. Также результат будет плачевный если взять инструмент и попытаться с его помощью решать не предусмотренную автором задачу. Я вслед за известным русским мыслителем называю это «проблемой мартышки и очков». Так что главное зло — люди, которые не умеют пользоваться вещами, а не те, кто эти вещи создает.

[bratchikov]

В некотором смысле универсальную платформу можно сравнить с языком программирования. Всем понятно, что язык должен проектироваться исходя из каких-то глобальных принципов и не поддаваться на провокации отдельных проектов, реализованных на нём. Тут, конечно, всё дело во внутреннем стержне менеджеров или архитекторов универсальной платформы и их прозорливости. Ведь одним из важных принципов является принцип — сохранения обратной совместимости. Даже если надо исправить ошибку в платформе, но если это исправление приведёт к вот этому эффекту у пользователей платформы:

в один прекрасный день Вы в своем проекте обновляете версию платформы до последней и обнаруживаете, что весь проект сломан

Тут надо трижды подумать что делать с этой ошибкой — быть может есть другой вариант решения, а сломать всё — последнее дело. Ещё один полезный принцип — открытость интерфейсов платформы. Если пользователю не подходит что-то из платформы — пусть напишет сам (возможно, хуже, но своё которое ему понятно как устроено).

[capslocky]

Спасибо за комментарии! Тема довольно дискуссионная. Как переводчик, я не могу сказать, что разделяю всю оригинальную риторику автора, но в целом, критика именно «универсальных супер-платформ» обоснованная. Во всем должна быть мера, сами по себе платформы — не являются злом, но если они создаются, они не должны становится слишком универсальными и глобальными.