×Закрыть

Как реанимировать старый безнадежный проект. Часть 2: Тимбилдинг

Rescue image via Shutterstock.

Перед прочтением этой статьи рекомендуем ознакомиться с предыдущим материалом: «Как реанимировать старый безнадежный проект. Часть 1: Рефакторинг vs переписывание с нуля».

Муки выбора: формат команды и проекта

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

Вы можете:
1. Создать две конкурирующие команды. Одна из них сопровождает старый проект, вторая — пишет новый.
2.Создать два проекта (новый и старый) в рамках одной команды.

В первом случае старая команда остаётся сопровождать умирающий проект, пока новая команда с нуля переписывает систему. Стоит предостеречь от искушения выпускать переписанную систему только после полного повторения функциональности старой системы. Зачастую такое решение приводит к очень долгому противостоянию между старым и новым проектом, время разработки нового проекта затягивается из-за неоправданно высоких ожиданий по функциональности. Программисты испытывают давление со стороны менеджмента, а от старой команды всё чаще слышны смешки «уж два годка как ждем релиза». В таких условиях программисты «нового» проекта вынуждены торопиться и совершать ошибки, они пишут «грязный код», часть из них разочаровывается и покидает проект, а спустя время вы получаете хаос ничуть не лучше, чем в старом проекте.

Чтобы избежать этой участи, нужно установить разумные рамки функциональности новой системы. Это тот самый случай, где без MVP и разумного системного аналитика вам просто не обойтись. А во избежание ненужной конкуренции между командами — изолируйте их друг от друга, разместив офисы разработчиков, например, в разных концах города. Связующим между старым и новым проектом должен выступать аналитик, но никак не разработчики.

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

Почему работодатели не ставят в известность разработчиков старой команды о написании новой системы? Они беспокоятся, что команда, узнав о скором закрытии своего проекта, откажется его сопровождать. Найти выход из этой ситуации, морально подготовить команду и корректно сообщать ей эти непростые новости — еще одна головная боль, о которой нужно подумать заранее.

Выпускать новую систему как заменитель старой или создавать внутреннего бренд-конкурента — вопрос к маркетолагам, но над этим тоже следует подумать заблаговременно.

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

Второй способ организации команд и проектов — это создание старого и нового проекта в рамках общей команды.

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

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

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

Стоит упомянуть, что команда будет препятствовать грядущим изменениям всеми возможными средствами. Вариант «всех уволить» нам не подходит, т.к. кто-то должен сопроводить старый «не-пойми-как-работающий» продукт. И чтобы минимизировать пагубное влияние на принятие решений в рамках новой системы — очень желательно выделить для «Проекта 2» отдельное совещательное помещение (и это не должен быть общий митинг-рум).

Успех данной стратегии во многом зависит от доступности необходимых ресурсов. После первичной оценки объемов будущей системы, архитектор и аналитик могут запросить в команду одного или нескольких новых специалистов. Как правило, для этого есть веские основания, будьте готовы к этому.

Из недостатков этого метода можно перечислить:
1.Сложности при поиске достаточно грамотных и коммуникабельных архитектора и аналитика, которые согласятся обучать команду.
2.По истечении времени часть разработчиков придется уволить, потому что, скорее всего, для сопровождения новой системы понадобится гораздо меньшее количество программистов, чем для старой.

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

Данная стратегия применима как для полного переписывания системы, так и для глубокого рефакторинга текущего проекта.

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

И в завершение, всегда помните: вашу команду формируют личности, у которых есть свои переживания и мысли. У них разные характеры, привычки и коммуникативные способности. Успех вашего предприятия в большей мере зависит даже не от технического уровня специалистов, а от личных качеств этих людей. Каждый из ваших разработчиков — маленький «станочек» в вашем IT бизнесе — он создаёт продукт, который вы продаёте. Никогда не забывайте, что они — живые люди, относитесь к ним по-человечески, и тогда очень велика вероятность, что они ответят взаимностью.

Послесловие

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

«Когда я пришел в этот проект, я понятия не имел, что так можно работать. В предыдущей команде был постоянный кодревью, «били по рукам» за неправильное имя переменной, криво написанную функцию, неправильно выбранный алгоритм, не тот примененный паттерн проектирования и.т.д. У меня был очень красивый код. У меня был правильный стиль. У меня была поддержка со стороны (мой же код постоянно смотрели), и вероятность ошибок падала экспоненциально. Именно такой «светлый», «отчеканенный» я пришел.

