Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.

Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
Объясню. Лезешь разбираться с проектом. Мама дорогая. Простая задачка, на пару-тройку методов по 20-50 строк в одном классе, выполняющая одну логическую(с человеческой точки зрения) операцию. Заботливо разбита по 50 методам в 30 классах, каждый снабжен набором сеттеров и геттеров, кучей сервисных методов по 1 строке с обвеской аннотациями для поддержки всего ниже, интерфейсом, фабрикой, инициализация всех размазана по 1 строчке в самых неожиданных местах(что даже Идея не может выяснить все из них — так же круче!), конфигурация этого всего превращена в мегамонстра, и доступна через свой механизм размером со слона. Это все в обвязке еще сотни классов непонятного без пару литров водки назначения. Акторы, визиторы, и прочие шаблоны в самых непредсказуемых местах. Расширяемо типа до невозможности. Только, во-первых, нихрена не в тех направлениях, где реально понадобилось(т.е. все эти архитектурные зарубы не пригодились) — менять приходится совершенно другое, так как предсказалочка у таких писателей никакая. Во-вторых, исправить сотню багов проще, чем разобраться в этом месиве.
Такое ощещение, что некоторые панически боятся использовать "new"(только инициализация по черти-откуда взятому объекту класса рефлексией, только хардкор!) и прямые вызовы методов — только интерфейсы или рефлексия, только фасады и переброска сообщений!

Зато красиво. Шаблоны. Методы по 2 строки. Новые технологии. Только найти строчку кода, которая что-то делает, а не обслуживает какое-то очередное трендовое решение — дикая головная боль. Выяснить, где какие-то значимые логические операции, а где просто куски — хрен там. Документация — ага, щас, писателям сего некогда — слишком мало классов!!!!111

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

Здравствуйте, Eugeny__, Вы писали:

E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?

http://en.wikipedia.org/wiki/You_aren't_gonna_need_it

Здравствуйте, Eugeny__, Вы писали:

E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
Ответ ниже:

E__>Зато красиво.
У всех свои ценности. Такие монстры, как ты описал, появляются тогда, когда техническое совершенство ставится над более скучными вещами, такими как требования бизнеса, сопровождаемость, UX и т.п. Большинство разработчиков — законченные техноэгоцентристы, отсюда и такой перекос в сторону переусложненности в ущерб всему остальному.

Здравствуйте, Eugeny__, Вы писали:

E__> Заботливо разбита по 50 методам в 30 классах

<flame>
ООП не нужно
</flame>

Здравствуйте, Eugeny__, Вы писали:

E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?

Угу, overdesign, классическая болезнь начинающего архитектора в чистом виде.

Универсальных рецептов как удержать баланс между простотой поддержки и возможностью развития проекта нет, всё решает в основном опыт.
Опыт (особенно из разряда "как делать НЕ НАДО") приобретается, увы, только запоротым проектом, да и то при наличии здоровой самокритики.

Если у архитектора ещё нет собственоручно собранного сада камней поля граблей, то обычно всё начинается с попытки перетащить в проектирование те же приёмы, что и при написании кода и заканчивается вечной "проблемой мангустов в почтовом ящике":

	...
	— Слушайте, я могу все объяснить, — сказал Мойст. Лорд Ветинари поднял бровь с озабоченностью человека, который, найдя гусеницу в салате, осторожно приподнимает остальные листики. — Прошу вас, — сказал он, откидываясь на спинку кресла. — Нас слегка занесло, — начал Мойст. — Проявили слишком уж креативное мышление. Развели мангустов в почтовых ящиках, чтобы змеи держались подальше… Лорд Ветинари ничего не сказал. — Э… Которых, стоит признать, мы затащили в ящики, чтобы снизить количество лягушек… Лорд Ветинари повторил свой ответ. — Э, которых, по правде, служащие засунули, чтобы отвадить улиток… Лорд Ветинари оставался безмолвным. — Э… Которые, я вынужден отметить, сами заползли в ящики сожрать клей с марок, — закончил Мойст, опасаясь, что он скатывается в несвязное бормотание. — Ну, по крайней мере, их вам не пришлось никуда засовывать, — весело заметил Ветинари. (c) Пратчетт, Делай деньги.

