Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

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

Revive image via Shutterstock.

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

Муки выбора: починить или сделать новое?

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

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

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

Что происходит дальше: все инициативные технические специалисты, будучи не услышанными, уходят. Скорость сопровождения системы продолжает экспоненциально падать. Более сообразительные конкуренты систематически вносят обновления и новшества в свои продукты, отбирая ваших клиентов. К этому моменту руководство наконец-то принимает волевое решение: «Нужно что-то делать!»

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

А как же получаются хорошие проекты?

Прежде чем продолжать рассуждения о головной боли старых безнадежных проектов, давайте немного отвлечемся и обратим внимание на успешные IT-продукты. Их все объединяют общие качества:

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

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

3. Высокий уровень личной ответственности. Сотрудники лично мотивированы и настроены на профессиональный рост, в команде есть участники, которые берут на себя ответственность за принятие решений.

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

А о системности подходов ярко говорит случайным образом связанный макаронный код проекта и отсутствие каких бы то ни было стандартов.

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

Без чего вы точно не обойдетесь

Чтобы в корне изменить ситуацию, вам в основном понадобятся две вещи: политическая воля и «новая кровь».

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

1. Красиво и идейно писать код.
2. Это увидят все остальные, оценят и поймут, как это круто и удобно,
3. и начнут сами писать так же.

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

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

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

Что же вас ждет? Если вы «старый» разработчик на проекте, и вас попросили остаться при обновлении — придется учиться. И это хорошая новость, потому что с новыми умениями вы увеличите свою ценность на рынке труда. Начинайте прямо сейчас!

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

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


Но это еще не всё.
Во второй части беседы поговорим о тимбилдинге в старых безнадежных проектах.

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

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

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

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

Схожі статті

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

    Sergii Zhuravel

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




190 коментарів

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

(рукалицо) о каком «проекте» идет речь? Идиотские птички для огрызка? Или огромная ЕЕ система, охватывающая целые континенты и с пяток разных доменов и возрастом лет в 30? Или комплекс реалтайм систем управления горнодобывающим комплексом, в купе с металлургическим заводом и электростанцией и непрерывным циклом производства?
Умиляют такие «статьи», всякие котики из интернета просто отдыхают, писшите исчо! Для меня ДОУ уже давно заменяет разные там, уже забытые, яплакаль и анектоды. Просто отдыхаешь душой ))))

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

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

Реализация — это всего-лишь скилет, его можно и нужно периодически менять, а вот данные внутри — это та кровь, которая циркулирует по телу, поэтому плясать в любом проекте нужно от данных, передаваемых с помощью современных коммуникационных стандартов, например, json, OAI или SOAP.

Каким образом, если

архитектура проекта сложна и невозможно понять
 И самое главное, кто за это будет отвечать?

Звучит хорошо, но не проще ли в этом случае переписать все заново? :)

Ключевыми словами есть старый и безнадежный. Если проект безнадежный, то Вам виднее,что безнадежно. Если проект старый, т.е. очень длительный, то можно его развивать. Я работал на телекоммуникационном проекте, который начали в США более 30 лет назад на mainframe. В систему регулярно добавлялись новые фичи и удаляли не актуальныуе функции. Огромная клиентская база с глубокой историей. Они попробовали перевести все на РС, но не получилось. Так и поддерживают систему в работоспособном состоянии, благо IBM обновляет HW&SW.

Я не могу представить реальную экономическую ситуацию, которая позволила бы с нуля переписать проект.
Допустим проект стоит 50 человеко-лет или по украинским расценкам примерно миллион долларов. У него есть какой-то кэш-фло, какая-то клиентская база и вдруг в какой-то момент времени некто говорит — Давайте потратим ещё один миллион и через два-три окажемся там же где мы сейчас.
Это странное решение.
Если судить по книжкам, то реально есть два пути для любого проекта — первый, постоянный рефакторинг, причём, не важно хороший это проект или нет, даже, наоборот, чем дальше проект от итальянской кухни тем резвее и нобходимее будет рефакторинг, ну и приятнее; и второй путь — пристрелить и разойтись.
Переписать с нуля этот вариант может относиться к модулю или к очень маленькому проекту который пилился в одно лицо.
Ничего технически невозможного в рефакторинге самого ужасного быдлокода нет, куча декорирующих, имитирующих, изолирующих паттернов.
Джуну в рефакторинге неинтересно и делать нечего, а нормальному профессионалу при соответствующем финансировании это даже челендж. Широкий простор для всех трёхбуквенных аббревиатур, которые у него в резюме есть.

При переписывании с нуля не нужно повторять все эксперименты, которые были с проектом.
Если разобрать проект по функционалу, то дай бог чтоб из 50 там 1-2 человеко-года осталось.

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

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

Книжная теория и моя практика говорят о том что всё известно может быть только на очень маленьком проекте. А в обычном проекте как только вы подумаете что всё уже известно заказчик вносит вводную которая ставит проект с ног на голову.

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

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

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

p.s.: был выбран рефакторинг, закончилось все не очень удачно

Ну так не было же варианта переписать с нуля. Хотя в этом случае когда новый заказчик такие варианты очень популярный — все так или иначе «переписывают» чужие прототипы.
Из того что я вычитал я делаю примерно такой вывод — на любом проекте должна быть команда постоянного рефакторинга, может быть 10-20% от основной, не знаю. Если этого нет, то процесс рефакторинга должен подразумевать остановку развития и освобождение почти всей команды от поддержки. Команда должна быть достаточно большой и точно работать слаженно и с максимальным пониманием предметной области. Ну и это должны быть профи высокого уровня.
Рефакторинг очевидно сложнее разработки. Это как из кривых выкроек уметь сшить идеальное платье.