Первое, с чем я столкнулся, — это хаос. Натуральный кошмар. Хотя в том безнадежном проекте тоже была своя «система». Был таск-менеджер, были таски, сроки, код. Главное, чего не было — это стандарты. И первое, что я сделал, — за неделю написал стандарты кодирования: как переменные именовать, какие отступы, куда ставить скобочки, как писать запросы, какие классы использовать и.т.д.

Сначала стандарты обсмеяли. Потом все-таки их вынесли на утренний митинг. На митинге их бурно обсудили, перевели в холивар:
— А вот я привык пользоваться пробелами!
— А я привык пользоваться табами!..
И так далее. Что потом? А ничего. Каждый остался при своём, и мне сказали:
— Вот видишь, не будут все писать одинаково.

Как должен вести себя руководитель в этом случае? Жестко взять и сказать: «хватит бардака! Делаем так и так». Устраивание балагана и/или «пусть всё решает общее вече с утра пораньше» — это банальный уход от ответственности.

Нет системного подхода — бардак! Бардак способен решать задачи, но не способен делать это эффективно. Бардак не способен быстро исправлять ошибки. Бардак не способен не допускать ошибки. Бардак способен плодить ошибки.

Когда вместо набора if()...if()...if() я предложил использовать Абстрактную фабрику, все, кроме одного парня, спросили: «Что? Что это?» — это было показательно. Есть шаблоны проектирования. Они не с потолка придуманы. И это не уровень «нравится — не нравится». А это уровень «поддерживается — не поддерживается».

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

Я пытался внедрить массовое код-ревью — не получилось. И дело не столько в инструментарии, сколько в том, что: «да кто ты такой, что указываешь мне, что делать с моим кодом? Ты сколько тут работаешь? Два месяца? А я — два года. Фигово написано? Не твоего ума дела. Работает? Вот и не компостируй мозг».

Я переписывал тихо. Один парень там умел спорить и доказывать. Если не получилось доказать — он не исправлял ничего. Работало, как работало. Я же молча и без шума что-то менял сам, и тихо радовался своей работе. Никто этого не оценил. В конечном итоге я ушел. Меня ждали новая компания, новый мир, бурный рост, осознание собственной глупости.

Ты спрашиваешь, почему я ушел: я начал тупеть. Очень сильно. За неделю до ухода я открыл фрагмент кода, посмотрел и обалдел: он был очень красиво написан.

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

Я рад, что ушел в новую компанию, где мои качества оценили по достоинству. Очень приятно заниматься любимым делом, реализовать себя, быть нужным и уважаемым специалистом, да еще и получать достойную компенсацию за свой труд".

Сердечно благодарю Славу Конашкова за профессиональные консультации и помощь в написании этой статьи.

64 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

1. Создать две конкурирующие команды. Одна из них сопровождает старый проект, вторая — пишет новый.
2.Создать два проекта (новый и старый) в рамках одной команды.
Два раза участвовал в подобных проектах в двух совершенно разных по профилю фирмах. Один раз меня-юниора уволили через полгода, второй раз через полгода уволился я-сениор. Чем все закончилось не интересовался, однако то что видел сам пока работал — пустое сжигание человеко-часов. По опыту обоих проектов сделал для себя вывод: если фирма умудрилась довести свой продукт до такого состояния (или умудрилась убедить себя, что довела до такого состояния), что он не поддается рефакторингу и необходимо полное переписывание, значит ловить там нечего т. к. местные сениоры-лиды или менеджмент-владельцы или и те и другие — в неадеквате.
Первое, с чем я столкнулся, — это хаос. Натуральный кошмар. Хотя в том безнадежном проекте тоже была своя «система». Был таск-менеджер, были таски, сроки, код. Главное, чего не было — это стандарты. И первое, что я сделал, — за неделю написал стандарты кодирования: как переменные именовать, какие отступы, куда ставить скобочки, как писать запросы, какие классы использовать и.т.д.
Тут, по-моему, можно просто поржать.
если фирма умудрилась довести свой продукт до такого состояния
Была такая фирма. ;) Аппле. Довела собственное ядро операционки до состояния, в котором на версии X пришлось перейти на «фряшное».

Безнадежный проект — не обязательно чисто техническая составляющая его непосредственно разработчиков.