На практике это выглядит примерно так:
Однотипные проблемы? Пишем хелпер фреймворк. Проблемы с использованием фреймворка?
1. пишем метафреймворк,
2. если уже написан:
2.1. возвращаемся к п.1, только на этот раз всё будет ок.
2.2. на неудобные вопросы (а как собственно с этим работать???) цитируем Фаулера, Бека, или Эванса (по вкусу). Как правило в этот момент люди сами всё понимают и матерясь уходят писать анти-хелперы. Которые в теории должны анигилировать фреймворк, на практике только увеличивают общую энтропию

Впрочем, другая крайность aka "фигак-фигак и в продакшн" ничем не лучше, только последствия всплывают сильно позже. В худшем случае — после релиза.


E__>Объясню. Лезешь разбираться с проектом. Мама дорогая. Простая задачка, на пару-тройку методов по 20-50 строк в одном классе, выполняющая одну логическую(с человеческой точки зрения) операцию.
А тут возможны два варианта:
1. Всё действительно так, как вы сказали. Лечится просто — договариваемся с тимлидом о времени на тестирование после ваших исправдений, пишем тесты, заменяем реализацию, закрывем дело.
2. (наиболее вероятный):

	img

Здравствуйте, Eugeny__, Вы писали:

E__>Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.

E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?

Потому что регулярно общаемся с тимлидами-прожектменеджерами-заказчиками, ревьюим бэклог и неплохо представляем себе задачи, которые возникнут через несколько спринтов. Ваш К.О.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Eugeny__, Вы писали:

E__>>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?

S>Угу, overdesign, классическая болезнь начинающего архитектора в чистом виде.

S>Универсальных рецептов как удержать баланс между простотой поддержки и возможностью развития проекта нет, всё решает в основном опыт.
S>Опыт (особенно из разряда "как делать НЕ НАДО") приобретается, увы, только запоротым проектом, да и то при наличии здоровой самокритики.

Видел много запоротых проектов в разных областях, все они похожи:
1) Несмотря на тонны написанного кода нечего показать. То что есть выглядит как УГ, работает также.
2) В беклоге куча багов и фич, причем фичи имеют приоритет над багами.
3) Деплоймент проекта это АД. Для выкатывания релиз-версии нужны танцы с бубном.
4) В проекте очень много бессмысленных "ритуалов": обязательное покрытие тестами, обязательные паттерны, обязательное ревью "самого главного архитектора", обязательные совещания раз неделю, на которых ничего не решается итп

Здравствуйте, Eugeny__, Вы писали:

E__>Объясню. Лезешь разбираться с проектом. Мама дорогая. Простая задачка, на пару-тройку методов по 20-50 строк в одном классе, выполняющая одну логическую(с человеческой точки зрения) операцию. Заботливо разбита по 50 методам в 30 классах, каждый снабжен набором сеттеров и геттеров, кучей сервисных методов по 1 строке .....

На Java поди пишешь?

Здравствуйте, Eugeny__, Вы писали:

E__>Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.

E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?

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

И отдельный момент — высокие ЗП. Нахрена изучать чтото еще, если ЗП и так большая ?

Отсюда и растет Future-coding — люди оторваные от реальности, вместо решения конкретных проблем пилят непойми что по непойми каким принципам — "что бы было красиво и правильно"

Здравствуйте, Eugeny__, Вы писали:

E__>Зато красиво. Шаблоны. Методы по 2 строки. Новые технологии. Только найти строчку кода, которая что-то делает, а не обслуживает какое-то очередное трендовое решение — дикая головная боль. Выяснить, где какие-то значимые логические операции, а где просто куски — хрен там. Документация — ага, щас, писателям сего некогда — слишком мало классов!!!!111

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

Здравствуйте, Eugeny__, Вы писали:

E__>Зато красиво. Шаблоны. Методы по 2 строки.
E__>... Но когда я вижу очередной высер такого плана, мне хочется убивать. Жаль, некого

+1000.
Но убивать есть кого — банду старых пердунов GoF.