был вариант переписать, только сверху решили переписать половину, а не все

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

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

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

Ничего технически невозможного в рефакторинге самого ужасного быдлокода нет, куча декорирующих, имитирующих, изолирующих паттернов.

Вам повезло, не видели вы такого ужаса, который можно назвать «невозможно». Если даже и возможно, то затраты на рефакторинг могут быть несоизмеримо выше, чем переписывание с нуля. А это ключевой момент: что дороже.
Потом, никто ж не заставляет терять клиентскую базу. Пишется параллельно, потом подменяете. Почти как рефакторинг, т.е. без изменения функционала. Только с нуля.

Один раз я столкнулся с проектом, в котором любое новое совсем маленькое требование оборачивается в дни трудозатрат и нет гарантии, что работает верно. Мало того, никто не знал требований. По факту, знали, что код работает приблизительно верно, хотя очень глючный, база данных верно. И надо было из самого проекта собрать требования.
Написал отдельный проект, который следит за текущим проектом, отслеживает нажатия кнопок и прочего. Просунул между базой данных и вызовами из кода прослойку, которая логирует. И далее, сделал всё так, чтобы собирались use-case в xml. Т.е. называете use-case, нажимаете «старт» в следящем проекте. Далее от нажатия, прослеживается ответ от бд, и что появилось на формах.

И такая жесть бывает.

PS. Не закончил это переписывание, т.к. уволился оттуда.

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

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

Может быть не хватило того что называется бизнес-аналитика.

Разные ситуации бывают. Я там был единственный разработчик, который отвечал за всё, кроме субд. Т.е. один базовик и один разработчик. И легаси код, писавшийся около 10 лет. Т.е. никакого скрама и прочего.

Был еще один случай, когда проект переписывался с нуля мною. Был случай, когда с нуля весь движок переписывался.

Я не сторонник переписываний. Но всё определяется ценой. Если дешевле переписать, то переписывали. Бывает такой ацкий код, что пару методов отрефакторить сложнее, чем половину проекта переписать.

Тот проект, например, написан человеком, который совершенно не соображал в ООП, хотя на шарпе писал его, написал код полностью в одном классе (божественный класс), кругом одни статические методы, которые возвращают bool (успешно/не успешно, т.е. эксепшинов не было), но при этом, этот сишник/олимпиадник даже не знал про ранние возвраты. Т.е. он в каждом если писал ветку если и иначе. Абсолютная взаимозависимость всех методов в этом божественном классе. Каждый метод на страницы ифов, а самих методов, сигнатур (в свернутом виде), около 10-тка страниц.
Разобраться даже в одном методе даже с дебагером — это смерть.
Вы представили себе ситуацию? А функционала этого мегапроекта ну на месяц работы от силы. Тем не менее проект жил, приносил уже деньги, но требовал постоянных новых доработок/хотелок, и каждая хотелка, вроде мелкая, могла обернуться в часы, а то и дни.

Это один из типов говнокодов. Даже не худший, которые я видел.

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

Да, и бизнес-аналитика тоже не было. Сам бизнес, который работал на этом, находился далеко в другом городе ))

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

Был другой проект, который я уже в другой конторе с нуля переписывал. Там наоборот: была очень ясной предметная область и очень ясными требования, а код меганеясный. Заливка данных в базу данных из экселя — 40 тыс строк проект.
Разбираться в нем опасно для психического здоровья.

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

обычно правильнее вообще не трогать пока все работает

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

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

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

Здесь затраты на рефакторинг могут быть выше написания заново. Все придется перетестить и отпилотить.

Что значит «могут»? Берем две цифры (стоимость рефакторинга и переписывания) и сравниваем. Это ж математика, а не философия.

Где та грань, что пора переводить проект на что-то современное?
Перевод на «что-то современное» не имеет смысла вообще (оно может устареть ко времени окончания миграции :) ). Имеет смысл перевод, если старая технология не позволяет реализовать какую-то функциональность, имеет низкую производительность и тд.
Пока еще есть специалисты помнящие как это делать, но со временем их будет трудно найти.
Людей на кобол и перл вполне успешно находят. Что это за технология такая, что спецов сложнее найти чем на кобол?
.
Если вы понимаете что технология устаревает (оптенциальные не будет поддержывать более эффективные архитектурные подходы), то более прагматично может быть «законсервировать» разработку на этой технологии, и весь __новый функционал__ делать на более новой технологии.

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

Всем спасибо за комменты. С нетерпением жду завтрашнего холивара с выходом завершающей статьи.

С точки зрения разработчика с безнадежных проектов надо валить. Безнадежный проект = дохлая лошадь, Если лошадь сдохла — слезь! Но ведь это было бы слишком просто, поэтому и появляются такие вот активити:
1. Покупаем более сильную плеть.
2. Меняем наездников.
3. Говорим: «Мы всегда скакали на лошади именно таким образом».
4. Создаем комитет по изучению лошади.
5. Организуем посещение других организаций, чтобы посмотреть, как они скачут на своих дохлых лошадях.
6. Повышаем стандарты скачки на дохлых лошадях.
7. Создаем тигровую команду по оживлению дохлой лошади.
8. Организуем тренинг по развитию скаковых навыков.
9. Проверяем соответствие состояния дохлой лошади современной окружающей среде.
...
LOSS

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