Была такая фирма. ;) Аппле. Довела собственное ядро операционки до состояния, в котором на версии X пришлось перейти на «фряшное».
Ну ядро — это все таки не весь проект. К тому же они не переписывали его, а позаимствовали.
Безнадежный проект — не обязательно чисто техническая составляющая его непосредственно разработчиков.
Вот-вот, часто проблема в менеджменте-владельцах, это даже хуже.

Наталия, а это all.biz переписывается с нуля?

а давайте по всем моим работам по списку пройдёмся? Как думаете, будет ли корректно с моей стороны привселюдно рассказывать о своих работодателях, особенно вещи, о которых я говорить не хочу? Как думаете, я себе работу потом найду вообще где-то?

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

Объясните мне, чем люди думают, когда задают такие вопросы?
Что собеседник просто ответит «Извините, конфиденциально» или «Да, скоро будет крутой няшные all.biz, кстати, приходите к нам на технологии XXX, YYY, мы куем хайлод».
Как думаете, я себе работу потом найду вообще где-то?
После таких комментариев Вам ее найти будет однозначно сложнее.

я прошу прощения за грубый тон, вчера день не задался.

А вот мне показалось что Наталия корректна. И не болтает лишнего :) В конце-концов это может насолить кому-то.

собеседник просто ответит «Извините, конфиденциально»

Спасибо за дискуссионную статью.

Меня немного пугает что среди комментаторов нет ни одного который бы написал — Ха! Рефакторинг? Да мы задней левой ногой стопицот проектов переписали и норм. Всё в срок и бюджет, заказчики довольные как стадо слонов. Надо, короче, вначале...

а зачем писать о том, как что-то делать? Гораздо ведь проще устроить холиварище и забросать автора какаш... ой, аргументами, что «это всё фантазии», «дайте метрики» и т.д. Вот так набежала куча Дартаньянов и давай себя в грудь пятками бить. Статья-детектор, ей-богу )

а зачем писать о том, как что-то делать? Гораздо ведь проще устроить холиварище и забросать автора какаш... ой, аргументами, что «это всё фантазии», «дайте метрики» и т.д.
а зачем писать о том, как что-то делать? Гораздо ведь проще налить воды на 11 страниц и обижаться на всех кто указывает вам на ваши ошибки :)
Статья-детектор
Можно по списку «мои ошибки», пожалуйста?
Можно по списку «мои ошибки», пожалуйста?
По списку нет, а в разброс где-то так:
dou.ua/...uilding/#579021
dou.ua/...rewrite/#578162
dou.ua/...rewrite/#578195

А давайте расставим точки над и? Мне не нравится тон обсуждения «Этопростописец!». Я оставляю за собой право отвечать или не отвечать на любые комментарии, собственно, как и вы. Я вам ничем не обязана.

Счастливо оставаться.

1. Создать две конкурирующие команды. Одна из них сопровождает старый проект, вторая — пишет новый.
2.Создать два проекта (новый и старый) в рамках одной команды.

В теории выглядит красиво, но ни один подход не годится на практике, Роберт Мартин в своей книге «Идеальный программист» или «Чистый код» описывает почему. Точную страницу не нашел, но там это точно есть. Если найду, укажу страницу.

Вот мой вольный пересказ: «Когда старая система становится совершенно неподдерживаемой и команда ползет со скоростью улитки, они объявляются начальству, что система никуда не годится и ее нужно переписать с нуля. Руководство соглашается и создается новая ударная команда, которая будет писать новую систему, а другие чуваки поддерживать старую. Естественно все программисты любят писать с нуля, поэтому самые сильные уходят в новую команду, а слабые остаются на сапорте старой. И начинается состояние гонки, автору известно, что такая гонка длилась годами. Но ни одна такая новая система не была внедрена, потому что первоначальный состав давно покинул ударную команду, другие люди не смогли хорошо разобраться, и новая система скатилась к тому с чего начали: «нужно переписывать с нуля».

В теории выглядит красиво, но ни один подход не годится на практике, Роберт Мартин в своей книге «Идеальный программист» или «Чистый код» описывает почему. Точную страницу не нашел, но там это точно есть. Если найду, укажу страницу.
Страницы 25 — 29. Сразу видно, что читал. Пролистайте заново — эта статья не противоречит тому, что писал Роберт Мартин. Более того, он так и оставил открытым вопрос — что же делать, если проект уже в предсмертном состоянии. Его книга посвящена тому, как не допустить такой ситуации, а не что делать, когда всё уже произошло.