Проблема overengineering — классическая "болезнь среднего уровня", когда ты вроде уже не кодер на поBUGушках, но ещё не поумнел для оптимальных решений — ты осознаёшь, что знаешь мало, но выбираешь совсем не тот путь развития. Ошибку легко совершить, учитывая обилие штопаных архитекторов со своими паттернами и тестами, коотрые не могут написать калькулятор без сотни классов. В таких случаях я просто говорю: "этот очень умный код пусть дописывает тот, кто его придумал — я буду переписывать с нуля".

Здравствуйте, andyag, Вы писали:

E__>>Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.

E__>>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?

A>Потому что регулярно общаемся с тимлидами-прожектменеджерами-заказчиками, ревьюим бэклог и неплохо представляем себе задачи, которые возникнут через несколько спринтов. Ваш К.О.

У вас тимлиды-прожектменеджеры и прочие знают все наперед? Да они счастливые люди, получившие бесконечный счастливый билет в этой жизни! У нас вообще никто никогда не знает ничего наперед, даже глава всей огромной конторы, которая заведует, по сути, всем перемещением медийной продукции по миру(кроме СНГ, туда не лезут, ибо смысла нет, а геморроя полная жопа).

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, andyag, Вы писали:

E__>>>Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.

E__>>>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?

A>>Потому что регулярно общаемся с тимлидами-прожектменеджерами-заказчиками, ревьюим бэклог и неплохо представляем себе задачи, которые возникнут через несколько спринтов. Ваш К.О.

E__>У вас тимлиды-прожектменеджеры и прочие знают все наперед? Да они счастливые люди, получившие бесконечный счастливый билет в этой жизни! У нас вообще никто никогда не знает ничего наперед, даже глава всей огромной конторы, которая заведует, по сути, всем перемещением медийной продукции по миру(кроме СНГ, туда не лезут, ибо смысла нет, а геморроя полная жопа).

Во-первых это зависит от стадии, в которой находится проект. Если проект начинается и архитектура сразу накрученная, это говорит о том, что когда-то где-то прозвучал диалог типа такого например:

— Нам надо чтобы все апдейты в UI были в реальном времени. А ещё нам надо демку инвесторам показать через месяц. Там нужны фичи А, Б и Х.
— А реалтаймные апдейты в UI тоже к демке нужны?
— Не, их можно потом.

В этой точке "архитектор" знает, куда оно всё катится и если возникает мысль, что какой то аспект запилить прямо вот сразу, чтобы потом не было мучительно больше, он так и сделает. В результате когда придут "программисты", первым делом обвинят его в оверинжиниринге. Им никто не запрещает общаться с заказчиком, бэклог от них никто не прячет, все новости озвучиваются в явном. А им просто пофигу обычно. Если бы было не пофигу, сами были бы архитекторами. Но нет, чаще всего они играют в игру "убеди QA, что фича работает".

Во-вторых нужно разделять "планирование" и "понимание направления". Для того, чтобы уместно накрутить архитектуру достаточно знать направление. Сегодня у нас есть только сайт, но заказчик говорит, что к концу года хотелось бы ещё мобильных клиентов в первом приближении. Программисту Васе по барабану — он позиционирует себя как "Senior Java Back End Developer", ему плевать на всех этих винфонов, андроидов и айфонов, он не относит это к тому, о чём ему стоит знать. Поэтому введение service layer и запрет писать бизнес логику в контроллерах приводит к нытью на тему "архитектора фаулер покусал".

В-третьих есть ещё особенности субъективного восприятия хорошей архитектуры. Кто-то любит в классах делать по 20 приватных методов и думает, что это нормально. Кто-то в аналогичной ситуации сделает 20 классов, где эти методы будут паблик. В принципе один хрен: если повыкидывать "декорации", код один и тот же, но в первом случае "смотрите — всего 1 класс, как всё просто", а во-втором "смотрите — фабрика фабрик адаптеров арифметических выражений шаблонного калькулятора". С другой стороны, авторы решения "номер 1" как правило спустя какое-то время раздувают свой "один простой класс" до размеров в несколько KLOC и начинают рассказывать, что код вдруг стал легаси. А вот у авторов решения "номер 2" с ходом времени ничего не меняется: они как клепали объекты и связи между ними, так и клепают.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Eugeny__, Вы писали:

E__>>Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.

E__>>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?

I>Это мне кажется аутсорс начинает переваривать сам себя:

I>- Вместо инженерного подхода ценится его отсутствие.

Как правило, ценится навык ловли баланса между "сделать фичу вчера" и "чтобы не развалилось завтра".

I>- Вместо проектирования используются паттерны

Паттерны не используются, их часто просто не знают. Знают на уровне сказать пару слов про синглтон (пара слов это типа "наше всё"), но как только доходит до практики, лучше б их всё-таки GoF покусал.

I>- Вместо управления рисками в ходу всевозможные баззворды
I>Для аутсорсной конторы такое очень выгодно. Ценятся не те специалисты, которые могут и делают, а те, кто в состоянии запудрить мозг заказчику.

Ценятся сбалансированные участники, которым одинаково не наплевать на "продукт", "ожидания" и "код". Если даже у человека скилл "код" прокачан до over 9000, это крайне бестолковый "участник", т.к. самостоятельно он работать не сможет — нужен будет кто-то, чтобы рекламировать его "код" и направлять таким образом, чтобы "код" превращался в продукт.

I>И отдельный момент — высокие ЗП. Нахрена изучать чтото еще, если ЗП и так большая ?

Не знаю, сколько это — "большая", но если человек сам себя ограничивает "я делаю только вот это, а больше мне ничего не интересно", он сам себе определяет потолок — как профессионально, так и зарплатно.

I>Отсюда и растет Future-coding — люди оторваные от реальности, вместо решения конкретных проблем пилят непойми что по непойми каким принципам — "что бы было красиво и правильно"

Чаще всё-таки встречается наоборот: "Архитектура приложения у нас будет MVC" и понеслась.

Здравствуйте, btn1, Вы писали:

B>Проблема overengineering — классическая "болезнь среднего уровня", когда ты вроде уже не кодер на поBUGушках, но ещё не поумнел для оптимальных решений — ты осознаёшь, что знаешь мало, но выбираешь совсем не тот путь развития. Ошибку легко совершить, учитывая обилие штопаных архитекторов со своими паттернами и тестами, коотрые не могут написать калькулятор без сотни классов. В таких случаях я просто говорю: "этот очень умный код пусть дописывает тот, кто его придумал — я буду переписывать с нуля".

Супер подход. Дальше приходит прозрение, что вы тратите свою жизнь на фигню и пора сменить работу, дальше приходит ещё один "умник", который падает в обморок от вашего кода и предлагает переписать. Не потому что код плохой, а просто потому что ОН-то уж точно знает как надо правильно

Рефакторинг — это основа SD. Переписать с нуля может любой Вася с улицы. Адекватный программист при работе с легаси кодом избегает революций и постепенно доводит запущенные места до хорошего состояния. При написании кода (построении архитектуры) с нуля действуют абсолютно те же самые принципы. С первого раза всегда неправильно, но второй раз должен быть не переписыванием с нуля, а серией мелких переделок.

Здравствуйте, andyag, Вы писали:

I>>Это мне кажется аутсорс начинает переваривать сам себя:
I>>- Вместо инженерного подхода ценится его отсутствие.

A>Как правило, ценится навык ловли баланса между "сделать фичу вчера" и "чтобы не развалилось завтра".

В аутсорсе ? Смешно, контора сдала проект, получила бабло а дальше хоть трава не расти. 80-90% контор работают именно так.

A>Ценятся сбалансированные участники, которым одинаково не наплевать на "продукт", "ожидания" и "код". Если даже у человека скилл "код" прокачан до over 9000, это крайне бестолковый "участник", т.к. самостоятельно он работать не сможет — нужен будет кто-то, чтобы рекламировать его "код" и направлять таким образом, чтобы "код" превращался в продукт.

Ценятся, но не в аутсорсе.

I>>Отсюда и растет Future-coding — люди оторваные от реальности, вместо решения конкретных проблем пилят непойми что по непойми каким принципам — "что бы было красиво и правильно"