Рефакторинг, как и хирургия, помогает когда еще не поздно и носит временный характер. Безнадежный = дохлый по определению, спорить тут не о чем. Для рефакторинга нужно покрытие тестами, для плохого проекта это принципиально невозможно покрыть тестами все места, которые будете менять. И вместо рефакторинга получается пробежка по минному полю с понятным итогом.

это всё понятно, когда диагноз уже известен. А у нас тут холивар о том, а нужно ли вообще какие-то телодвижения делать.

читайте продолжение завтра. Выйдет вторая часть статьи.

хотя, «когда» и «почему» описано уже в этой части. И ещё вот тут: dou.ua/...peless-project

Холивары по определению строятся на абстрактных и абсурдных вещах: Ислам vs Христианство (собственно истоки), iPhone vs Android, Windows vs Linux, Овуляшки vs Child-free и т.д.
Если время добавление фичи или выкатка новой версии по сравнению с аналогичным функционалом увеличивается в 3-5-10-100 раз по времени и/или прочими ресурсами, то нужно принимать меры.

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

Для рефакторинга нужно покрытие тестами, для плохого проекта это принципиально невозможно покрыть тестами все места, которые будете менять.
Но есть нюанс...
Согласен со всем, но внесу поправку.
В том случае о котором Вы говорите НЕ нужно покрывать юнит тестами.
Пишите интеграционные тесты. Нет? Не получается! Тогда пишите функциональные. В рамках этих реалий уже можно рефакторить относительно безболезненно. (я сказал относительно... да, подорваться можно все равно... нет, у нас ограниченное количество саперов...)
Пишите интеграционные тесты. Нет? Не получается! Тогда пишите функциональные. В рамках этих реалий уже можно рефакторить относительно безболезненно.
Юнит/не юнит — это не принципиально. Проблема в том что вы перед рефакторингом должны понять __все__ бизнес-сценарии, а не имея ни тестов, ни хорошей спеки (что как правило является проевлениями гуано-проектов), вы не сможете покрыть все сценарии.
Другими словами ваши тесты, написанные через года/релизы после имплементации фичи будут покрывать только базовые сценарии и не дадут уверенности в корректности рефакторинга.
Проблема в том что вы перед рефакторингом должны понять __все__ бизнес-сценарии, а не имея ни тестов, ни хорошей спеки (что как правило является проевлениями гуано-проектов), вы не сможете покрыть все сценарии.
И это чистая правда! Значит вероятность подрыва растет.
бабах.... а вот и он!

Это точка зрения QA, которые тестируют методом черного ящика. С точки зрения девелопера при крупных рефакторингах все по-другому. Обычно интеграционные/функциональные покрывают 5/10% функционала в лучшем случае. Без Unit не обойтись никак. Иначе даже если билд пройдет, то очень большая вероятность возникновения плавающих багов, внезапных отваливаний различных кусков спагетти-колбасы индусского/местного производства.

Это точка зрения QA, которые тестируют методом черного ящика.
Не только. Есть у меня в арсенале несколько толковых людей (реально толковых) который склонны нести подобную мысль в массы. Лучше пусть будет хоть что-то покрыто тестами, чем не будет покрыто ничего. Лучше пусть тест будет функциональным и покроет 5% функционала, но уже на эти 5% функционала можно опереться.
Без Unit не обойтись никак
О, ДА! А вот если их нет и их внедрение долго и невозможно, а с первого раза еще и не получается потому что ... (о, боже, сколько тут разных вариантов) ... и нужно с чего-то начать...
Ну и начинаем. Вот, например, с итерационки. Тоже нереально? Сильно связаны модули? Ну хорошо, тогда пусть это будет функционалка. Не попадайтесь в петлю «мы не можем начать рефакторить, у нас нет тестов, но мы не можем писать тесты, т.к. там ужас и мрак и нужен рефакторинг».

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

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

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

Теперь второй вариант: у нас есть хороший продукт, который имеет энное число лояльных пользователей. Но! Наши разработчики постоянно ноют о «рефакторинге», а самые «перспективные» из них (точнее, те, кто себя такими считает) уходят в другую контору.
Значит ли это, что мы должны сделать этот самый «рефакторинг»?

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

Так вот, предлагаю о этих цифрах и поговорить. Могу даже задать наводящие вопросы (и буду очень рад увидеть ответы):
— Какой нормальный уровень (%) соотношения «шума» и фич?
— Какой процент от затрат времени должны занимать мероприятия, направленные на поддержание скорости разработки (code-review, рефакторинг)
— Какой подход эффективнее и насколько: постоянный рефакторинг (каждый месяц) или рефакторинг при падении разработки на критический процент.
— Какой процент падения эффективности разработки является критическим (требует немедленно переходить к рефакторингу) ?

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

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

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

наш продукт в стадии переписывания. О нормах ещё рано говорить.

А как вы тогда решили, что проект нужно переписывать?

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

Насколько дешевле и насколько быстрей?
Насколько дороже (и в какой перспективе) было бы поддерживать старый продукт без глубокого рефакторинга?

проекту 6 лет. Писали китайцы. Сопровождал непонятно кто. Он встал колом. На сопровождение идти никто не хочет — плюются. Переписать по MVP можно за полгода силами двух крутых специалистов. Сопровождать и развивать — команда из 3-4-х толковых разрабов + аналитик.

Мне было бы сильно интересно посмотреть на то что вы решили похоронить

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