Рассказ анонимного архитектора внизу красноречиво опровергает вашу статью. Из «болота» нет выхода. Можно еще прочитать про Д.Уэлча, также известного как человек-бензопила, как он «наводил порядок» в различных компаниях путем массовых увольнений, но это я немного забегаю вперед.

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

Еще раз подчеркну, как-то только настроения команды падает, проект в штопор: страдает документация, код, деплои, появляются критикалы, различные скандалы и распри, уходят носители знаний и новый виток.

Выхода нет.

вы первую часть этой статьи читали? Там черным по белому написано, что без политической воли и новой крови результата не будет никогда. В этом случае я соглашусь с вами. Рассказ внизу ярко иллюстрирует это.

Читал, но я все равно не согласен с излишним менеджерским оптимизмом такого подхода, когда явные проблемы преуменьшаются и акцент перемещается на иллюзии. Что вам удастся найти аналитика, который составит грамотные требования по дикому legacy, что найдется архитектор, который спроектирует отличную и поддерживаемую инфраструктуру, что «новая кровь» разгонит болото, что будет грамотный аудит проекта, это все иллюзии к сожалению.

Возможно менеджерам такая статья покажется silver-bullet, но мне как разработчику она кажется неубедительной и я все равно убежден, что разработчикам нет смысла задерживаться на безнадежных проектах.

вы рассуждаете с позиции разработчика — и я разделяю ваше мнение. На таких проектах делать нечего. Однако, если проект приносит прибыль, если не смотря на всю кривость реализации, бизнес-модель приносит деньги — то проект будет жить. Пока он или совсем не испохабится в адов говнокод, который сыпется со всех сторон — точно по Роберту Мартину, либо пока меняться не вынудит конкурент.

Я тоже особого восторга не испытываю от того, что в нашей реальности есть такие проекты. Но факт остаётся фактом — есть проблема, нужно искать пути её решения.

silver-bullet
лично я считаю, что пока менеджеры будут витать в облаках в надежде, что кто-то решит их проблемы — до тех пор у нас будут возникать такие вот проекты в ненормально больших количествах.

Менеджер? Работаешь в IT? Значит потрудись изучить основы функционирования своего бизнеса. Ты не должен уметь программировать, но понимать, что же происходит в отделе разработки и чем живут эти люди — обязан.

пока менеджеры будут витать в облаках в надежде, что кто-то решит их проблемы — до тех пор у нас будут возникать такие вот проекты
Таки да, менеджер виноват в появлении «безнадежные проекты»: где-то недоглядел, где-то подтолкнул «фича важнее архитектуры» и тд.
Но у менеджера куда меньше рычагов влияния как на этапе говняния проекта, так и на этапе разгребания. И проблемы с проектом решаются как раз снизу более эффективно. А для менеджера затраты на рефакторинг включенные в простую фичу с комментарием «по другому не получится» — это куда понятнее чем 11 страниц воды на ДОУ.
понимать, что же происходит в отделе разработки и чем живут эти люди — обязан.
Нет, не обязан. Это очень хорошо когда таки понимает, если понимает, то скорее всего очень хороший управленец. Но задача менеджера следить за сроками, а надсмотр за качеством делегируемая другим людям (КуА-лид, Тим-лид разработчиков и тд).
Но задача менеджера следить за сроками
Чтобы определить сроки, человек должен быть в этом компетентен.

С вами у меня разговор уже окончен. Я не разделяю вашу точку зрения.

Чтобы определить сроки, человек должен быть в этом компетентен.
Нет, он должен быть компетентен в подборе людей которые компетентны в определении строков.
С вами у меня разговор уже окончен. Я не разделяю вашу точку зрения.
А вот тут второй важный момент: когда профессионал не разделяет точку зрения, он пытается донести свою и понять мысли оппонента. :)

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

Сыпать бисер — no.

я эту статью месяц обдумывала, трижды за неё садилась, ведь материал очень непростой, успела обсудить этот вопрос с нескольким десятком высококлассных специалистов и дать пару лекций по теме
Как я и говорил — «гуманитарное ля-ля». Вы за месяц и обладая ресурсами опыта 10 высококлассных специалистов не смогли сделать сводную табличку и список из 10-20 пунктов на уровне «что делать»?
Пока что у вас опубликована только «обоснование проблематики», для такой темы — это должен был быть 1 абзац на 5-10 строк.

