Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.
Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
Объясню. Лезешь разбираться с проектом. Мама дорогая. Простая задачка, на пару-тройку методов по 20-50 строк в одном классе, выполняющая одну логическую(с человеческой точки зрения) операцию. Заботливо разбита по 50 методам в 30 классах, каждый снабжен набором сеттеров и геттеров, кучей сервисных методов по 1 строке с обвеской аннотациями для поддержки всего ниже, интерфейсом, фабрикой, инициализация всех размазана по 1 строчке в самых неожиданных местах(что даже Идея не может выяснить все из них — так же круче!), конфигурация этого всего превращена в мегамонстра, и доступна через свой механизм размером со слона. Это все в обвязке еще сотни классов непонятного без пару литров водки назначения. Акторы, визиторы, и прочие шаблоны в самых непредсказуемых местах. Расширяемо типа до невозможности. Только, во-первых, нихрена не в тех направлениях, где реально понадобилось(т.е. все эти архитектурные зарубы не пригодились) — менять приходится совершенно другое, так как предсказалочка у таких писателей никакая. Во-вторых, исправить сотню багов проще, чем разобраться в этом месиве.
Такое ощещение, что некоторые панически боятся использовать "new"(только инициализация по черти-откуда взятому объекту класса рефлексией, только хардкор!) и прямые вызовы методов — только интерфейсы или рефлексия, только фасады и переброска сообщений!
Зато красиво. Шаблоны. Методы по 2 строки. Новые технологии. Только найти строчку кода, которая что-то делает, а не обслуживает какое-то очередное трендовое решение — дикая головная боль. Выяснить, где какие-то значимые логические операции, а где просто куски — хрен там. Документация — ага, щас, писателям сего некогда — слишком мало классов!!!!111
Не, не везде так. Есть вполне понятные проекты. Но когда я вижу очередной высер такого плана, мне хочется убивать. Жаль, некого — по странной случайности авторы сего уже уволились.
13.06.14 11:47: Перенесено модератором из 'Компьютерные священные войны' — Odi$$ey
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
Ответ ниже:
E__>Зато красиво.
У всех свои ценности. Такие монстры, как ты описал, появляются тогда, когда техническое совершенство ставится над более скучными вещами, такими как требования бизнеса, сопровождаемость, UX и т.п. Большинство разработчиков — законченные техноэгоцентристы, отсюда и такой перекос в сторону переусложненности в ущерб всему остальному.
Здравствуйте, Eugeny__, Вы писали: E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
Угу, overdesign, классическая болезнь начинающего архитектора в чистом виде.
Универсальных рецептов как удержать баланс между простотой поддержки и возможностью развития проекта нет, всё решает в основном опыт.
Опыт (особенно из разряда "как делать НЕ НАДО") приобретается, увы, только запоротым проектом, да и то при наличии здоровой самокритики.
Если у архитектора ещё нет собственоручно собранного сада камней поля граблей, то обычно всё начинается с попытки перетащить в проектирование те же приёмы, что и при написании кода и заканчивается вечной "проблемой мангустов в почтовом ящике":
...
— Слушайте, я могу все объяснить, — сказал Мойст.
Лорд Ветинари поднял бровь с озабоченностью человека, который, найдя гусеницу в салате, осторожно приподнимает остальные листики.
— Прошу вас, — сказал он, откидываясь на спинку кресла.
— Нас слегка занесло, — начал Мойст. — Проявили слишком уж креативное мышление. Развели мангустов в почтовых ящиках, чтобы змеи держались подальше…
Лорд Ветинари ничего не сказал.
— Э… Которых, стоит признать, мы затащили в ящики, чтобы снизить количество лягушек…
Лорд Ветинари повторил свой ответ.
— Э, которых, по правде, служащие засунули, чтобы отвадить улиток…
Лорд Ветинари оставался безмолвным.
— Э… Которые, я вынужден отметить, сами заползли в ящики сожрать клей с марок, — закончил Мойст, опасаясь, что он скатывается в несвязное бормотание.
— Ну, по крайней мере, их вам не пришлось никуда засовывать, — весело заметил Ветинари.
(c) Пратчетт, Делай деньги.
На практике это выглядит примерно так:
Однотипные проблемы? Пишем хелпер фреймворк. Проблемы с использованием фреймворка?
1. пишем метафреймворк,
2. если уже написан:
2.1. возвращаемся к п.1, только на этот раз всё будет ок.
2.2. на неудобные вопросы (а как собственно с этим работать???) цитируем Фаулера, Бека, или Эванса (по вкусу). Как правило в этот момент люди сами всё понимают и матерясь уходят писать анти-хелперы. Которые в теории должны анигилировать фреймворк, на практике только увеличивают общую энтропию
Впрочем, другая крайность aka "фигак-фигак и в продакшн" ничем не лучше, только последствия всплывают сильно позже. В худшем случае — после релиза.
E__>Объясню. Лезешь разбираться с проектом. Мама дорогая. Простая задачка, на пару-тройку методов по 20-50 строк в одном классе, выполняющая одну логическую(с человеческой точки зрения) операцию.
А тут возможны два варианта:
1. Всё действительно так, как вы сказали. Лечится просто — договариваемся с тимлидом о времени на тестирование после ваших исправдений, пишем тесты, заменяем реализацию, закрывем дело.
2. (наиболее вероятный):
Здравствуйте, Eugeny__, Вы писали:
E__>Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.
E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
Потому что регулярно общаемся с тимлидами-прожектменеджерами-заказчиками, ревьюим бэклог и неплохо представляем себе задачи, которые возникнут через несколько спринтов. Ваш К.О.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Eugeny__, Вы писали:
E__>>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
S>Угу, overdesign, классическая болезнь начинающего архитектора в чистом виде.
S>Универсальных рецептов как удержать баланс между простотой поддержки и возможностью развития проекта нет, всё решает в основном опыт. S>Опыт (особенно из разряда "как делать НЕ НАДО") приобретается, увы, только запоротым проектом, да и то при наличии здоровой самокритики.
Видел много запоротых проектов в разных областях, все они похожи:
1) Несмотря на тонны написанного кода нечего показать. То что есть выглядит как УГ, работает также.
2) В беклоге куча багов и фич, причем фичи имеют приоритет над багами.
3) Деплоймент проекта это АД. Для выкатывания релиз-версии нужны танцы с бубном.
4) В проекте очень много бессмысленных "ритуалов": обязательное покрытие тестами, обязательные паттерны, обязательное ревью "самого главного архитектора", обязательные совещания раз неделю, на которых ничего не решается итп
Здравствуйте, Eugeny__, Вы писали:
E__>Объясню. Лезешь разбираться с проектом. Мама дорогая. Простая задачка, на пару-тройку методов по 20-50 строк в одном классе, выполняющая одну логическую(с человеческой точки зрения) операцию. Заботливо разбита по 50 методам в 30 классах, каждый снабжен набором сеттеров и геттеров, кучей сервисных методов по 1 строке .....
Здравствуйте, Eugeny__, Вы писали:
E__>Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.
E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
Это мне кажется аутсорс начинает переваривать сам себя:
— Вместо инженерного подхода ценится его отсутствие.
— Вместо проектирования используются паттерны
— Вместо управления рисками в ходу всевозможные баззворды
Для аутсорсной конторы такое очень выгодно. Ценятся не те специалисты, которые могут и делают, а те, кто в состоянии запудрить мозг заказчику.
И отдельный момент — высокие ЗП. Нахрена изучать чтото еще, если ЗП и так большая ?
Отсюда и растет Future-coding — люди оторваные от реальности, вместо решения конкретных проблем пилят непойми что по непойми каким принципам — "что бы было красиво и правильно"
Здравствуйте, Eugeny__, Вы писали:
E__>Зато красиво. Шаблоны. Методы по 2 строки. Новые технологии. Только найти строчку кода, которая что-то делает, а не обслуживает какое-то очередное трендовое решение — дикая головная боль. Выяснить, где какие-то значимые логические операции, а где просто куски — хрен там. Документация — ага, щас, писателям сего некогда — слишком мало классов!!!!111
Нет здесь ничего красивого. Красиво, это когда смотришь в код и тебе сходу понятны и детали, и абстракции и точки для расширения, и возможности оптимизации и код раз за разом своей работоспособностью вселяет уверенность.
Здравствуйте, Eugeny__, Вы писали:
E__>Зато красиво. Шаблоны. Методы по 2 строки. E__>... Но когда я вижу очередной высер такого плана, мне хочется убивать. Жаль, некого
+1000.
Но убивать есть кого — банду старых пердунов GoF.
Проблема overengineering — классическая "болезнь среднего уровня", когда ты вроде уже не кодер на поBUGушках, но ещё не поумнел для оптимальных решений — ты осознаёшь, что знаешь мало, но выбираешь совсем не тот путь развития. Ошибку легко совершить, учитывая обилие штопаных архитекторов со своими паттернами и тестами, коотрые не могут написать калькулятор без сотни классов. В таких случаях я просто говорю: "этот очень умный код пусть дописывает тот, кто его придумал — я буду переписывать с нуля".
Здравствуйте, andyag, Вы писали:
E__>>Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.
E__>>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
A>Потому что регулярно общаемся с тимлидами-прожектменеджерами-заказчиками, ревьюим бэклог и неплохо представляем себе задачи, которые возникнут через несколько спринтов. Ваш К.О.
У вас тимлиды-прожектменеджеры и прочие знают все наперед? Да они счастливые люди, получившие бесконечный счастливый билет в этой жизни! У нас вообще никто никогда не знает ничего наперед, даже глава всей огромной конторы, которая заведует, по сути, всем перемещением медийной продукции по миру(кроме СНГ, туда не лезут, ибо смысла нет, а геморроя полная жопа).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, 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>Вы неудачно поработали в каком-то аутсорсе?
А я где то пишу, что это про те проекты, где я работал ? Прекращай додумывать.
Здравствуйте, kleng, Вы писали:
K>Совершенство — это когда нечего выбросить. K>А это — техническое уродство.
В контексте этого разговора разница несущественна.
Здравствуйте, btn1, Вы писали:
B>Здравствуйте, Eugeny__, Вы писали:
E__>>Зато красиво. Шаблоны. Методы по 2 строки. E__>>... Но когда я вижу очередной высер такого плана, мне хочется убивать. Жаль, некого
B>+1000. B>Но убивать есть кого — банду старых пердунов GoF.
Неужели ГоФ виноват в том, что люди не хотят думать ?
B>Проблема overengineering — классическая "болезнь среднего уровня", когда ты вроде уже не кодер на поBUGушках, но ещё не поумнел для оптимальных решений — ты осознаёшь, что знаешь мало, но выбираешь совсем не тот путь развития. Ошибку легко совершить, учитывая обилие штопаных архитекторов со своими паттернами и тестами, коотрые не могут написать калькулятор без сотни классов. В таких случаях я просто говорю: "этот очень умный код пусть дописывает тот, кто его придумал — я буду переписывать с нуля".
Переписывается — это еще одна ошибка, есть более эффективный и пред сказуемым способ
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Eugeny__, Вы писали:
E__>>Объясню. Лезешь разбираться с проектом. Мама дорогая. Простая задачка, на пару-тройку методов по 20-50 строк в одном классе, выполняющая одну логическую(с человеческой точки зрения) операцию. Заботливо разбита по 50 методам в 30 классах
НС>Это java головного мозга. Тоже такое встречал (из свежего — SableCC, то что у меня оформлено единственным статическим методом — там полтора десятка классов, бойлерплейта больше чем осмысленного кода). Отчасти объясняется отсутствием до недавнего времени лямбд, отчасти дурными традициями в комьюнити.
Такое в любом языке в любой платформе выше крыши. В среднем четко коррелирует с количеством доступных тылов для рефакторинга и легкостью написания кода
Здравствуйте, btn1, Вы писали:
B>Но убивать есть кого — банду старых пердунов GoF.
Это всё равно что судить изобретателя молотка за отбитые при забивании гвоздя пальцы.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Такое в любом языке в любой платформе выше крыши.
НС>Но в джаве такое встречается почему то на порядок чаще.
Потому что в джаве легаси кода на порядок больше. Т.е. в дотнете код в среднем молодой, в джаве гораздо старше. И джава практически всегда это энтерпрайз, а вот дотнет это может быть все что угодно.
Здравствуйте, Ikemefula, Вы писали:
I>Это мне кажется аутсорс начинает переваривать сам себя: I>- Вместо инженерного подхода ценится его отсутствие. I>- Вместо проектирования используются паттерны I>- Вместо управления рисками в ходу всевозможные баззворды I>Для аутсорсной конторы такое очень выгодно. Ценятся не те специалисты, которые могут и делают, а те, кто в состоянии запудрить мозг заказчику.
Ну то есть, скоро аутсорс будет заниматься аутсорсингом, который в свою очередь...
Вот и приплыли. Недолго, кстати, плавали.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Ikemefula, Вы писали:
I>>Такое в любом языке в любой платформе выше крыши.
НС>Но в джаве такое встречается почему то на порядок чаще.
Ну, во-первых, ява постарше, а во-вторых, разработчиков на яве гораздо больше чем на том же
дотнете. Отсюда и столько фреймоврков и проч.
Здравствуйте, Sharov, Вы писали:
I>>Это мне кажется аутсорс начинает переваривать сам себя: I>>- Вместо инженерного подхода ценится его отсутствие. I>>- Вместо проектирования используются паттерны I>>- Вместо управления рисками в ходу всевозможные баззворды I>>Для аутсорсной конторы такое очень выгодно. Ценятся не те специалисты, которые могут и делают, а те, кто в состоянии запудрить мозг заказчику.
S>Ну то есть, скоро аутсорс будет заниматься аутсорсингом, который в свою очередь... S>Вот и приплыли. Недолго, кстати, плавали.
Дык давно. Уже полно полу-контор посредников, которые аутсорсят аутсорс.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, btn1, Вы писали:
B>>Здравствуйте, Eugeny__, Вы писали:
E__>>>Зато красиво. Шаблоны. Методы по 2 строки. E__>>>... Но когда я вижу очередной высер такого плана, мне хочется убивать. Жаль, некого
B>>+1000. B>>Но убивать есть кого — банду старых пердунов GoF.
I>Неужели ГоФ виноват в том, что люди не хотят думать ?
Конечно виноваты. Они описали процесс создания программы, как процесс сборки из кубиков-паттернов. Причем явно указано что это вообще говоря хороший способ. Маленькую оговорку про то, что не каждый паттерн применим в любой ситуации, читатели обычно игнорируют. Хотя именно эту мысль стоило прописать на каждой странице.
Вообще любую книгу по архитектуре программ нужно начинать словами: "Используя знания из этой книги вы нанесете вред себе и окружающим в первый раз... и во второй тоже... да и в третий. Но когда-нибудь наступит просветление и вы сможете применить полученные знания на пользу."
G>Конечно виноваты. Они описали процесс создания программы, как процесс сборки из кубиков-паттернов. Причем явно указано что это вообще говоря хороший способ. [...]
Более того, создали карго культ. Паттерны, паттерны, паттерны. Т.е. думать надо только паттернами,
больше думать ничем не нужно.
Здравствуйте, gandjustas, Вы писали:
I>>Неужели ГоФ виноват в том, что люди не хотят думать ?
G>Конечно виноваты. Они описали процесс создания программы, как процесс сборки из кубиков-паттернов. Причем явно указано что это вообще говоря хороший способ.
Враньё. В книге сказано совсем другое — паттерны это возможное решение задачи проектирования. Внимание — проектирования, а не реализации.
>Маленькую оговорку про то, что не каждый паттерн применим в любой ситуации, читатели обычно игнорируют. Хотя именно эту мысль стоило прописать на каждой странице.
Ога, целая глава посвящена тому, как работать с паттернами.
Здравствуйте, Sharov, Вы писали:
G>>Конечно виноваты. Они описали процесс создания программы, как процесс сборки из кубиков-паттернов. Причем явно указано что это вообще говоря хороший способ. [...]
S>Более того, создали карго культ. Паттерны, паттерны, паттерны. Т.е. думать надо только паттернами, S>больше думать ничем не нужно.
Когда не было ГоФ, те же самые пейсатели вместо паттернов мыслили в терминах наследования-инкапсуляции-полиморфизма. Вместо того, что бы решать задачу, реализовывали десяток иерархий наследования, а то иначе как же, мало ооп это плохо.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Неужели ГоФ виноват в том, что люди не хотят думать ?
G>>Конечно виноваты. Они описали процесс создания программы, как процесс сборки из кубиков-паттернов. Причем явно указано что это вообще говоря хороший способ.
I>Враньё. В книге сказано совсем другое — паттерны это возможное решение задачи проектирования. Внимание — проектирования, а не реализации.
Ага, попробуй неокрепшему уму объяснить разницу между проектированием и реализацией, когда в книге прмиеры кода (внезапно реализация) приведены.
>>Маленькую оговорку про то, что не каждый паттерн применим в любой ситуации, читатели обычно игнорируют. Хотя именно эту мысль стоило прописать на каждой странице. I>Ога, целая глава посвящена тому, как работать с паттернами.
Попробуй для прикола спросить на собеседовании или просто у коллег про эту главу. 95% даже не вспомнят о её существовании, а остальные затруднятся сказать что в ней написано.
Здравствуйте, Ikemefula, Вы писали:
I>Нет здесь ничего красивого. Красиво, это когда смотришь в код и тебе сходу понятны и детали, и абстракции и точки для расширения, и возможности оптимизации и код раз за разом своей работоспособностью вселяет уверенность.
Кстати, понравилась оценка "вселяет уверенность". Что-то здесь есть. Глубокое...
Здравствуйте, Sharov, Вы писали:
I>>Вместо того, что бы решать задачу, реализовывали десяток иерархий наследования, а то иначе как же, мало ооп это плохо.
S>О, ну паттерны это конечно исправили. Было криво, стало косо.
Паттерны вообще ничего не изменили. Любители баззвордов были и будут всегда.
Здравствуйте, gandjustas, Вы писали:
I>>Враньё. В книге сказано совсем другое — паттерны это возможное решение задачи проектирования. Внимание — проектирования, а не реализации. G>Ага, попробуй неокрепшему уму объяснить разницу между проектированием и реализацией, когда в книге прмиеры кода (внезапно реализация) приведены.
Ужос, в книге по проектированию приведен для примера конечный результат проектирования
I>>Ога, целая глава посвящена тому, как работать с паттернами. G>Попробуй для прикола спросить на собеседовании или просто у коллег про эту главу. 95% даже не вспомнят о её существовании, а остальные затруднятся сказать что в ней написано.
Результаты такие — кто умеет читать, тот все понимает. Кто не умеет — тому мерещится всякое, в том числе "программы надо складывать из паттернов"
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Враньё. В книге сказано совсем другое — паттерны это возможное решение задачи проектирования. Внимание — проектирования, а не реализации. G>>Ага, попробуй неокрепшему уму объяснить разницу между проектированием и реализацией, когда в книге прмиеры кода (внезапно реализация) приведены.
I>Ужос, в книге по проектированию приведен для примера конечный результат проектирования
Ты ушел от ответа. Сможешь объяснить чем проектирование от реализации отличается, если и там, и тут код? Особенно тому, кто еще не читал много умных книжек.
I>>>Ога, целая глава посвящена тому, как работать с паттернами. G>>Попробуй для прикола спросить на собеседовании или просто у коллег про эту главу. 95% даже не вспомнят о её существовании, а остальные затруднятся сказать что в ней написано.
I>Результаты такие — кто умеет читать, тот все понимает. Кто не умеет — тому мерещится всякое, в том числе "программы надо складывать из паттернов"
И снова ты ушел от прямого вопроса. Какой процент вспомнит про эту самую главу, о том как работать с паттернами?
Практика показывает что надеяться на сознательность каждого программиста нельзя.
Здравствуйте, gandjustas, Вы писали:
I>>Здравствуйте, gandjustas, Вы писали:
I>>>>Враньё. В книге сказано совсем другое — паттерны это возможное решение задачи проектирования. Внимание — проектирования, а не реализации. G>>>Ага, попробуй неокрепшему уму объяснить разницу между проектированием и реализацией, когда в книге прмиеры кода (внезапно реализация) приведены.
I>>Ужос, в книге по проектированию приведен для примера конечный результат проектирования
G>Ты ушел от ответа. Сможешь объяснить чем проектирование от реализации отличается, если и там, и тут код? Особенно тому, кто еще не читал много умных книжек.
Нуда, Структура это тоже код, описание применимости это тоже код, описание взаимодействия снова код, и все это код при чем на русском языке
G>И снова ты ушел от прямого вопроса. Какой процент вспомнит про эту самую главу, о том как работать с паттернами?
Зачем вспоминать главу? Главное чтобы человек понял что ГоФ хотя и решебник, не самый удачный, он не предлагает строить код из паттернов, более того, явно указывает этого не делать
G>Практика показывает что надеяться на сознательность каждого программиста нельзя.
Более того, с любой другой книгой все ровно то же
Скажем, те кто не осилил гоф, в ДДД 'прочтут' о том что эта книга про ооп
Здравствуйте, Sharov, Вы писали:
I>>Паттерны вообще ничего не изменили. Любители баззвордов были и будут всегда.
S>Риторический вопрос: зачем тогда множить сущности?
Незачем. С паттернами количество сущностей в среднем не изменилось.
Это не java. Никто не запрещает на ней писать по-другому. Это дурость головного мозга.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
A>Во-первых это зависит от стадии, в которой находится проект. Если проект начинается и архитектура сразу накрученная, это говорит о том, что когда-то где-то прозвучал диалог типа такого например:
A> — Нам надо чтобы все апдейты в UI были в реальном времени. А ещё нам надо демку инвесторам показать через месяц. Там нужны фичи А, Б и Х. A> — А реалтаймные апдейты в UI тоже к демке нужны? A> — Не, их можно потом.
A>В этой точке "архитектор" знает, куда оно всё катится и если возникает мысль, что какой то аспект запилить прямо вот сразу, чтобы потом не было мучительно больше, он так и сделает. В результате когда придут "программисты", первым делом обвинят его в оверинжиниринге. Им никто не запрещает общаться с заказчиком, бэклог от них никто не прячет, все новости озвучиваются в явном. А им просто пофигу обычно. Если бы было не пофигу, сами были бы архитекторами. Но нет, чаще всего они играют в игру "убеди QA, что фича работает".
A>Во-вторых нужно разделять "планирование" и "понимание направления". Для того, чтобы уместно накрутить архитектуру достаточно знать направление. Сегодня у нас есть только сайт, но заказчик говорит, что к концу года хотелось бы ещё мобильных клиентов в первом приближении. Программисту Васе по барабану — он позиционирует себя как "Senior Java Back End Developer", ему плевать на всех этих винфонов, андроидов и айфонов, он не относит это к тому, о чём ему стоит знать. Поэтому введение service layer и запрет писать бизнес логику в контроллерах приводит к нытью на тему "архитектора фаулер покусал".
Знаешь, я ведь не зря написал "разбираюсь в проекте" и "написавшие уволились". Ну вот так получилось, что на меня сваливают все сильно и не сильно легаси, ибо нервов и сил разобраться у других не хватает.
Ну, то есть, я вижу мною описанное говно не в динамике, а в ретроспективе. И понимаю, что все эти изыски вот вообще не пригодились, как бы не думали те, кто наворачивал эти тонны буллшита.
А еще — да, я забыл. Использование библиотек везде, где можно. И правдами и неправдами попытка следовать их идеологии, и как можно больше кода скрыть в нутрях разных либ. Желательно да, чтобы вызовы были неявные, а тебе типо приходило все уже сконфигурированным и настроенным в функцию.
А вот теперь представь. Проект, написанный в твоем стиле. Все, что можно, запрятано как можно дальше(ну как же, неужели я опозорю свой класс логики каким-то методом парсинга урл? Не, это будет происходить в недрах либы, только через внешнее навешивание библиотечной процедуры через АОП(и хрен ты по коду догадаешься где именно это описано, пока руками не перешерстишь ВЕСЬ проект, на что уйдет от недели до месяца), только через кучу интерфейсов, фабрик, и еще черти-чего). Приходит тебе типа урл на что-то, в метод. Ну, точнее, должен приходить. Еще лучше — когда не урл, а сразу результаты запроса, и уже распарсенные типа. Любы юзаются какие только возможно — лишь бы читающий этот код не смог понять, в чем суть, но оно ведь не надо, правда? Тыжеархитектор, ты все предусмотрел. А вот твой гневный пост в профильном форуме: http://rsdn.ru/forum/java/5629388
. Типа — никаких ручных действий, есть же мощный библиотечный класс! Зная отдаленно Спринг, и понимая твою идеологию — он удачно впишется в вышеописанное сокрытие всего и вся от читающего проект программиста.
А теперь, внезапно, приходит откуда-то урл из моего примера
. Он правильный, но тех, кто писал спринг, это не колыхало, ибо если посмотреть сорцы приведенного тобою класса — там обычный быдлопарсинг регекспами, причем быдло — потому что рассчитан только на стандартные хттп урлы с днс именем хоста, причем так и только так, rfc писавший это говно в глаза не видел. Но ошибок этот класс не выдаст, нет. Он просто отдаст левые данные, которые потом вызовут пачку исключений в самых неожиданных местах с самыми неожиданными сообщениями. Причем(помним про проект) опять же не в программерском коде, а черти-где! Хорошо, если исключения не будут проглатываться в процессе прохождения всей иерархии архитекто-библиотеко-говнобуллшит-кода. В последнем случае поиск бага при отсутствиии возможности дебага и редких событиях возникновения превращается в такой ад, что поддержка проекта, где все вообще выполняется в одной функции будет казаться сказкой.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, btn1, Вы писали:
b> E__>Зато красиво. Шаблоны. Методы по 2 строки. b> E__>... Но когда я вижу очередной высер такого плана, мне хочется убивать. Жаль, некого
b> +1000. b> Но убивать есть кого — банду старых пердунов GoF.
Ну конечно, виноват кто угодно, но только не тот кто не умеет пользоваться инструментом. Да и GoF придумали только названия для типичных решений, а то что эти решения кинулись применять зачастую не включив голову проблема тех кто применяет.
Здравствуйте, Eugeny__, Вы писали:
E__>Знаешь, я ведь не зря написал "разбираюсь в проекте" и "написавшие уволились". Ну вот так получилось, что на меня сваливают все сильно и не сильно легаси, ибо нервов и сил разобраться у других не хватает. E__>Ну, то есть, я вижу мною описанное говно не в динамике, а в ретроспективе. И понимаю, что все эти изыски вот вообще не пригодились, как бы не думали те, кто наворачивал эти тонны буллшита. E__>А еще — да, я забыл. Использование библиотек везде, где можно. И правдами и неправдами попытка следовать их идеологии, и как можно больше кода скрыть в нутрях разных либ. Желательно да, чтобы вызовы были неявные, а тебе типо приходило все уже сконфигурированным и настроенным в функцию.
E__>А вот теперь представь. Проект, написанный в твоем стиле. Все, что можно, запрятано как можно дальше(ну как же, неужели я опозорю свой класс логики каким-то методом парсинга урл? Не, это будет происходить в недрах либы, только через внешнее навешивание библиотечной процедуры через АОП(и хрен ты по коду догадаешься где именно это описано, пока руками не перешерстишь ВЕСЬ проект, на что уйдет от недели до месяца), только через кучу интерфейсов, фабрик, и еще черти-чего). Приходит тебе типа урл на что-то, в метод. Ну, точнее, должен приходить. Еще лучше — когда не урл, а сразу результаты запроса, и уже распарсенные типа. Любы юзаются какие только возможно — лишь бы читающий этот код не смог понять, в чем суть, но оно ведь не надо, правда? Тыжеархитектор, ты все предусмотрел. А вот твой гневный пост в профильном форуме: http://rsdn.ru/forum/java/5629388
. Типа — никаких ручных действий, есть же мощный библиотечный класс! Зная отдаленно Спринг, и понимая твою идеологию — он удачно впишется в вышеописанное сокрытие всего и вся от читающего проект программиста. E__>А теперь, внезапно, приходит откуда-то урл из моего примера
. Он правильный, но тех, кто писал спринг, это не колыхало, ибо если посмотреть сорцы приведенного тобою класса — там обычный быдлопарсинг регекспами, причем быдло — потому что рассчитан только на стандартные хттп урлы с днс именем хоста, причем так и только так, rfc писавший это говно в глаза не видел. Но ошибок этот класс не выдаст, нет. Он просто отдаст левые данные, которые потом вызовут пачку исключений в самых неожиданных местах с самыми неожиданными сообщениями. Причем(помним про проект) опять же не в программерском коде, а черти-где! Хорошо, если исключения не будут проглатываться в процессе прохождения всей иерархии архитекто-библиотеко-говнобуллшит-кода. В последнем случае поиск бага при отсутствиии возможности дебага и редких событиях возникновения превращается в такой ад, что поддержка проекта, где все вообще выполняется в одной функции будет казаться сказкой.
Я ваш комментарий поделю на 2 тезиса:
1. "Достался проект с какой-то архитектурой, паникапаникапаника"
Причин у вашей паники может быть несколько:
* Проблема может быть лично в вас. Например, не хватает технической подготовки, чтобы быстро разобраться как оно работает. Или не хватает предыстории — понимания задач и сложностей, с которыми столкнулись до вас. Или планы по проекту были сильно более амбизиозные, прежде чем он попал к вам — а вы об этом не знаете. Плохо когда нет возможности пару недель потратить на передачу знаний, но так бывает.
* Проблема может быть в тех, кто был до вас. Вполне мог быть Архитектор, который любил Архитектуру ради Архитектуры. Фактически тот же говнокод, только с другой стороны — понимать и сопровождать сложно. Такое тоже бывает.
Какой из этих двух вариантов конкретно у вас — я не знаю. Моё исходное сообщение в этом треде было посвящено именно тому, что одна из причин, почему архитекторы "городят чёрт знает что" — это как раз более глубокое видение жизненного цикла проекта. То что вы сверху описали — это как раз "я хз почему оно так, но выглядит херово". Вот моё сообщение было именно про причины этого самого "я хз".
A>Причин у вашей паники может быть несколько: A>* Проблема может быть лично в вас. Например, не хватает технической подготовки, чтобы быстро разобраться как оно работает.
Дадада, разбираться в тоннах говна. Только это не умение, а усидчивость.
A>Или не хватает предыстории — понимания задач и сложностей, с которыми столкнулись до вас.
А это вообще бывает? Конечно ни предыстории ни документации нет. Писавшим это говно не до таких мелочей было, а потом они уволились. По крупицам бегаешь как ошпаренный, собирая с QA и манагеров, как оно хотя-бы приблизительно работает. На 50% инфы начинаешь что-то понимать, но пока нечетко. Больше инфы не даст никто, действуем по наитию и по реверс инжиниринггу.
A>Или планы по проекту были сильно более амбизиозные, прежде чем он попал к вам — а вы об этом не знаете.
Планы всегда опережают разработку, и всегда сверхамбициозные. Но не каждый разработчик может послать манагера нах, когта тот порет чушь.
A>Плохо когда нет возможности пару недель потратить на передачу знаний, но так бывает.
От кого получать знания? какая передача? Проект уже 8-10 лет в продакшне, его разрабы уже давно далеко. Крупицы хотя-бы базового функционала знают толковые ребята из QA, всех знаний по этим проектам просто нет вообще, даже по тому, что они должны делать. Ну, они что-то делают в продакшне, но что — уже никто не знает. Ходишь как по минному полю.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, andyag, Вы писали:
A>>Причин у вашей паники может быть несколько: A>>* Проблема может быть лично в вас. Например, не хватает технической подготовки, чтобы быстро разобраться как оно работает.
E__>Дадада, разбираться в тоннах говна. Только это не умение, а усидчивость.
Слушайте, если вы воспринимаете свою работу как "тонны говна", не проще другую работу найти? Тут дискуссии не получится — вам просто противна задача, которая перед вами стоит. У меня было несколько очень интересных проектов, где был готовый код, который писал кто-то другой. Я не буду говорить, хороший он или плохой, но построение запросов к базе там было во вских OnButton1Clicked. Мне были интересно этим заниматься — именно благодаря этим проектам я научился рефакторить и осознал ценность уместных тестов.
A>>Или не хватает предыстории — понимания задач и сложностей, с которыми столкнулись до вас.
E__>А это вообще бывает? Конечно ни предыстории ни документации нет. Писавшим это говно не до таких мелочей было, а потом они уволились. По крупицам бегаешь как ошпаренный, собирая с QA и манагеров, как оно хотя-бы приблизительно работает. На 50% инфы начинаешь что-то понимать, но пока нечетко. Больше инфы не даст никто, действуем по наитию и по реверс инжиниринггу.
Конечно бывает. Есть такой типичный сценарий — аутсорсили продукт, решили поменять вендора. В таких случаях устраивают нолидж трансфер. Выделяется время, кто-то куда-то едет в командировку, общаются.
A>>Или планы по проекту были сильно более амбизиозные, прежде чем он попал к вам — а вы об этом не знаете.
E__>Планы всегда опережают разработку, и всегда сверхамбициозные. Но не каждый разработчик может послать манагера нах, когта тот порет чушь.
Каждый разработчик и не должен — должен только тот, который "отвечает" за техническую часть. Такой человек обычно старается не придумывать всякое, а направлять девелопмент таким образом, чтобы:
1. Девелоперы не говорили "я не знаю как это сделать".
2. Если вдруг команду сократят до него одного, он был уверен, что там нет какого-то глубоко спрятанного дерьма вроде зависимости строки подключения к базе данных от цвета кнопки.
A>>Плохо когда нет возможности пару недель потратить на передачу знаний, но так бывает.
E__>От кого получать знания? какая передача? Проект уже 8-10 лет в продакшне, его разрабы уже давно далеко. Крупицы хотя-бы базового функционала знают толковые ребята из QA, всех знаний по этим проектам просто нет вообще, даже по тому, что они должны делать. Ну, они что-то делают в продакшне, но что — уже никто не знает. Ходишь как по минному полю.
8-10 лет назад запустили, потом не трогали, и только сейчас решили вернуться к девелопменту?
A>>2. UriComponentsBuilder — кривой.
A>>Ответил вот тут: http://rsdn.ru/forum/java/5645428.1
E__>>Дадада, разбираться в тоннах говна. Только это не умение, а усидчивость.
A>Слушайте, если вы воспринимаете свою работу как "тонны говна", не проще другую работу найти? Тут дискуссии не получится — вам просто противна задача, которая перед вами стоит. У меня было несколько очень интересных проектов, где был готовый код, который писал кто-то другой. Я не буду говорить, хороший он или плохой, но построение запросов к базе там было во вских OnButton1Clicked. Мне были интересно этим заниматься — именно благодаря этим проектам я научился рефакторить и осознал ценность уместных тестов.
Я свою работу люблю. Мне обычно приходится заниматься двумя вещами: превращением говна, по поводу которого у всех опустились руки, в конфетку, и совмещение не очень совмещаемых вещей в общем понимании(творческие способы скрещения ужей с ежами). И первое, и второе приносит удовольствие. Рефакторить OnButton1Clicked, кстати, проще простого. Обычно код там ужасный, но его структура проста как столб. А вот когда структура кода представляет из себя камаз спагетти с говном — вот тогда начинается самое интересное. Замена 300К строк и 200К классов одним в 500 строк? Легко. Переписывание тонны крайне малопонятного многопоточного кода в один класс с использованием короткоживущих copy-on-write объектов? Бывало(и, что смешно, это давало выигрыш по производительности). Просто упрощение кода, когда он сдувался в 500 раз засчет убирания лишних либ и наворотов(потому что все уже бежали как от огня от этого проекта), правда, обычно на скале — множество раз. И я знаю, что делаю хорошо, ибо код, который обслуживает архитектуру, а не решает задачи — это неплохо если его 5%. Если его 95%, то берешь бульдозер, и сгребаешь это все в утилизатор, ибо правка малейшего бага в таком коде — это кромешный ад. Не, сама правка может быть и небольшой, а вот поиск, где поправить, и вообще из-за чего бага может занимать совершенно непотребное время.
A>>>Или не хватает предыстории — понимания задач и сложностей, с которыми столкнулись до вас.
E__>>А это вообще бывает? Конечно ни предыстории ни документации нет. Писавшим это говно не до таких мелочей было, а потом они уволились. По крупицам бегаешь как ошпаренный, собирая с QA и манагеров, как оно хотя-бы приблизительно работает. На 50% инфы начинаешь что-то понимать, но пока нечетко. Больше инфы не даст никто, действуем по наитию и по реверс инжиниринггу.
A>Конечно бывает. Есть такой типичный сценарий — аутсорсили продукт, решили поменять вендора. В таких случаях устраивают нолидж трансфер. Выделяется время, кто-то куда-то едет в командировку, общаются.
Увы(или стоит сказать "ура"?), в аутсорсе мне поработать не довелось. Может, там свои заморочки.
A>>>Или планы по проекту были сильно более амбизиозные, прежде чем он попал к вам — а вы об этом не знаете.
E__>>Планы всегда опережают разработку, и всегда сверхамбициозные. Но не каждый разработчик может послать манагера нах, когта тот порет чушь.
A>Каждый разработчик и не должен — должен только тот, который "отвечает" за техническую часть. Такой человек обычно старается не придумывать всякое, а направлять девелопмент таким образом, чтобы: A>1. Девелоперы не говорили "я не знаю как это сделать". A>2. Если вдруг команду сократят до него одного, он был уверен, что там нет какого-то глубоко спрятанного дерьма вроде зависимости строки подключения к базе данных от цвета кнопки.
И нанимать его надо из Мира Эльфов, да? Того, который сделает всем хорошо, в смысле.
У меня уходили дни рабочего времени и мегабайты строк в скайпе на то, чтобы убедить менеджеров в том, что то, что они придумали — трэш. И, признаюсь, получается это совсем не всегда. Техническая часть вообще мало кого волнует — продукт должен выполнять задачи, и ради этого менеджмент готов купить костыльный завод, благо, денег хватит.
A>>>Плохо когда нет возможности пару недель потратить на передачу знаний, но так бывает.
E__>>От кого получать знания? какая передача? Проект уже 8-10 лет в продакшне, его разрабы уже давно далеко. Крупицы хотя-бы базового функционала знают толковые ребята из QA, всех знаний по этим проектам просто нет вообще, даже по тому, что они должны делать. Ну, они что-то делают в продакшне, но что — уже никто не знает. Ходишь как по минному полю.
A>8-10 лет назад запустили, потом не трогали, и только сейчас решили вернуться к девелопменту?
Да, такое постоянно бывает. Работает себе продукт, но пришло время прилепить к нему свистелки и перделки, например. Или долепить кастомную заточку под жирного клиента, который компании принесет немало денег(или уйдет к конкуренту, который меньше парится о технической части своих проектов).
A>>>2. UriComponentsBuilder — кривой.
A>>>Ответил вот тут: http://rsdn.ru/forum/java/5645428.1
E__>>И ответил неверно. Даблфэйл.
A>Я неудачник и никогда не скрывал этого. А Spring всё-таки обновите до новой версии
Я уже обновил. Да, теперь ipv6 парсится верно — в класс добавили паттерн для него. Но еще 1000 случаев он так же неверно парсит.
ЗЫ я спринг сто лет не использовал(и не использую сейчас). Просто примерчик с парсингом урлов очень показательный получился.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E__>>Зато красиво. Шаблоны. Методы по 2 строки. Новые технологии. Только найти строчку кода, которая что-то делает, а не обслуживает какое-то очередное трендовое решение — дикая головная боль. Выяснить, где какие-то значимые логические операции, а где просто куски — хрен там. Документация — ага, щас, писателям сего некогда — слишком мало классов!!!!111
I>Нет здесь ничего красивого. Красиво, это когда смотришь в код и тебе сходу понятны и детали, и абстракции и точки для расширения, и возможности оптимизации и код раз за разом своей работоспособностью вселяет уверенность.
Знаешь, я все больше и больше начинаю любить скалку. Не, я на ней тоже видел адский треш, когда программист хотел не решить задачу, а показать, как он умеет выпендриться. Но на самой скалке такая ситуация нечаста, ибо язык по самой идеологии призывает писать коротко — там все под это заточено. Вместо монструозных конструкций используются довольно легко читаемые инструкции. Поначалу код на скалке понятен так себе — много разных непонятных символов и прочее. Но он короткий, и сама идеология языка не рекомендует использовать тонну классов для простой задачи. А то в некоторых проектах на джаве реально полный трындец. Блаблаинтерфейс, блаблаадаптер, блаблафабрикаблублу, блаблафасаддлядлублаблу, блаблаимпл, блабладефхрензнашо, блаблаблабла, и так для каждого блбабла и блублу. И самое стремное, что эти классы, во-первых, не представляют никакой логический объект, во-вторых, все равно используются единожды, и в-третьих, похожи как две капли воды ибо логики в них нет, только обслуживание таких же непонятных хреней, которые тоже не представляют собою никакого понятного объекта. Нахрена, зачем? Тесты? Ну так поднимите мне веки, покажите мне эти тесты? Ах, не написали, но "кто-нибудь напишет"? А я-то, дурак, думал, что TDD подразумевает написание тестов перед кодом. Ибо никто не напишет тесты для вашего говнокода кроме как под дулом автомата.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
A>>А в этих ваших сиплюсплюсах уже научились делать всякие встроенные HTTP-серверы
MTD>Давным-давно, а на Java драйвера писать научились?
Было дело, кстати. Правда, драйвера клиентского режима для кассово-банкового оборудования. Но это все-таки драйвер, так как он общается с девайсами посредством специфического бинарного протокола(ессно своего для каждого девайса), а выдает одинаковый объектный интерфейс для работы с каждым типом девайсов. Прекрасно все писалось. Единственное чем в этом плане неудобна джава — отсутсвием беззнаковых простых типов, но при аккуратной работе это легко обходится.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
A>>или может хотя бы общепринятую систему управления зависимостями?
MTD>maven имеется в виду? Нет, такого нет.
Кстати, мавен пилят в сторону работы с с++ проектами(особо не изучал, но вот вроде ничего так пример). Логично, потому как ничего чисто джава-специфического в мавене нет. Другое дело инфраструктура, но при росте популярности она появится.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, MTD, Вы писали:
A>>>или может хотя бы общепринятую систему управления зависимостями?
MTD>>maven имеется в виду? Нет, такого нет.
E__>Кстати, мавен пилят в сторону работы с с++ проектами(особо не изучал, но вот вроде ничего так пример). Логично, потому как ничего чисто джава-специфического в мавене нет. Другое дело инфраструктура, но при росте популярности она появится.
А я именно про инфраструктуру писал. Gradle вон тоже замечательно билдит C++, но толку от этого мало пока все библиотеки нужно либо руками устанавливать глобально, либо подключать через git submodules
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, andyag, Вы писали:
E__>Я свою работу люблю. Мне обычно приходится заниматься двумя вещами: превращением говна, по поводу которого у всех опустились руки, в конфетку, и совмещение не очень совмещаемых вещей в общем понимании(творческие способы скрещения ужей с ежами). И первое, и второе приносит удовольствие. Рефакторить OnButton1Clicked, кстати, проще простого. Обычно код там ужасный, но его структура проста как столб. А вот когда структура кода представляет из себя камаз спагетти с говном — вот тогда начинается самое интересное. Замена 300К строк и 200К классов одним в 500 строк? Легко. Переписывание тонны крайне малопонятного многопоточного кода в один класс с использованием короткоживущих copy-on-write объектов? Бывало(и, что смешно, это давало выигрыш по производительности). Просто упрощение кода, когда он сдувался в 500 раз засчет убирания лишних либ и наворотов(потому что все уже бежали как от огня от этого проекта), правда, обычно на скале — множество раз. И я знаю, что делаю хорошо, ибо код, который обслуживает архитектуру, а не решает задачи — это неплохо если его 5%. Если его 95%, то берешь бульдозер, и сгребаешь это все в утилизатор, ибо правка малейшего бага в таком коде — это кромешный ад. Не, сама правка может быть и небольшой, а вот поиск, где поправить, и вообще из-за чего бага может занимать совершенно непотребное время.
"просто" и "сложно" — это очень относительные понятия. При разных квалификациях они очень сильно разные. Начиная от "написать хеллоу ворлд" — это сложно для человека, который только что первый раз взял в руки книжку по программированию и заканчивая "урезать количество кода в N раз с сохранением функциональности" — это легко для человека, который занимается аналогичными задачами последние сколько-то лет. То, о чём вы рассказываете, называется "углубляющий рефакторинг". Это когда ваше понимание происходящего выходит на новый качественный уровень и вместо сотни отдельных нетривиальных проблем, которые вы видели в коде "вчера", вы начинаете видеть всего одну тривиальную сегодня. Чтобы такое происходило быстро и часто нужен большой опыт, понимание "где проект находится сейчас" и "к чему всё идёт". Вы всё правильно говорите, но мне кажется, что не вы не видите разницу в двух очень разных ситуациях:
1. Делаем новый проект и пока не очень понятно как что будет
2. Видим старый проект и понимаем, что стоило сделать иначе
Разница в том, какие знания можно получить прямо сейчас, когда хочется. Для нового проекта требования поступают постепенно, некоторые требования изменяются по 20 раз, поэтому ловить каждый раз "вот здесь можно всё сделать проще" — это далеко не тривиальная задача. Для существующих проектов, где "всё уже есть, но хреново" сравнительно легко вытащить все эти требования и проверить всякие гипотезы об упрощении, просто потому что всё уже зафиксировано и вам не нужно по 8 часов общаться со стейкхолдерами, слушая как они на каждый ваш вопрос придумывают по десятку новых бизнес рулов.
E__>>>А это вообще бывает? Конечно ни предыстории ни документации нет. Писавшим это говно не до таких мелочей было, а потом они уволились. По крупицам бегаешь как ошпаренный, собирая с QA и манагеров, как оно хотя-бы приблизительно работает. На 50% инфы начинаешь что-то понимать, но пока нечетко. Больше инфы не даст никто, действуем по наитию и по реверс инжиниринггу.
A>>Конечно бывает. Есть такой типичный сценарий — аутсорсили продукт, решили поменять вендора. В таких случаях устраивают нолидж трансфер. Выделяется время, кто-то куда-то едет в командировку, общаются.
E__>Увы(или стоит сказать "ура"?), в аутсорсе мне поработать не довелось. Может, там свои заморочки.
Есть заморочки на тему "сдал-принял". Компания просто так не возьмётся сопровождать "легаси" — обязательно будут оговорены всякие сроки вникания, возможность получать ответы на вопросы, критерии приёмки работы клиентом и т.д.
E__>>>Планы всегда опережают разработку, и всегда сверхамбициозные. Но не каждый разработчик может послать манагера нах, когта тот порет чушь.
A>>Каждый разработчик и не должен — должен только тот, который "отвечает" за техническую часть. Такой человек обычно старается не придумывать всякое, а направлять девелопмент таким образом, чтобы: A>>1. Девелоперы не говорили "я не знаю как это сделать". A>>2. Если вдруг команду сократят до него одного, он был уверен, что там нет какого-то глубоко спрятанного дерьма вроде зависимости строки подключения к базе данных от цвета кнопки.
E__>И нанимать его надо из Мира Эльфов, да? Того, который сделает всем хорошо, в смысле.
Почему? Просто минимально ответственный чувак с хорошим опытом. Если речь идёт о технически ограниченных проектах, где экзотики не очень много, не так сложно найти человека, скиллов которого будет хватать, чтобы сделать весь проект самостоятельно. База + сайт + веб API + мобильный клиент под Андроид — технически до такого уровня лет за 5 прокачаться можно легко. Но если этот чувак будет один, проект будет делаться календарно долго, просто из-за количества работы. Поэтому такого человека ставят "главным по технической части" и дают команду из N человек.
E__>У меня уходили дни рабочего времени и мегабайты строк в скайпе на то, чтобы убедить менеджеров в том, что то, что они придумали — трэш. И, признаюсь, получается это совсем не всегда. Техническая часть вообще мало кого волнует — продукт должен выполнять задачи, и ради этого менеджмент готов купить костыльный завод, благо, денег хватит.
Здесь видимо снова разница в специфике работы. Клиент-исполнитель и менеджер-подчинённый — это очень-очень разные отношения.
A>>8-10 лет назад запустили, потом не трогали, и только сейчас решили вернуться к девелопменту?
E__>Да, такое постоянно бывает. Работает себе продукт, но пришло время прилепить к нему свистелки и перделки, например. Или долепить кастомную заточку под жирного клиента, который компании принесет немало денег(или уйдет к конкуренту, который меньше парится о технической части своих проектов).
Могу только пожелать удачи. ИМХО, у задачи очень большой риск и шанс подставиться.
A>>Я неудачник и никогда не скрывал этого. А Spring всё-таки обновите до новой версии
E__>Я уже обновил. Да, теперь ipv6 парсится верно — в класс добавили паттерн для него. Но еще 1000 случаев он так же неверно парсит.
E__>ЗЫ я спринг сто лет не использовал(и не использую сейчас). Просто примерчик с парсингом урлов очень показательный получился.
Это одна из тех ситуаций, о которых я писал вот тут
. UriComponentsBuilder не на 100% соответствует стандарту:
* Если вы клепаете сайтик на спринге — это вообще не проблема. Не надо писать свой UriComponentsBuilder _по умолчанию_.
* Если вы пишете какой-то хардкор, для которого правильный разбор любых URL — это must, то — да, надо либо найти какой-то более адекватный парсер, либо написать свой руками.
Когда есть понятная мотивация, велосипед — это не велосипед, а "решение".
A>"просто" и "сложно" — это очень относительные понятия. При разных квалификациях они очень сильно разные. Начиная от "написать хеллоу ворлд" — это сложно для человека, который только что первый раз взял в руки книжку по программированию и заканчивая "урезать количество кода в N раз с сохранением функциональности" — это легко для человека, который занимается аналогичными задачами последние сколько-то лет. То, о чём вы рассказываете, называется "углубляющий рефакторинг". Это когда ваше понимание происходящего выходит на новый качественный уровень и вместо сотни отдельных нетривиальных проблем, которые вы видели в коде "вчера", вы начинаете видеть всего одну тривиальную сегодня. Чтобы такое происходило быстро и часто нужен большой опыт, понимание "где проект находится сейчас" и "к чему всё идёт".
Да, опыт такой есть. И за такой опыт работодатели готовы платить, и немало. У меня не так много баззвордов в резюме, но хороший набор решенных задач. Увы, некоторые программисты делают упор не на решения задачи, а на углубление знаний в технологиях. А я уже давно не вижу особой разницы в том, какую именно технологию использовать — это больше от задачи зависит, а знания в чем-то конкретном всегда можно получить в процессе.
A>Вы всё правильно говорите, но мне кажется, что не вы не видите разницу в двух очень разных ситуациях:
A>1. Делаем новый проект и пока не очень понятно как что будет A>2. Видим старый проект и понимаем, что стоило сделать иначе
A>Разница в том, какие знания можно получить прямо сейчас, когда хочется. Для нового проекта требования поступают постепенно, некоторые требования изменяются по 20 раз, поэтому ловить каждый раз "вот здесь можно всё сделать проще" — это далеко не тривиальная задача. Для существующих проектов, где "всё уже есть, но хреново" сравнительно легко вытащить все эти требования и проверить всякие гипотезы об упрощении, просто потому что всё уже зафиксировано и вам не нужно по 8 часов общаться со стейкхолдерами, слушая как они на каждый ваш вопрос придумывают по десятку новых бизнес рулов.
Иногда и в развивающемся проекте нужно сделать "стоп" и провести рефакторинг, удалив явно ненужные и устаревшие части. Это займет время сейчас, но сильно упростит работу в дальнейшем. Иногда наоборот приходит понимание, что нужно сделать какую-то абстракцию, ибо код начинает превращаться в спагетти. Это тоже заставляет сделать стоп-поинт, и заняться только этим. Правда, нужно уметь убедить в необходимости такой работы менеджеров, а это бывает не всегда просто. Ибо для яних это выглядит как необоснованная пауза в реализации новых фич. Это тоже скилл, причем далеко не самый простой в нашей профессии. Увы, очень многие страдают индусским "yes man". Но есть способы — например, сделать обоснование. Желательно его задокументировать, где-нибудь в вики или в жире. Поддаться менеджеру, и сделать как он хотел. Если все ок — то ты ошибся. Если оказалось, что решение говно — ткнуть менеджера в это говно и в написанное тобою ранее обоснование этого. После пары итераций с тобой начинают считаться.
E__>>У меня уходили дни рабочего времени и мегабайты строк в скайпе на то, чтобы убедить менеджеров в том, что то, что они придумали — трэш. И, признаюсь, получается это совсем не всегда. Техническая часть вообще мало кого волнует — продукт должен выполнять задачи, и ради этого менеджмент готов купить костыльный завод, благо, денег хватит.
A>Здесь видимо снова разница в специфике работы. Клиент-исполнитель и менеджер-подчинённый — это очень-очень разные отношения.
Да, хоть я и не работал в аутсорсе, примерно разницу понимаю.
A>>>8-10 лет назад запустили, потом не трогали, и только сейчас решили вернуться к девелопменту?
E__>>Да, такое постоянно бывает. Работает себе продукт, но пришло время прилепить к нему свистелки и перделки, например. Или долепить кастомную заточку под жирного клиента, который компании принесет немало денег(или уйдет к конкуренту, который меньше парится о технической части своих проектов).
A>Могу только пожелать удачи. ИМХО, у задачи очень большой риск и шанс подставиться.
К этому привыкаешь. Ну и кто-то же должен это делать, верно?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Иногда и в развивающемся проекте нужно сделать "стоп" и провести рефакторинг, удалив явно ненужные и устаревшие части. Это займет время сейчас, но сильно упростит работу в дальнейшем. Иногда наоборот приходит понимание, что нужно сделать какую-то абстракцию, ибо код начинает превращаться в спагетти. Это тоже заставляет сделать стоп-поинт, и заняться только этим. Правда, нужно уметь убедить в необходимости такой работы менеджеров, а это бывает не всегда просто. Ибо для яних это выглядит как необоснованная пауза в реализации новых фич. Это тоже скилл, причем далеко не самый простой в нашей профессии. Увы, очень многие страдают индусским "yes man". Но есть способы — например, сделать обоснование. Желательно его задокументировать, где-нибудь в вики или в жире. Поддаться менеджеру, и сделать как он хотел. Если все ок — то ты ошибся. Если оказалось, что решение говно — ткнуть менеджера в это говно и в написанное тобою ранее обоснование этого. После пары итераций с тобой начинают считаться.
Мне кажется это одно из главных элементов и масштабируемого кода. В своем небольшом проекте я это очень хорошо почувствовал. Код должен эволюционировать. Есть более менее понятный дизайн, надо добавить что-то мелкое, результатом добавления является флаг в конструктор и выставлением его наружу, потом еще флаг. Снова возникает подобная задача и надо добавить флаг, но вот тут уже надо остановиться и подумать, что было добавлено 2 флага, сейчас надо добавить третий, наверное стоит решить задачу, чтобы потом можно было добавить еще 10, при этом оставив простоту и понятность кода. Выбор момента когда нужно обобщать, а когда нет очень тонкий. Отклонения в ту или иную сторону пораждают либо непонятный дизайн либо запутанный спагетти код.
Здравствуйте, Eugeny__, Вы писали:
E__>Ну и до кучи. Тут уже не в абстрактном плане, а вполне про конкретное.
E__>Господа "архитекторы"! Зачем вы тулите тонну решений "на будущее"?
Так пишут код "архитекторы" или "разработчики"? У вас точно проблема с "архитекторами", а не с разработчиком который просто решился применить все известные ему подходы. Ваш крик, скорее говорит об отсутствие "архитектора" на проекте.
I>Для аутсорсной конторы такое очень выгодно. Ценятся не те специалисты, которые могут и делают, а те, кто в состоянии запудрить мозг заказчику.
Скорее выдать мегатонны кода на гора. Если решить задачу парой классов, как объяснить заказчику, что стоит 100500 миллионов? Вот, а если нафигачить кучу слоев, абстракции, паттерны и т.д. и т.п., есть что показать. Вон сколько классов, применены все наимоднейшие технологии, учтены все тренды... неплохо бы допик оформить на увеличение суммы контракта.
Здравствуйте, Eugeny__, Вы писали:
E__>Не, не везде так. Есть вполне понятные проекты. Но когда я вижу очередной высер такого плана, мне хочется убивать.
Красота возникает там где есть четкие цели и ограничения. Если человек не может их определить для себя сам, значит они должны быть заданы извне.
Ограничивая количество строк в методе и количество методов в классе, но при этом не ограничивая количество классов — вы получаете взрывной рост классов и интерфейсов в самых причудливых сочетаниях.
Если программист сам не задается правильными вопросами — значит ему надо помочь. Принесли код на ревью — спроси, а можно ли это сделать в два раза меньшим количеством строчек, классов, методов? Потратил 30 минут на то, чтобы разобраться с кодом — спроси, как сделать так, чтобы я мог разобраться за 5 минут? Не надо говорить разработчикам как делать, нужно ставить конкретные цели и ограничения. А умение ставить правильные цели и ограничения — это уже головная боль тех лида.
E__>Жаль, некого — по странной случайности авторы сего уже уволились.
Если некого убить, но очень хочется — убей котенка. Они уже привыкли умирать за чужие ошибки.
Здравствуйте, Eugeny__, Вы писали:
E__>Не, не везде так. Есть вполне понятные проекты. Но когда я вижу очередной высер такого плана, мне хочется убивать. Жаль, некого — по странной случайности авторы сего уже уволились.
1. Авторы одной статьи писали про то, что плохая архитектура рождается из-за плохой командной работы. Поскольку люди не могут нормально общаться, они отгораживают свои части кода различными промежуточными конструкциями. Причём это делается исходя из индивидуальных умений программистов, а не общего архитектурного плана.
2. Ещё есть такой подход:
— Я пишу оптимальные функциональные программы.
— Если вижу чужой говнокод, то просто переписываю всё заново.
— Библиотека? Нет, использую своё решение, оно тут как раз входится в функцию.
И первый и второй случай описывают отсутствие командной работы. Если на проекте один человек, то думаю второй подход в целом не плохо работает для проектов на которых никогда не понадобится больше одного человека. Начальство, которому в целом плевать на долгосрочную перспективу программного продукта, по достоинству ценит таких людей.
То, что люди уволились не странная случайность, а закономерность. Говорить об архитекторах в данном контексте бессмысленно. Архитектор это ключевая фигура, которую не выкидывают с проекта. А раз люди уволились, значит никаких архитекторов нет, каждый сам по себе, методология — делаем как получится. Тем более раз позволяется изменять чужой код, нет никакой области ответственности.
Но жизненно, да 