A>Чаще всё-таки встречается наоборот: "Архитектура приложения у нас будет MVC" и понеслась.

Это одно и то же.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, andyag, Вы писали:

I>>>Это мне кажется аутсорс начинает переваривать сам себя:
I>>>- Вместо инженерного подхода ценится его отсутствие.

A>>Как правило, ценится навык ловли баланса между "сделать фичу вчера" и "чтобы не развалилось завтра".

I>В аутсорсе ? Смешно, контора сдала проект, получила бабло а дальше хоть трава не расти. 80-90% контор работают именно так.

То что вы описываете — это скорее про фрилансеров-одиночек: "надо сделать мобильный клиент с двумя кнопками". Очень часто аутсорсят не "изготовление артефакта", а "команду девелоперов", которая существует "бесконечно" и стабильно делает, доделывает и переделывает в зависимости от изменяющихся хотелок клиента и его инвесторов. Длиться это может от года и больше. По моей статистике таких проектов (в плане человекочасов) большинство. Бывают всякие на 3 недели с фиксированным бюджетом, их может быть много количественно, но по суммарным человекочасам они точно не на первом месте.

A>>Ценятся сбалансированные участники, которым одинаково не наплевать на "продукт", "ожидания" и "код". Если даже у человека скилл "код" прокачан до over 9000, это крайне бестолковый "участник", т.к. самостоятельно он работать не сможет — нужен будет кто-то, чтобы рекламировать его "код" и направлять таким образом, чтобы "код" превращался в продукт.

I>Ценятся, но не в аутсорсе.

Вы неудачно поработали в каком-то аутсорсе?

I>>>Отсюда и растет Future-coding — люди оторваные от реальности, вместо решения конкретных проблем пилят непойми что по непойми каким принципам — "что бы было красиво и правильно"

A>>Чаще всё-таки встречается наоборот: "Архитектура приложения у нас будет MVC" и понеслась.

I>Это одно и то же.

С точки зрения выхлопа — одно и то же. С точки зрения перспектив у "покусанного Фаулером" больше шансов научиться делать по-человечески.

Здравствуйте, MTD, Вы писали:

MTD>Здравствуйте, Eugeny__, Вы писали:

E__>>Объясню. Лезешь разбираться с проектом. Мама дорогая. Простая задачка, на пару-тройку методов по 20-50 строк в одном классе, выполняющая одну логическую(с человеческой точки зрения) операцию. Заботливо разбита по 50 методам в 30 классах, каждый снабжен набором сеттеров и геттеров, кучей сервисных методов по 1 строке .....

MTD>На Java поди пишешь?

А в этих ваших сиплюсплюсах уже научились делать всякие встроенные HTTP-серверы, сериализацию в 2 строчки, или может хотя бы общепринятую систему управления зависимостями? Или быстрое перекладывание байтов вместе с вычислением факториала на этапе компиляции — это по прежнему единственное, где плюсы бьют какой-нибудь PHP?

Здравствуйте, Eugeny__, Вы писали:

E__>Объясню. Лезешь разбираться с проектом. Мама дорогая. Простая задачка, на пару-тройку методов по 20-50 строк в одном классе, выполняющая одну логическую(с человеческой точки зрения) операцию. Заботливо разбита по 50 методам в 30 классах

Это java головного мозга. Тоже такое встречал (из свежего — SableCC, то что у меня оформлено единственным статическим методом — там полтора десятка классов, бойлерплейта больше чем осмысленного кода). Отчасти объясняется отсутствием до недавнего времени лямбд, отчасти дурными традициями в комьюнити.

Здравствуйте, andyag, Вы писали:

A>То что вы описываете — это скорее про фрилансеров-одиночек: "надо сделать мобильный клиент с двумя кнопками".

Я фрилансеров не видел. Рассказываю о том, чего наблюдал со стороны.

>Очень часто аутсорсят не "изготовление артефакта", а "команду девелоперов", которая существует "бесконечно" и

Часто но не большинство.

I>>Ценятся, но не в аутсорсе.

A>Вы неудачно поработали в каком-то аутсорсе?

А я где то пишу, что это про те проекты, где я работал ? Прекращай додумывать.