Следующий раз так и сделаешь. На медаль.

Следующий раз так и сделаешь. На медаль.
Для начала не сделаешь, а сделаете.
И поясните что значит «следующий раз» и «на медаль».
я эту статью месяц обдумывала
:)))))))))))))))) Я по итогам 20 лет работы не готов писать подобные статьи. Ибо бред писать противно — себя не уважать, а не бред... мне очень далеко до того же Кента Бека.
Сыпать бисер
Великолепное отношение к читателям.

Можно ответить в твоем стиле «плохому танцору...», но да опускаться не буду.

Ты вынесла свои заметки на суд общественности. Что ты ожидала получить в ответ, кучу хвалебных постов? Это смешно. Ты получила ожидаемую дозу критики и самое правильное, что могла сделать это принять ее. Ты же начала скатывать всю критику в обычные форумные срачи с оскорблениями читателей.
Скажем так, твое поведение в высшей степени некрасиво вне зависимости от поведения читателей.

т.е. по такой логике в мой адрес позволяется любое хамство и мат, а с моей стороны любой чих — рассматривается как оскорбление? Круто )))) Так держать )

и мат
Лучше не пиши больше ничего. Тебе бы сначала в своих видениях разобраться.

т.е. формулировка «хамство» — проходит. Ну тоже неплохо, да )

А если не писать ничего то опыт не придёт.

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

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

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

где без MVP и разумного системного аналитика вам просто не обойтись
А я все думал к чему эти слабенькие статьи...
Реклама необходимости системных аналитиков.
1. Создать две конкурирующие команды. Одна из них сопровождает старый проект, вторая — пишет новый.
2.Создать два проекта (новый и старый) в рамках одной команды.
Это самая паршивая идея, которая вообще может прийти в голову, © даже объяснять лень. У меня был такой экспириенс, когда одна команда с мыслью «все тлен» разгребает говна мамонта и фиксит проект, который уже отправили на помойку («да кому это нужно?», «смысл фиксить, все равно все переписывать», «не трать время, поставь какой-нить костыль, все равно выкинут» и т.д.), пока вторая занимается разработкой с нуля и у них там единороги и радуга. О%уеть какая здоровая атмосфера в коллективе, о да.

а меня не задевает мысль о том что все что я напедалю уйдет на помойку, наоборот все не скатится в говно спустя много лет, вот оно пользу принесло и пропало — идеально, вообще бы с удовольствием разрабатывал проекты с определенным временем жизни (до 2 лет, например), а потом конец поддержки и новое с нуля, у меня это почему-то ассоциируется с играмми ааа класса, ну только теми которые не выпускаются потом серийно аддонами со всем тем же, только + пару юнитов, новые карты и типа новый сюжет

Согласна, если есть хороший проект со временем жизни и с поддержкой определенных стандартов качества — это совсем другой разговор.

да какая разница хороший он или плохой, если вот его конец уже рядом, намного хуже когда плохой проект, который надо тащить

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

Вот про эту штуку, родом из СССР (система продажи авиабилетов):
ru.wikipedia.org/...i/Сирена_(сеть

Вот есть старый проект, на этом ПО работают люди, крутятся реальные деньги. Припустим, что это кассир в магазине. Часть функционала мы оставили по-старому. Часть уже перенесли в новый софт. Даже сложно представить сколько ошибок будет делать кассир имея два ПО одновременно. Сколько радости он будет получать. И это довольно примитивное ПО — считал код, получил из базы цену, закончил транзакцию (утрировано).

Единственная более-менее интересная часть (не имеющая ни малейшего отношения к статье) — отзыв неизвестного «архитектора» с завышенным ЧСВ.

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

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

Но зачем тратить на такое болото годы жизни?
Вообще-то полгода, если умеешь. Зачем? Это интересно.

Расскажи подробнее, пожалуйста, как это всё зафиксить за полгода. Можно на примере из статьи, что чувак делал неправильно, как надо было делать правильно, и почему это сработало бы.

Хоспади, да все на поверхности.
Что сделал чувак из статьи? Он полез со своим уставом в чужой монастырь. Начал рассказывать, какие все вокруг тупые (судя по цитате, ЧСВ там — огого). И какую реакцию на это нужно ожидать?

А что надо было сделать? Ждать проблем. Если все так хреново, то и проблем должно быть в достатке. А потом — просто решать эти проблемы. И да, пока ждешь проблемы, хорошо бы было качественно исполнять свои обязанности, брать на себя ответственность и заводить хорошие отношения с руководством.

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

Дарование даже знающее паттерн «фабрика классов». Вот только не понятно почему он ушел из такого вот счастья

В предыдущей команде был постоянный кодревью, «били по рукам» за неправильное имя переменной, криво написанную функцию, неправильно выбранный алгоритм, не тот примененный паттерн проектирования и.т.д. У меня был очень красивый код. У меня был правильный стиль. У меня была поддержка со стороны (мой же код постоянно смотрели), и вероятность ошибок падала экспоненциально

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

как вариант — проект закрылся. Т.к. пока там били по рукам и пытались заюзать все возможные паттерны, конкуренты уже выпускали третью версию...

очень сомнительно, мне кажется такое только в стартапе может быть из-за недостатка опыта

дык любой проект когда-то был стартапом :)