Другие подобные ситуации у вас были, или это первая подобная ситуация?

разборы полётов моего прошлого? А не много ли вы на себя берёте, господа?

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

Если бы вы сразу сказали, что с подобными метриками дела не имели, разговор был бы много короче.

А ещё можно попробовать инвесторам объяснить, что их мегауспешный, но тормознутый проект нужно «закапывать».

а можно ничего не делать. Тогда даже вопроса зачем не возникнет.

Простите, это из серии «я хоть что-то пытаюсь делать»?

это ответ в контексте статьи. Если ничего не делать — проект можно «закапывать». Если делать — то «а зачем».

Собственно, так часто и бывает. Молчишь в тряпочку — молодец. Высказал мнение — ай какой нехороший, зачем?

А потом все удивляются, почему это система сыпется? Почему на рынке 70-80 процентов проектов — быдлокод с отсутствующей архитектурой. Почему мы нанимаем послушных, работящих разработчиков десятками, а ничего не получается.

Простите, вы и на рабочих совещаниях, вместо аргументации срываетесь в истерику?

нет, что вы, только когда холивар поднимается.

Вопрос об измерении эффективности или необходимости того или иного действия вы именуете холиваром?

о том, что не нужно превращать в демагогию и переливание из пустого в порожнее, вопрос, когда он указан чётко и понятно: рефакторить / переписавать / оставить как есть.

Этот вопрос не имеет смысла.
Чтобы сделать его осмысленным, вам придется предоставить метрики.

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

Ссылка: www.issoft.by/...enii-proektami

Цитата: ни одна из известных на сегодняшний день метрик не может похвастаться достаточной значимостью и точностью. Метрики не дают объективной картины происходящего, они всего лишь предоставляют некоторые показатели, вычисленные по заданному алгоритму. Особенно это касается тех случаев, когда для оценки какого-либо параметра вводится только одна метрика. Более-менее полную картину может дать только использование целого комплекса метрик,
Во-вторых, часто, если сотрудники знают об измеряемых показателях, то они стараются не выполнить свою работу надлежащим образом, а занимаются подгонкой своих показателей под заданные параметры.

Во всех остальных случаях, когда у вас не компания-монстр, имеет смысл пользоваться здравым смыслом, а не высчитывать метрики, КПД, и проч. статистику полезности.

Вы использовали такие практики?

вы хотите спросить, что мы меряли? Вам сюда: dou.ua/...rewrite/#578693 и сюда: dou.ua/...rewrite/#578727

Отлично. Значит вы все таки измеряете эффективность, да?

зачем вы продолжаете меня терзать? Какая лично вам разница, что мы там измеряем? Почему вы думаете, что имеете право отчитывать меня как девочку? Мне не интересно общаться с вами в таком тоне. Я вам что-то должна?

-
Очень информативно и аргументированно. А главное ёмко и предельно лаконично.

Отличный комментарий! Однозначно плюс.

Сейчас попробую частично со своей колокольни «фонариком посветить».
Первое. Какой бы крутой не был код, какие бы крутые спецы не работали на проекте, как бы круто его не вылизывали/рефакторили/переписывали и.т.д. — успешность или не успешность проекта определяют клиенты. Да. Бабло! Если этого понимания нет — поздравляю, вы пилите yet another фича-в-себе. Круто вылизанную, но нафиг никому не нужную.

Но тут, как я вижу, понимание клиента во главе есть.
А значит есть и построенная цепочка клиент -> функционал -> задачи -> (yet another profit ex. refactoring).
Вот тут и подходим к вопросу эффективности.
Нужно мерять. Что мерять? Как мерять?
Дальше будет ИМХО, которое может идти в разрез с любым другим мнением. (если что — я предупредил)
Первое — меряем маркетинг(!). Посетителей, клиентов, продажи, конверсии, затраты и.т.д. Это основные показатели при принятии любого решения.
Дальше меряем производительность системы. Скорость работы скрипта/модуля, «отклик» базы данных, «отклик» API, количество обрабатываемых запросов в секунду, и.т.д.
А теперь меряем «эффективность команды».
Вот тут мерять можно от забора и до обеда.
— количество закрытых задач (для того чтобы правильно это мерять, должны быть правильные задачи, а не задача-простыня на +/-20 дней работы)
— количество баг-тикетов
— количество reopen тикетов
А что там у нас еще есть? (у каждого свое)
— среднее кол-во времени на типичную задачу
— % покрытия тестами
— стабильность тестов
— количество строчек кода (нет, не прикалываюсь. да, видел)
— количество коммитов в репу
и.т.д.

Под каждый продукт у каждой компании свои метрики.
Главное понимать что значит та или иная метрика.

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

Посему, буду краток:

Так вот, предлагаю о этих цифрах и поговорить.
— 300
— что 300?
— а что приборы?
©
Я готов говорить цифрами, но это будут цифры привязанные к конкретно заданному проекту, с конкретно заданными требованиями, для конкретно взятых людей, в конкретно взятый промежуток времени. Иначе, я считаю, это опять будут сферические кони в вакууме.

Как я предупреждал выше — это мнение конкретно взятого человека и оно может (и должно) отличатся от любого другого мнения любого другого конкретно взятого человека (или группы людей).

