Comments 36
Встречался в практике случай, когда систему, написанную в середине двухтысячных "переписывали" на современный стек. С микросервисами, SPA и т.д. При этом всё API, поведение и даже стили должны были остаться неизменными. За этим следила команда усердных и бесконечно терпеливых QA инженеров из Индии. Они просто сравнивали старое и новое приложения и писали отчёты об ошибках, если их поведение различалось.
Трудно себе представить более демотивирующую программиста деятельность, чем такое "переписывание". Это ведь не исправление — это воспроизведение.
Вот только есть проблема. Обосновать переписывание старого проекта и выделение на это ресурсов перед вышестоящим начальством можно. А вот увеличение расходов, связанное с внешне незаметной внутренней миграцией грозит лишь лишением премий в связи с объективным падением эффективности разработки.
Оказывался в ситуации, когда нужно было "воспроизвести". Переписывал старую систему внутрикорпоративной системы учёта и документооборота. Не сказал бы, что это было чем-то демотивирующим. Наоборот, было приятно видеть, как вместо ужасной БД без единого индекса появляется стройная быстрая система. То же самое с клиентским приложением: вместо поделки на Дельфи, в которой надо было указывать с какой по какую строчку таблицы нужны данные, появились нормальные асинхронные model/view таблицы.
Да, о безопасности/разделении прав и речи не шло в старой системе — все решалось в клиенте, а прямыми запросами к СУБД можно было хоть все таблицы дропнуть.
Недавно кажется что аиХабре был перевод статьи разработчика Netscape был такой веб браузер когда мысль о переписывание кода привело к по ере лидирующих позиций. С другой стороны, есть mvp, которое лучше сразу выбросить после проверки идеи. Но очень часто сталкиваюсь с навешивание все больше и больше не функционала на mvp пр вложение так как клиент пр вык получать все недорого.
Переписать их на современный стек не получилось, хотя мы много раз пытались это сделать.
2) 50+ лет баг-тестинга и замороженных стандартов гарантируют, что код на COBOL будет работать.
3) Писать обработку финансовых транзакций на современных высокоуровневых и/или абстрагированных от имплементации языках — отложенный выстрел себе в ногу по абсолютно непрозрачным причинам.
Пока новая версия сделает половину фичь старой системы, в старую систему добавят ещё фичь.
Только полная консервация старой системы и новые фичи только в новую систему! Только хардкор!
<:o)
Несколько раз участвовал в переписывании систем. Это офигенно приятно, особенно если делать с умом и не торопясь. Требования уточнены, команда имеет опыт набитых шишек. В новый проект можно взять классные технологии. Можно с удовольствием обсудить недостатки старой архитектуры и нарисовать новую. Из новой системы выкидываются ненужные фичи. Все разрабы расслаблены и довольны — наступает год чистой инженерии, сиди себе и складывай систему из разноцветных кубиков в условиях определенности.
Возможно, дело в том, что я всегда работал в компаниях с сильными руководителями проекта и влиятельными СТО. Если у СТО слабая воля, и он прогибается под «бизнес», переход будет нервным, будут вот эти глупые требования новых фичей и прочая ерунда.
«Ваша работа в опасности» — это вообще не очень ясный пассаж. Что там может быть в опасности, что самое худшее вообще может произойти?
Мне кажется, стоит ещё учитывать вот какой момент.
Вероятно, многие костыли и 'особенности реализации', которые были в старой системе, были сделаны не просто так. Не все они появились от недостатка времени, иногда это издержки выбранной архитектуры, фреймворка, либо ещё чего.
Если начать переписывать всё по-новому, учитывая все проблемы старой реализации, то непременно появятся новые нюансы.
И тут ситуация может стать ещё хуже чем при первом подходе.
Я сталкиваюсь с новой проблемой, ко мне приходит условный заказчик и спрашивает, когда будет завершено переписывание. С одной стороны, у меня возникла проблема и мне нужно время на решение. С другой стороны, мы же обещали сделать всё по-новому и правильно (и, вероятно, относительно быстро), и проблем при переписывание вроде как быть не должно (по крайней мере, по мнению заказчика, иначе зачем вообще переписывать).
И тут либо опять ставить костыль, либо называть не совсем подходящее решение 'особенностью реализации', либо ещё глубже закапываться в переписывание.
Надеюсь, более-менее удалось донести мысль, достаточно сумбурно получилось)
Хорошо, когда старый продукт ещё достаточно крепок, что позволяет «играть» в реформатора продукта, но не доводить до конца.
Но без переписывания для крупных проектов никак. А переписывать просто что бы переписывать, это тоже плохой подход. В этом небольшая сложность. Особенно если вы работаете в «молодом дружном коллективе» (то есть никто не знает, зачем переписывать, но все горят желанием нарисовать свой велосипед).
Для нормального развития должны сойтись несколько условий: нежадный бизнес (наверное, это главное условие), грамотный архитектор и одновременно руководитель (если не руководитель — «молодые и дружные» убедят начальство писать велосипеды), ну и мотивация, без неё тоже ничего не выйдет. Вот такой примерно должна была бы быть статья. Ну ещё плюс краткое описание проблем долго не модернизировавшихся проектов. Например гугло-ведроид лет через 10 бесконечного мазохизма решили пофиксить новой версией — фуксией (а может лучше фиксией?). И пока они монополисты у создающих этот фикс есть время для тренировок. Но там присутствует всё та же проблема — молодой и дружный коллектив. Не уверен, что они научатся так быстро, что и ось новую создадут и качество будет не велосипедное. Поэтому альтернативные оси всё ещё имеют очень серьёзные шансы для завоевания рынка смартфонов.
Ошибка выжившего. Те, которые стали лучше, никто не обсуждает
Не знаю почему так, но факты говорят за себя. Вот пара статей, где рассказывается о том как сервис переписали и он стал быстрее и масштабируемее:
Там чуть меньше сотни комментариев. А вот статья о том как все плохо набирает в 20 раз больше комментариев, и оказывается у всех на слуху.
Этот долг возникает вполне естественным образом и преследует все сколь бы то ни было успешные системы — когда есть сам продукт, его пользователи, каналы коммуникации с ними. Не важно, продается ли продукт непосредственно, либо же он является вспомогательной частью бизнеса компании, важно то, что он находится в эксплуатации достаточно длительное время. Пользователи хотят получить новую функциональность (возможно, они даже заплатят за это), менеджмент хочет поскорее это пользователям предоставить, потому отдел разработки, находясь под прессингом сроков, реализует необходимые изменения. Процесс повторяется многократно, и рано или поздно кто-то громко скажет — “кажется, у нас долг, возможно технический!”
Как бы возникновение технического долга естественный и видимо неизбежный, по мнению автора, процесс.
А как же эффективные менеджеры? Они разве не за это деньги получают, чтобы это не случилось?
Они выделели на появление новых фич необходимые ресурсы: человеческие, технические, временные?
Они слушали что им говорили ведущие разработчики о возможности/невозможности реализации хотелок пользователей и начальства в требуемые сроки?
Скорее всего менеджеры были озабочены своими процессами и показателя, дающими возможность выписывать немалые бонусы.
А для этого да, надо показывать некий великий рост продукта.
И когда этот рост несоразмерен с реальными техническими возможностями команды, внутрь кода или продукта закладываются те самые решения, которые рано или поздно его взорвут.
Ведущие специалисты, видя несоразмерность объемов работы реалиям, так или иначе уйдут с проекта (или забьют на свою ведущую роль что еще хуже) и нарушится “кристалическая решетка проекта”. Пропали узлы которые контролировали части проекта в смысле качества кода и своевременности перехода на новые технические решения.
И всё, дальше покатилось по наклонной. Какие проблемы накапливаются потом написано достаточно подробно.
Чем раньше это понять и начать ловить ситуацию, тем меньший ущерб надо гасить.
Но из статьи напрашивается вывод, что это ущерб созданный технарями, исполнителями.
Если вы это слышите, либо же это вы произносите, то знайте — ваш проект, ваша работа в большой опасности.
Дело в том, что согласие на переписывание — крайняя мера, когда другие, вроде бы, уже невозможны — так считают и такую версию принимают участники процесса.
А может быть это просто неизбежный этап, создание новой “кристалической решетки” проекта?
Новые люди берут на себя ответственность за новые технические решения. Как иначе дать человеку ответственность за некую часть проекта, но не дать возможность реализовать это так, как он считает технически обоснованным?
… автор не говорит бладаря чему этот технический долг появляется.
Говорит, но чуть ниже по тексту:
Технический долг же — это сумма накопленных, но не согласованных в рамках системы изменений, сумма не упорядоченных между собой артефактов эволюции, которая и приводит к экспоненциальному нарастанию сложности, о которой говорилось выше.
На моей памяти нет ни одного успешного переписывания. Результат обычно потерянное время и клиенты. А изменения сделанные могут много лет вылезать то здесь то там усложняя жизнь всем.
По молодости сам придерживался мнения, что если плохо, то надо все переписать с нуля, будет лучше :) Став постарше понял, что реально работающий код прямо сейчас, имеет гораздо большую ценность, нежели некий идеальный в будущем :)
На самом деле в статье хороший отсыл в детство — неполучилось, разломать, и начать заного.
Последний эксперимент переписывание небольшого, но важного модуля: уступил напору молодых, ну и хотел посмотреть будут ли выполнены обещания. Обещания: 3 месяца — базовый функционал, 6 месяцев продакшен. Ужас в QA, от обилия новых багов. Результат базовый функционал примерно 4 месяца, продакшен — 1.5 года. Объем кода вырос на порядок. Скорость внесения новых изменений — не увеличилась.
Значительно более успешный подход, это рефакторинг существующих компонент. Причем не преписвание "с нуля", а по частям.
В общем думаю проблема плохого кода слегка преувеличина. И просто хочется быть творцом, а не убирать за кем-то. И в этом многие потакают разработчикам.
Потому что для начала за стол садится «команда» из менеджеров и разработчиков, где обсуждаются следующие вопросы:
-есть ли у команды опыт переписывания с нуля проекта на 1000000+ строк кода? Ну, хоть у кого-нибудь? Можно даже неудачный?
-есть ли в команде толковые архитектор и бизнес-аналитик?
Если на оба вопроса звучит уверенное «нет», то это очень серьёзный повод задуматься, что вы в принципе не готовы к данной работе.
Если всё-таки принято решение двигаться дальше, то в следующем раунде за тем же столом должны собраться «команда» и владельцы бизнеса, чтобы обсудить следующие вопросы:
1. Зачем это нужно бизнесу? Что это даст на выходе? Какие риски?
Автор конечно даёт ответы, но сугубо технические, а они нужны в понятных для бизнеса метриках, очень утрируя: «в итоге клиентская база у нас будет расти на писят процентов в год».
2. Сколько времени это займёт?
На этом этапе озвученные разработчиками сроки даже не можно, а нужно умножать не на 2-3 как обычно, а на все пять.
3. Сколько это будет стоить?
А к этому вопросу подготовиться будет ещё сложнее, чем к первым двум. А для людей, которые эти самые деньги платят — он чуть не самый важный и именно через эти суммы будут оцениваться ответы на первый вопрос.
Если после этого все стороны твёрдо уверены, что «да, переписываем», то переходим к следующему раунду.
В котором за столом сидит команда и владельцы бизнес-процессов, хотя бы ключевых.
Первый вопрос тут тот же самый: объяснить, что они с этого будут иметь, какие риски их ожидают, например, готовы ли они на этапе внедрения работать в двух системах, как это частенько бывает и вот это вот всё.
Второй — а что мы вам собираемся предложить? Упрощённо существует две модели а) мы делаем в новом технологическом стеке систему, максимально приближенную к существующей или б) делаем всё по-новому, грубо говоря, были winforms, а у нас будет веб-клиент. А это опять же, риски и деньги — во втором случае придётся переучивать весь персонал/клиентов, например. Готовы ли они к этому?
Результаты этих переговоров (в общем-то всех надо бы, но вот эти просто обязательно) надо письменно зафиксировать на всех уровнях. И ещё не исключено, что на обе эти модели придётся склепать MVP и с совершенно не нулевой долей вероятности услышать в ответ «идите нафиг, нам и здесь хорошо».
Если и после этого «двигаемся дальше», то возвращаемся к первой стадии и ещё раз всё вдумчиво проговариваем и фиксируем договорённости.
Тут ещё надо понимать, что вот это всё в зависимости от очень многих факторов может занять не иллюзорно так времени. Полгода — считайте сильно повезло, серьёзно.
Дальше мы уже пишем код? А вот и нет. Дальше мы формируем проектную команду.
Архитектор и бизнес-аналитик. Сразу говорю, что скорее всего их придётся искать со стороны. И ещё надо понимать, что архитектор и БА это представители менеджмента, а не разработки.
Потому что отдавать архитектуру на откуп текущей команде разработки — это значит гарантированно загубить всю работу, потому что они начнут тянуть новомодные технологии, языки, фреймворки и блаблабла, в чём было бы интересно поковыряться и подкачаться, собственно у автора это всё как раз и расписано, в общем так делать совсем нельзя. Архитектор делает технический аудит существующей системы и предлагает новый оптимальный технологический стек. И вот тут запросто может выясниться, что существенная часть текущей команды к этому и не готова. То есть им либо нужно время (которое деньги) на вхождение, либо они вообще не захотят. У меня был реальный пример в подобном проекте, когда два сотрудника по рабочей системе наотрез отказались переучиваться в предложенные новые технологии. И вот что делать? Текущую систему поддерживать тоже надо, кто их направления на себя возьмёт? А новый код кто писать будет? И не надо про «чтобы было удобно всем», недовольные будут всегда.
Про работу БА до начала разработки даже не буду начинать писать, выдохся уже немного по части количества букв. Могу только отметить, что если
И ещё в обязательном порядке должны быть в живом контакте с командой те самые владельцы (или их представители) ключевых бизнес-процессов, причём крайне заинтересованные в том, что вы делает. Без них тоже крайне не рекомендуется начинать.
В общем, с момента «благая весть» прошёл уже как самый минимум год и возможно мы вот-вот наконец-то приступим непосредственно к программированию. Возможно.
Это всё красиво на словах и когда нет других проблем. Но если есть проблемы? Обычно это конкуренты. У них новая версия продукта ХХХ, новые модные фичи, куча рекламы, народ ведётся и переходит к ним. Что делать? А давайте сделаем такие же новые фичи! Задаём вопрос разработчикам — сколько времени? Ответ — ну где-то год. То есть в реальности года три. И вот тут надо бы уже что-то делать, а времени нет. Конкурент вытесняет, и за три года может вообще выбросить с рынка. В такой ситуации пить Боржоми уже поздно.
Поэтому и нужно вкладываться заранее. Но время обычно течёт плавно, изменений немного, поэтому кажется, что вроде бы и незачем. Потому что конкурент ещё не проявился. А когда проявится — будет поздно. Но в результате проект развивается по старой закостеневшей схеме, никто не думает о его модифицируемости, скорость внедрения фич более или менее устраивает. Только это скорость «мирного времени». Когда же придёт война — в наличии будет только то, что запасли в мирное время. И вот в это мирное время всё же иногда надо находить деньги для выплаты страховой компании «красивый код». Не каждый год, может раз в 10 лет, но надо. Плюс иметь запас генералов. То есть если правильного генерала нет во время войны — вы проиграли. Но откуда он возьмётся, если его не готовили до войны? Вот пускай он в мирное время в качестве учений улучшает покомпонентно (с минимальной болью) текущую систему. И показывает повышение скорости внедрения фич, например.
В целом аналогия с армией вполне уместна и наглядна. Иначе как армяне недавно — тоже били себя пяткой в грудь, мол «можем повторить», а оказалось, что ни генералов, ни других нужных военных спецов у них не нашлось, а запасов нужной техники и подавно.
Хотя можно надеяться на отсутствие серьёзных проблем длительное время (на наш век хватит). Но «это несерьёзно» (с).
Ну ладно. Есть же MVP, есть болезни роста и технический долг.
Если есть точная оценка, что вот эта часть функционала нам полезна, но существущий стек поддерживать дороже чем написать заново, то переписывание имеет место быть.
Иначе — планомерный плановый рефакторинг.
Все остальное — беды плохой оценки и планирования. Ну или по деньгам получается что и так сойдёт.
“Важно помнить, что если вы начинаете все с начала, то нет ни единого основания предполагать, что у вас получится сделать свою работу лучше, чем вы сделали ее в первый раз”
Очень странный пассаж. Оглядываясь назад, я вижу, что многие прошлые проекты сейчас я бы сделал гораздо лучше. Это же абсолютно нормально, что люди учатся, приобретают опыт. У нас вот был выбран весьма странный подход: "давайте наберём студентов, и они перепишут систему". Они, дескать, не будут повторять ошибки "стариков". Они даже и не повторили. Внесли свои. Ну кто бы мог подумать, что надо заботиться о конкуренции доступа? Ой, тут ещё и последовательность действий роль играет! Беда-беда! О, свежая идея — давайте веб-интерфейс будет заниматься бизнес-логикой!
По мне, желание сделать по-новой — это нормально! Правильнее переклеить обои, чем тщательно устранять неизбежные дефекты при эксплуатации (потёртости у выключателей, задиры, царапины, следы животных, выбоины, выцветание).
Интересно, откуда у этого никудышного коллектива такой сложный продукт взялся?
По-разному бывает. Но основная причина в том, что коллектив не справляется на длинной дистанции, а не на короткой. И тут уже не особо важно, откуда взялся проект — или его этот же коллектив написал, или приняли от предыдущей команды. Важно как раз то, и на чем делался акцент, что удержание проекта в адекватном состоянии требует постоянных усилий.
Что мешает поступить следующим образом:
— Зафиксировать текущее состояние продукта в части фичеобразования.
— Сформулировать требования и новую архитектуру. Выбрать стек. Оценить затраты.
— Перевести законсервированный продукт в режим «только тех.поддержка и ничего более».
— Протестировать клиентуру на предмет наличия желающих выступить первопроходцами, пообещать пряников.
— Запустить разработку новой платформы на ограниченном контингенте. Здесь можно уже и Agile включать.
— В какой-то момент запустить миграцию клиентов.
— Вывести из работы старый продукт, полностью переключится на новую платформу.
Зафиксировать текущее состояние продукта в части фичеобразования.Зачастую это невозможно. Продукту нужно постоянное развитие, иначе клиенты уходят к вашим конкурентам. Только если вы монополист или плевать на всех.
Сформулировать требования и новую архитектуру.Невозможно. Как я писал в статье — в фирме никогда и никто не знает, как работает продукт во всех деталях. Если у вас есть четкие спецификации на ВЕСЬ функционал и вы не отходите от них ни на шаг — тогда еще что-то возможно. Но в реальном мире у вас будет лишь референсная реализация — собственно, ваш работающий продукт. И при переписывании вы вынуждены будете повторить все его недостатки.
Перевести законсервированный продукт в режим «только тех.поддержка и ничего более».Невозможно. См. первый пункт.
В какой-то момент запустить миграцию клиентов.И просто утонуть в фидбеке о том, насколько новый продукт не соответствует ожиданиям. Пример кинопоиска, кстати.
Вывести из работы старый продукт, полностью переключится на новую платформу.В реальности происходит миграция обратно.
Все это я видел на своем собственном опыте. Sounds good, doesn't work. Все, что можно себе позволить — медленно и кусками двигать проект из состояния «сейчас» в состояние «как бы мы хотели». Переделать UI, оставив бекенд. Переделать бекенд, оставив интерфейс API, поменять базу не меняя бекенда и так далее.
Еще раз повторюсь — у меня есть удачный и неудачный опыт. Удачный опыт всегда связан с медленными изменениями на живом проекте. Неудачный — всегда с переписыванием с 0.
Продукту нужно постоянное развитие, иначе клиенты уходят к вашим конкурентам.
Если код съедает себя сам, и команда барахтается в поверхностном допиле, то клиенты и так уходят к конкурентам.
Но в реальном мире у вас будет лишь референсная реализация — собственно, ваш работающий продукт. И при переписывании вы вынуждены будете повторить все его недостатки.
Если кто-то поставил вопрос «о переписывании», значит кто-то сформулировал недостатки. Если под «референсной реализацией» понимается интерефейс и логика, то вопрос внутренней реализации продукта вторичен. Интерфейс и логику можно натянуть на любой язык программирования, важнее архитектура продукта.
И просто утонуть в фидбеке о том, насколько новый продукт не соответствует ожиданиям.
В этом случае я делал оговорку про первопроходцев. Миграцию, я подразумевал, не одномоментную.
В реальности происходит миграция обратно.
И это нормально. Возможных причин много: команда слаба в разработке, функционал не тестили на юзерах, завышенные технические ожидания от нового стёка, новые фичи юзерам пофиг, им нужнее адекватная поддержка и пр. Главное вовремя принять решение об откате, а не вступить в новую платформу. Сделать выводы и «медленно и кусками двигать проект». А возможно, и продать продукт пока он имеет клиентскую базу и работоспособен.
Почему проекты переписываются и почему это не удается