я имел ввиду такой стартап, который так и не вышел в продакшин, потому что цель не деньги получить, а код писать оказалась

Ну вот ещё один вариант, который сам лично наблюдал:
Сварганеный на коленке стартап выстрелил, и приносит деньги (много). Но там фу-фу-фу архитектура и вообще пхп. Так что пару лет его переписывали на .net с неизвестным мне финалом.

И именно на этом проекте было отлично с юнит и автотестами, код-ревью и прочими програмистскими радостями.

Мне кажется, что вы не работали в болоте.

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

И я, в общем, действовал именно вот так — не лез со своим уставом в чужой монастырь, решал проблемы, не ссорился с коллегами (это не значит "не убеждал"/"не спорил"). Ко мне ходили коллеги с некоторыми проблемами.

Стало ли лучше? Безусловно. Но большинство проблем были обусловлены культурой компании. Поменять культуру компании снизу экстремально сложно.

Через некоторое время я оценил размер сделанных усилий, эффект от этих усилий, и уволился оттуда к чёрту.

Вы пробовали давать руководство выкладки, чего вам стоит гавнокод (в деньгах), сколько будет стоить рефакторинг, и когда он отобьется?

Более того — такое даже и без меня практиковалось. Однако рефакторинги не помогают уволить половину народу и из программистов, и из начальства.

Нет, для увольнения есть свои обоснования.

1. Создать две конкурирующие команды. Одна из них сопровождает старый проект, вторая — пишет новый.
2.Создать два проекта (новый и старый) в рамках одной команды.
Этопростописец!
Краткое пояснение:
По пункту 1. Люди из команды, которые остались разгребать гуано, а не попали на новый проект, пойдут искать новый проект в другой компании.
По пункту 2. 9 женщин не родят ребенка за 1 месяц. Важно понять почему плохой проект становится плохим. Ответ прост: Люди/команда.
Вы знаете окончание (одно из) фразы «к хорошему привыкаешь быстро»? Окончание такое «а к плохому еще быстрее». Проблема плохого проекта в команде, и надеятся что команда которая свела проект на гуано, что-то там увидит и поймет — бессмысленно! Ваш способ будет работать когда команда изменилась (или пришли новые люди, или старым объяснили как надо жить). Качественно сделать параллельно несколько дел за одно время не возможно, в нашем случае —это изменить команду изнутри и улучшить проект.
.
В общем как и ожидалось с предыдущих частей:
Автор — стратег-не-тактик.

у меня почему-то складывается стойкое ощущение, что вы являетесь действующим участником такого вот старого безнадежного проекта, его соавтором ) С таким жаром опровергать всеми правдами и неправдами материал — наверное, задело за живое ))

вы являетесь действующим участником такого вот старого безнадежного проекта, его соавтором
Где-то так, может не совсем безнадежный, но все же 10+ лет. Еще есть __опыт__ с 3-4 подобными проектами. И судя по вашим фантазиям, вы со «старыми и безнадежными» таки не работали, но лезете всех учить.
С таким жаром опровергать всеми правдами и неправдами материал
Ваш «материал» относится к материалам типа «шлак» и, вы таки правы, меня таки очень задевает некомпетентность людей которые работают в ИТ.

Подписаться на комментарии