Я готов говорить цифрами, но это будут цифры привязанные к конкретно заданному проекту
Pavel Kruchina предлагал говорить не про абсолютные значени, а о процентах и тенденциях. Такие «цифры» не привязаны к конкретным случаям и принесли бы пользу от этой статьи, а так получилось обыкновенное «гуманитарное ля-ля». (Могуть быть отличия в стиле контора из 10 человк и 10К человек, но это можно вносить в уточнения/ограничения.)
Pavel Kruchina предлагал говорить не про абсолютные значени, а о процентах и тенденциях.
Да нивапрос. Метрики то у всех разные )
— Какой нормальный уровень (%) соотношения «шума» и фич?
1/10.
Почему?
Так получилось.
— Какой процент от затрат времени должны занимать мероприятия, направленные на поддержание скорости разработки (code-review, рефакторинг)
— Какой подход эффективнее и насколько: постоянный рефакторинг (каждый месяц) или рефакторинг при падении разработки на критический процент.
Нет ответа. Было несколько практик. И несколько практик было успешных.
1 день в неделю. Хороший ответ? Да. А, нет. Или да. Проверяли — работает.
А было такое, что каждую на задачу обязательно должно было быть review от другого разработчика твоего ранга или выше. Хороший ответ? Нет. Или да. Проверяли — работает. И хорошо работает.
А было такое, что вообще нет review. Меряли показатели эффективности функционала. Количество метрик зашкаливало там за 100. Метрики не удовлетворяли условию — выкинули функционал, выпилили, перепили заново или забыли и пилим другой. Хороший ответ? Да не знаю я уже. Но ведь работает же! Ну реально ж работает. Именно такой подход приносил наибольшую прибыль.
— Какой процент падения эффективности разработки является критическим (требует немедленно переходить к рефакторингу)
Никакой! А иногда любой. Но я больше склоняюсь к варианту никакой. Сначала разбираемся в причинах падения эффективности. Да может ребятам банально в отпуск нужно. А не... тут другая причина. Просто з/п не привязана к доллару, а курс вырос и у ребят пропала мотивация. Стали медленнее работать. А у команды из 3-го кабинете вообще третья причина.
Но когда ж тогда переходить к рефакторингу? Как вариант — всегда. (примеры есть выше). Или как вариант — никогда. (примеры есть выше). Или когда 3 из 5-ти разработчиков скажут, что этот модуль тяжело поддерживать. Технологии не те уже и еще 100500 причин. Вот тогда рефакторим. Но не весь проект, а только этот модуль. Отлично так и запишем. Цифра — 3/5 — на нее и будем ориентироваться.

---

Дак о каких процентах и тенденциях может идти речь, если мы уже перешли на цифры, не привязав их к конкретным случаям?

PS

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

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

У вас комментарий в стиле «какова вероятность встретить динозавра? — 50%. или встречу или нет.»

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

всё, рассматривать нечего. Расходимся.

без метрик рассматривать просто нечего
Угу. Примеры метрик я приводил выше.
— Какой процент от затрат времени должны занимать мероприятия, направленные на поддержание скорости разработки (code-review, рефакторинг)
«какова вероятность встретить динозавра? — 50%. или встречу или нет.»
каждую на задачу обязательно должно было быть review от другого разработчика твоего ранга или выше
Вот конкретный вариант. Без динозавров. Ну, разве что с «динозаврами» в виде древних кусков исходников.

Это не метрика, это практика.
Метрикой будет количество часов, потраченных на ревью и количество часов потраченных на багфикс/рефакторинг

По динамике этих метрик можно будет судить о целесообразности код ревью (а то вдруг дешевле джунам фиксить баги, чем заставлять синьоров их ревьювить)

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

Т.е. вы даже учета времени, потраченного на задачу не ведете?

почему не ведём. Ведём, конечно.

Тогда откуда удивление, откуда взять время, потраченное на конкретные задачи?

Паша, Вы ж умный человек.

Делать ревью или нет, «покупать» еще 2 джуна, фиксить ли баги, рефакторить — просчитывается финансово.
Цепочка: ч/ч * на стоимость человека и так по каждому пункту.
Сравнили. Посчитали когда окупится выбранное решение. Реализовали.

Profit.

дык а кто спорит? Я ж просто к тому, что «надо делать так и так» — это не метрика.

Увы, не так все радужно. Ибо статистики по ROI тех же review, которой доверяли бы все стороны, к сожалению, нет.

Про товарища Capers Jones и книгу Software Engineering Economics в курсе, если что. Но, как показывает практика, даже это редко является убедительным аргументом.

Есть два вопроса:

1) Кто будет платить за усилия по сбору и анализу метрик?
2) Достаточно ли зрелая управленческая культура в организации, чтобы доходчиво объяснить разработчикам необходимость, например, заполнять дополнительное поле в багтрекере?

По поводу № 2, я неоднократно встречал противоположную, настолько клиенто-ориетированную культуру в командах, что любые подобные новшества встречались в штыки с аргументами «клиенту это не нужно», «клиент за это платить не будет»

Простите за ответ вопросом на вопрос, но «А кому интересна эффективность разработки?»

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

Заказчик может работать и напрямую с разработчиками, без подрядчиков. Чем-то это лучше для разработчиков и качества кода, чем-то хуже.

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

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

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

аудит проекта — вам эти слова ни о чем не говорят?

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

1. Открываем вики, читаем что такое «аудит»: ru.wikipedia.org/wiki/Аудит
видим слова: «Под техническим аудитом понимают проверку независимыми специалистами системы организации производства, ... применяемых технических и технологических решений...» и т.д.

