×

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

Rescue image via Shutterstock.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті

  • Чому рефакторинг — це постійний процесЧому рефакторинг — це постійний процес

    Sergii Zhuravel

    Про рефакторинг ми чуємо дуже часто, але кількість питань з цієї теми не зменшується, а навіть збільшується. Тому Сергій Журавель пропонує поговорити про рефакторинг та аналізує свій проєкт. 40




73 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

...жизненая история...
...когда мы начали работать в одной команде с ребятами из одной крупной компании из С,В,, они нам часто говорили «We get You the Best Practices of Santa-Clara». Тогда это воспринималось хорошо, но с удивлением... Но после этого... ...можешь узнать еще на собеседовании «а правда ли что сия фирма работает с Силиконовой Далиной?»....

Стиль. стиль во всем.

Когда СТО компании, которая имеет 60 офисов по всему миру, и, по совместительству, BIG TEAM LEAD команды, в которую ты входишь в своем check-in почесному пишет «с 10-00А.М. по 11-30А.М. водил свою собачку к ветеринару...» понимаешь что такое это the Best Practices of Santa-Clara...

Да что говорить... Если б они тщательнее выбирали партнеров в Украине... ... ...в Украине с ними работали б буквально пару фирм.
Ведь поверьте, смешно рассказывать преподавателю Стенфордского Университета, с которым ты работал в одной команде и который уже тогда был Principal Java Software Engineer и с которым ты общаешся уже больше семи лет, что ...одна «большая и важная фирма» решила провести «скриниг» моего английского и за 15 минут общения в хрипящий телефон установила, что мой уровень ниже intermediate с «сильным словянским акцентом»... И действительно, он то это воспринял как «загадочную словянскую шутку»... :)

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

Потому... права автор статьи в главном.
«Рыба гниет с головы». Все исключительно зависит от руководства...
Хотя... что там рассказывали о принципе Рикардо из Бразилии??? :)


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

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

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

Интересно, а вот о SonarQube для Java или Guard для Ruby (ну или о других подобных кои есть для всех нормальных языков) они слішали???

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

Первый закон АйТи — если ты столкнулся с проблемой (ЛЮБОЙ!!!) — значит кто-то с ней уже стыкался и нашел ЕЛЕГАНТНОЕ и СТОПРОЦЕНТНОЕ решение!

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему же вода? ..это ж... из жизни... правда вот кого... вопрос. :) ...«пофикодеров»?

Может просто все знают теорию?

Например TDD.
1. Пишем тесты.
2. Пишем код — как можно быстрее, чтоб тесты просто перешли от «красного» в «зеленое».
3. Делаем рефакторинг — пока позволяет время, спринт, проэкт менеджер и кто-то там еще...

Оно ж ... красивый код в первую очередь это код, который получен ВОВРЕМЯ.

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

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

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

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

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

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

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

Выхода нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующий раз так и сделаешь. На медаль.
Для начала не сделаешь, а сделаете.
И поясните что значит «следующий раз» и «на медаль».

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

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

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

Чтобы определить сроки, человек должен быть в этом компетентен.

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

..хм... а еще есть такие «вкусные» штуки как Activity, BMNP и подобное. Реально ПОМАГАЕТ. Конечно, тем, кому это нужно... :)

Выход есть.
Тоже американский «best practices».

Один «общий друг» одного калифорнийского друга ушел с «большого гуру» серїезной компании через месяц.
Спрашиваю: «Что так, не понравилось?»
Друг отвечает: «Все оч. хорошо!»
«А что так?»
«Ну как тебе объяснить... У нас человек работает в одной компании от трех до пяти лет. Когда он там отработает три года — он начинает сразу искать работу и должен за два года максимум ее найти. Если он где-то проработает больше пяти лет — его никгде уже не возьмут на работу — так как это обозначает что он достигнул „уровня своей некомпетентности“ и больше не растет. А такие никому сейчас не нужны!»

Если бы этот принцип действовал в Украине — проблем было бы меньше...

В чем-то согласен... Но вот и тут наша индустрия придумала выход.
В общем-то нас в Бауманке еще за царя гороха этому учили
---- Системный подход.
Допустим, правильный и каноничный CI\CD от Мартина Фловера — был бы полезен в даной ситуации и является как раз вариацией системного подхода к вопросу "новый"\"старый" код...
Хотя и тут «лучших практик» весьма много. Главное... ...«чтобы костюмчик чидел». То есть «системный подход» глупо натягивать на «управляемый хаос»...
Но решений всегда N+1

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

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

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

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

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

А неужели кто-то выступает против «стандартов качества»?
Просто — как уже затрагивалось выше — есть огромный инструментарий для менеджеров и еже с ними чтоб контролировать НА ИХ УРОВНЕ «стандарты качества».

Вот просто почемуто я (и такие как я) должен максимально отслеживать все новое... Вот например вышел сейчас spring-boot 2.0 — нужно его разобрать «по ксточкам».. ...а там где-то далеко очень маленькими буквочками написано что «spring security» под него может выйдет к концу года...

А вот для многих менеджеров посмотреть — а что там появилось для них — это высшая математика...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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