2. Перекладываем это определение на IT: берём независимых специалистов, т.е. людей, которые не вовлечены в деятельность нашей фирмы. Специалистов своего дела — архитектора и/или аналитика. Как вы их будете искать — это уже другой вопрос. Так вот, они приходят и начинают проверять. А по окончании своих изысканий говорят вам результаты своей оценки и дают рекомендации по улучшению, если таковые есть.

и вот, мы приходим к мысли: что бы мы не делали — это или слишком долго, или слишком дорого, или слишком сложно ) Я же говорю — значит не делайте ничего. Другого же выхода нет? А эта статья — попытка таки разобраться, а вдруг что-то можно сделать — даже не стоит прочтения. Просто сидите и ищите причины «почему нет».

И вот мы пришли к логическому завершению этого разговора, о чем уже было сказано выше:

Его нужно закапывать.
что вы и совершаете, ища причины ничего не делать.

там же написано, что статья имеет продолжение. Ну вот как можно читать кусок материала, а потом говорить — что это всё конь в вакууме и вообще девочка, что ты тут нафантазирована. Не устраивает — не применяйте. Можете сделать лучше — напишите нам развёрнутый материал на 300 страниц, как вы себе видите все эти процессы «не сферического коня». Подробно, с метриками и выкладками, ровно как вы от меня этого требуете.

Никаких резонных возражений кроме «что ты тут придумала» я пока что не услышала. А кричать в ответ «а почему» — я тоже умею.

если будет желание — прочитаете продолжение. Разбивать материал было не моим решением — вопросы в редакцию.

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

ну вы кодревью делали? Чем не аудит чужой деятельности? Уроки ребёнку проверяли? Тоже по своей сути аудит. В чём суть вопроса?

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

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

требуется абсолютная культурность сотрудников
Можно потренировать их на игре в манчкина :)) Если небыло опыта этой игры — просто рекомендую для себя поиграть. Даже могу при желании пригласить поиграть в уютной домашней обстановке. Все равно все закончится «социальной неадекватностью».
проведите консультации со сторонним системным архитектором и аналитиком
Как это предполагается реализовывать.
Такие решения чаще всего (даже не так. читай НИКОГДА) не исходят от разработчиков, а исходят от инвесторов, владельцев бизнеса и.т.д.
Руководство видит проблему: упали продажи, упала посещаемость, не успеваем пилить новую функциональность, частые жалобы на старую функциональность ... индикатором может быть абсолютно любой внешний фактор (реже внутренний, например раздраженный сотрудник).
Теперь что подразумевается под «консультацией со стороны»:
1) Есть компании, которые предоставляют сторонний аудит продукта/процессов/архитектуры. Знаю не по наслышке. В свое время одна из компаний, в которых я работал, заказывала такой аудит со стороны. Да, делался он не один день. «Подрядчики» вникали во все, начиная от бизнес процессов, точек прибыли, архитектуры, постановки задач и.т.д.
Относительно недавно (в течении последнего года) натыкался на человека, который специализировался на code reviw, основал компанию и занимался внешним консультированием как правильно внедрять эту практику у себя в компании. Очень бы хотел сразу дать ссылки на это видео, но найти не могу. Найду — сброшу дополнительным комментарием.
2) «Бен! Это Данила! Ай нид хелп!» © Брат-2
В качестве Бена часто выступает знакомый(-ая), который(-ая) СПЕЦИАЛИСТ (с большой буквы реже) или «специалист» (в кавычках чаще) в требуемой отрасли. Получаем набор советов, что делалось, как, почему, к чему это привело и получив волшебный пендель бежим и нагибаем всех и все на проекте.
Ну, говорю как есть. И такое тоже поголовно у всех было.
3) Гораздо реже, чем предыдущие варианты, но и такое встречалось.
Ищется на самом деле требуемый Специалист, ставятся конкретные задачи, получаются конкретные ответы/решения, договорная оплата, спасибо, разошлись.
Примеры: 3.1) habrahabr.ru/.../AntonShevchuk + Yandex. Результат — yandex-php-library
3.2) youtu.be/dx_6oVFuP8Y — тут @yakov_sirotkin рассказывает пару слов о том, как они в свой проект привлекали Антона Коробейникова (anton.korobeynikov.info) (человек который внес свой вклад в gcc). Хотя видео не об этом. Совсем не об этом, но идею по 3-му пункту оттуда уловить можно.
Примеров тут подобрать можно много. Они имеют место быть. Вернее место быть они имеют не только лишь много. © КличкоМем

И второе:

Т.е. мы сразу предполагаем, что в этой статье будет рассматриваться случай, когда все пропало?
— Шеф, все пропало, все пропало! Гипс снимают, клиент уезжает!
— СПОКОЙНО!
---
Решаем проблемы по мере поступления.
Если в проекте изначально все поставлено на нужные рельсы, то и проблем быть не должно... хотя... господи, ну кому я вру?
Всегда. Опять же в моем опыте. Ну вот всегда. Функционал устаревает. Модуль не расчитан на те нагрузки, под которыми он сейчас работает. Это писал Вася Пупкин, никто не знает как оно работает, а Васи уже нет.
Это я к чему. Возможно Вы правы, но... рано или поздно я ВСЕГДА попадал на проекте в ситуацию «шеф, все пропало!», с какими бы благими намерениями не создавался бы функционал/код/что-то еще — жди, то что ты написал вчера — завтра уже «с душком» (читай пропало!). Этот долбанный мир слишком быстро крутится. Новых технологий слишком много. Эти новые фичи так быстро устаревают. Блин! Пора смириться и быть честным с собой.
/me задумался и ушел медитировать (скоро вернусь).

кстати а о «синдроме второй версии» еще ктото помнит?

разумеется. Но у нас тема другая — когда проект становится колом.

помойму вы меня не поняли. попытка переписать с нуля — это надежный способ превратить проэкт в кол.

ок. Не переписывайте проект. Я же не настаиваю.

холивар из серии — зачем лечить здорового? От лекарств все болезни. А если он уже тяжело болен? Тоже лечить не нужно?

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

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

А по-правде говоря, я уже столько этих отговорок и разглагольствований слышала, лишь бы замять тему и ничего не делать — уже слушать противно. Есть старые проекты, с которыми нужно что-то делать — и точка.
А вы начните слушать (читать) то что вам говорят, а не то что вы себе нафантазировали. В моем комменте нет утверждения что ненужно ничего делать, нет отговорок. (по этому пункту объяснить бессмысленно, посему читайте до просветления).
.
А теперь более важный вопрос:
Как вы заманите хорошего спеца на «безнадежный проект»?

а сами как считаете? Рецепт универсальный: деньги + полномочия.

а сами как считаете?
Если бы я знал, то зачем бы я спрашивал :)
Рецепт универсальный: деньги + полномочия.
В теории, а на практике:
1) У вас денег не хватит. Менеджменту будет сложно объяснить почему мы должны Васе платить в 2-3 раза выше рынка (ибо 20-30% — это недостаточно для многих чтобы разгребать чужое гуано долго)
2) Полномочия — это фейк. Если команда не хочет слушать «нового лидера», результата не будет. А уволить большую часть команды и нанять «профи» — это см пункт № 1.
.
Та и сумарно, ваш рецепт (как и «статья») — это из серии «Я — стратег, а не тактик».

У статьи будет продолжение — это раз.

Кроме того, вы опять начинаете искать сложности в переменах. «Ах, это создаёт столько проблем». И менеджерам объяснять сложно, и вообще никто ниче делать не будет. Да на здоровье. Ничего не делайте, не объясняйте менеджерам. Я ничего против не имею.

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

Менеджменту будет сложно объяснить
автоматически отпадает.

Такие проекты или просто помирают, или же их пытаются реанимировать. К этому моменту менеджмент уже согласен на что угодно.

2) Полномочия — это фейк. Если команда не хочет слушать «нового лидера», результата не будет. А уволить большую часть команды и нанять «профи» — это см пункт № 1.
Подробно рассмотрен в части 2, которая ещё не опубликована )) Ждите продолжения, оно уже написано, лежит в редакции, обещали скоро выпустить.
Рецепт универсальный: деньги + полномочия.
В теории, а на практике
Андерс Хейлсберг (просто оставлю это имя здесь)
Если залезть в гугл можно найти еще больше примеров.
Или, например, такие цифры: «65% компаний переманивают ценных сотрудников у конкурентов»
Богдан, везде есть контр. примеры и универсального нету ничего. В каждой компании будет свой опыт и свои исключения.
адский труд
это именно то, о чем мечтает любой хороший разработчик!

ну он же высокооплачиваемый )

Вы считаете, что

«Неинтересно сопровождать» — это как раз проявление некомпетентности

и тут же задаете мне вопрос

Как вы заманите хорошего спеца на «безнадежный проект»?

Так вот, даю развернутый ответ: хороший специалист в жизни не будет работать в проекте, где ему «неинтересно». Так что «неинтересность сопровождения» былдопроекта — очень даже аргумент. А всё потому, что никто не любит копаться в г*.

Поправлю. Хороший специалист найдет как себя развеселить. Г* - это та штука, в которой таится потенциальная возможность для улучшений.

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

Возможно. Но я говорил не в ключе недоверия. А в том, что такие менеджеры как раз грузят «ценного работника» именно для того, чтобы он эффективно использовал свое время. Как они понимают. Что-то сделано, не надо это трогать. Если на задачу рефакторинга больше полдня, не надо делать. И т.д.

Но по сути да, микроменеджмент.

Я говорил про конкретную вещь, которую замечал на разных работах. Страх, да. Наверное. Это люди, которые понимают управление, как установление рамок, контроль сроков, желая снизить какие-либо проявления планирования у разработчика и заняться этим самим.
Но часто это были не разработчики. Или разработчики, но доверяли тому, что пишешь. Т.е. какого-то контроля по именованию классов или кодревью с их стороны обычно не было. В этом плане доверие. Если сделал, значит хорошо сделал, верим.

Как вы заманите хорошего спеца на «безнадежный проект»?
— Ты умный, ты справишься!
— Я умный, я даже не возьмусь! ©

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

Очевидно: зарплатой и свободой действий.

Почему вдруг хороший специалист будет отказываться от плохого проекта? Мне лично скучно идти на всё готовое и хорошо работающее.

Почему вдруг хороший специалист будет отказываться от плохого проекта?
Потому что хорошему специалосту важно иметь возможность себя реализовать, а разгребание гуана — это сомнительная возможность для самореализации.
Мне лично скучно идти на всё готовое и хорошо работающее.
А что вам не скучно? Идти на все __готовое__, но при этом плохо работающее? Если да, то вы просто человек-находка.

Ну значит я плохой специалист, в вашем понимании. Сколько живу, ни разу не понял эту фразу: реализовать себя. Интерфейс реализовать — понимаю. А себя, не понимаю )) Родители меня уже реализовали.

Шутки шутками, но действительно не ясно. Что должен желать хороший специалист? Поучаствовать в проектах его мечты? А если он делал это и многократно, то что дальше?

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

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

Тестирования скорее всего не будет кроме «менеджер потыкает в кнопки при приёмке новой фичи».

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

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

Я не предполагаю, что требования где-то кроме их реализации в коде есть.

у статьи будет продолжение с раскрытием всех тем. В редакции не отважились все 11 страниц в одной статье выпускать. Ждите.

Продолжение будет завтра утром :))

так лучше?)

звучит как насмешка..

звучит как троллинг

Это 2 принципиально разных момента... «Неинтересно сопровождать» — это как раз проявление некомпетентности (инфантильности)
В большинстве случаев — да. Согласен. Чаще всего проблема «неинтересно» на уровне квалификации разработчика. Гораздо реже — проблема на уровне квалификации менеджемнта.
Сторонний человек не будет обладать всей необходимой информацией о проекте для принятия решения.
Если свои не в состоянии... Есть люди и компании, которые построили серьезный бизнес именно на такого рода консультациях. И первым этапом идет именно сбор информации.
Переписывание с нуля, как правило, просто не работает для проектов которые в продавшее уже давно.
Но и контр примеры же есть: PHP (да, opensource, но было же), VOX, Magento (сейчас пилится вторая версия). Тот же facebook переписал интерфейс групп в 10-ом году с нуля.

Везде (!) нужно смотреть конкретно по ситуации. А для того чтобы небыло

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

а насчет некомпетентности это не так, некомпетентность — это отсутстие необходимых навыков

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

инфантильность... если изначально подписывался гребсти говно, то греби, если нет, то отказ вполне резонный
Это не про не интересно, а про сложно. Поэтому я и сказал что «сложно» — это валидный аргумент.
меня всегда удивляли люди, которые дают прграммисту задачу не связанную с программированием и удивляются чего он противится ее делать
Чуствоетсо «детская трамва». :)
Можно более подробный пример, ибо не совсем понятно что это а задачи такие (в контексте топика).

зачем вы устраиваете холивар и переходите на личности со своими «детскими травмами»? Лишь бы поперёк лежало (в контексте топика, разумеется)?

зачем вы устраиваете холивар и переходите на личности со своими «детскими травмами»?
А зачем вы фантазируете?
Холивар я не устраивал, перехода на личности не было. «Детская травма» использована в смысле «очень негативны и запоминающийся опыт».
Это не про не интересно, а про сложно. Поэтому я и сказал что «сложно» — это валидный аргумент.
говно грести не сложно, вообще сложные задачи крайне редкие
Чуствоетсо «детская трамва». :)
Можно более подробный пример, ибо не совсем понятно что это а задачи такие (в контексте топика).
ну да, было много травм, как и многих наверное
писать никому не нужную спецификацию (писал ее несколько раз из-за изменений в проекте, а ее никто никогда не читал), закончились задачи — не беда проинвестигейти бесплатные хостинги, что-то на компе не работает — сделай сам не трогай админов, тестер не умеет включать программу, которую я в глаза не видел — помоги, напиши программу на языке, которого ты не знаешь тыжпрограммист и т.д.
ну да, было много травм, как и многих наверное
Да, то что перечисленно — это таки совсем не программистские задачи (ну развешо про хостинги, и то с натяжкой). И таки реально бесят, сочувствую и понимаю.
Вот только все это как-то не соотносится с топиком? Или с «инфантильностью» аргумента про неинтересно?

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

с тем что отказываться от неинтересного нормально
Нормально, но на этапе собеседования.
а под неинтересным подразумеваем непрофильный и глупый труд
В такой формулировке согласен. Но по моему определению — это не столько про интересность, сколько про профильность.
Непонимание получилось из-за разности определений:
В моем понимании неинтересное — это профильное, но просто не интересное. Попробую привести пару примеров (наиболее часто встречаемые): реализовать фронт-энд — интересно, а добавлять поддержку для всех браузеров не интересно. Реализовывать бизнесс логику — интересно, а вот ДАО или веб-ендпоинты — не интересно. И все в таком роде.
Нормально, но на этапе собеседования.
а если на этапе собеседования об этом умолчали?
реализовать фронт-энд — интересно, а добавлять поддержку для всех браузеров не интересно. Реализовывать бизнесс логику — интересно, а вот ДАО или веб-ендпоинты — не интересно.
ну если какие-то задачи делать вообще не хочется, то можно попросить тимлида поменяться :) если не хочет/может — надо делать, если почти все не интересно опять же менять работу

ну а вообще не встречались мне такие кто профильную работу на отрез не хотел делать

а если на этапе собеседования об этом умолчали?
Если вы не спросили, то это вам наказание от высших сил :)
Если вы спросили, а вас обманули, то проблема не в «неинтересности», а в том что вас обманули — это уже другая история (к топику отношения не имеет).
ну а вообще не встречались мне такие кто профильную работу на отрез не хотел делать
На отрез — это редкость, а вот «включать дурочку» — такое бывает. Возвращаемся к моему исходному утверждению:
Базар про «хочу/не хочу» — это как раз проявление некомпетентности (инфантильности) в той или иной мере. Если эти хотелки идут в контексте «не хочу впиливать фичу в ту кучу гуана которую вы называете приложением» — это инфантизизм/некомпетентность в очень высокой мере.
При этом не путать предыдущий аргумент с такой (валидной) формулировкой:
«это очень сложно впиливать фичу в ту кучу гуана которую вы называете приложением»

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