Почему проекты переписываются и почему это не удается

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

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


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


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


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


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


    Кризис


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


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


    Плотину срывает — инженерами на стол выкладываются неопровержимые доказательства того, что дальше так нельзя и вот почему:


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

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


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


    Звук победных фанфар раздается в сознании инженера ровно в момент произнесения фразы “сколько времени вам потребуется на переписывание?”. Победа! Конечно, 100% времени никто не сможет выделить — нужно поддерживать старое, может сделать какие-то небольшие изменения, и все же доделать вот то, что начато. Но это уже не имеет значения, как и общая оценка необходимых ресурсов, как и то, в каких пропорциях будет разделена работа между старым и новым — 50/50, 60/40, треть и две трети. В этот момент случается один из важных и опасных фазовых переходов в сознании — существующая система начинает считаться временной, соответственно, временными выглядят и неудобства по работе над ней.


    Благая весть


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


    Если вы это слышите, либо же это вы произносите, то знайте — ваш проект, ваша работа в большой опасности.


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


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


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


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


    Сложности


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


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


    Одну из частей этой сложности, зачастую неосознанную и незримую, представляет собой контекст взаимодействия людей с системой. Скажу проще — в подавляющем большинстве случаев, в компании нет ни одного сотрудника, который знает, как работает их программный продукт. Эти знания либо слишком общие и высокоуровневые, либо слишком локальные и частные. Кое-где вообще Terra incognita, потому что написавший ее человек уже уволился. Кто-то просто что-то забыл, например, что именно это место в коде было сделано потому, что какой-то конкретный клиент (с которым уже не работают) просил о подобных изменениях. Кто-то из отдела поддержки использует старую, не документированную возможность какой-то части системы, чтобы добыть отсутствующие данные для отчета. Но это еще цветочки, по сравнению с тем, что творится у пользователей.


    Вы не знаете, не можете знать того, как пользователи взаимодействуют с продуктом. Как они обходят ограничения. Какая функциональность используется, а какая нет. Куда они нажимают, с помощью чего они работают с вашим публичным API. Изобретательность людей по ту сторону http-соединения поистине безгранична. Мой любимый пример — клиент нашей платформы, по каким-то причинам не дождавшись того, чтобы определенные данные появились в offline-отчетах, с помощью кого-то написал Selenium-скрипты, которые вытаскивали нужные данные с UI, чтобы потом присовокупить их к отчетным. С этого момента разметка страницы стала не документированным, но публичным API.


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


    Падение


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


    1. не справились со сложностью ведения точно такого же проекта, и не осознали этого
    2. не обладают всеобъемлющим знанием контекста

    Может ли у них что-то получиться? В каких-то случаях да — на короткой дистанции в пару месяцев это может и будет возможно. Другой вопрос — как быстро технический долг накопится вновь, ведь люди вокруг все те же. Как об этом писал Джоель Спольски в своей статье “Вещи, которые вы никогда не должны делать”: “Важно помнить, что если вы начинаете все с начала, то нет ни единого основания предполагать, что у вас получится сделать свою работу лучше, чем вы сделали ее в первый раз”. А уж если мы говорим о длинных марафонских дистанциях, то тут вступают в игру осложняющие факторы, начиная от “Эффекта второй системы” Брукса, заканчивая простым фактом того, что переписывающим нужно бежать очень быстро, чтобы догонять постоянно удаляющуюся цель — зачастую, в “старую” систему продолжают вносить изменения в то время, как пишется новая. Хватит ли ресурсов команды, чтобы вести разработку двух продуктов сразу?


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


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


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


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


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


    Поток


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


    Позитивный опыт, накопленный индустрией, говорит нам о том, что код — довольно податливый материал. Тут показательна история Twitter, который был плавно, в несколько этапов, перенесен между технологиями, без простоев и вместе со всеми своими пользователями и их данными, причем незаметно для последних. Были заменены подсистемы поиска, рендеринг страниц, хранилище данных и другие компоненты. И вот платформа, начавшаяся как приложение Ruby on Rails, теперь работает в основном на JVM, по пути полностью сменив архитектуру. Пример более чем впечатляющий.


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


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


    P.S.


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

    Комментарии 29

      +2

      Встречался в практике случай, когда систему, написанную в середине двухтысячных "переписывали" на современный стек. С микросервисами, SPA и т.д. При этом всё API, поведение и даже стили должны были остаться неизменными. За этим следила команда усердных и бесконечно терпеливых QA инженеров из Индии. Они просто сравнивали старое и новое приложения и писали отчёты об ошибках, если их поведение различалось.


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


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

        0

        Оказывался в ситуации, когда нужно было "воспроизвести". Переписывал старую систему внутрикорпоративной системы учёта и документооборота. Не сказал бы, что это было чем-то демотивирующим. Наоборот, было приятно видеть, как вместо ужасной БД без единого индекса появляется стройная быстрая система. То же самое с клиентским приложением: вместо поделки на Дельфи, в которой надо было указывать с какой по какую строчку таблицы нужны данные, появились нормальные асинхронные model/view таблицы.
        Да, о безопасности/разделении прав и речи не шло в старой системе — все решалось в клиенте, а прямыми запросами к СУБД можно было хоть все таблицы дропнуть.

          0

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

        +1

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

          0
          В банках и сейчас существует большое количество программных модулей написаны на COBOL. С ними присутствуют все те же проблемы, которые описал автор в статье — нет специалистов, никто не знает как это работает и т.п.
          Переписать их на современный стек не получилось, хотя мы много раз пытались это сделать.
            0
            Ну а почему не получилось-то? Не сведений в деталях, как старое работает и что делает?
              0
              1) COBOL хорош для того, что он делает — обрабатывает миллиарды транзакций в день.
              2) 50+ лет баг-тестинга и замороженных стандартов гарантируют, что код на COBOL будет работать.
              3) Писать обработку финансовых транзакций на современных высокоуровневых и/или абстрагированных от имплементации языках — отложенный выстрел себе в ногу по абсолютно непрозрачным причинам.
            +2
            Проблема переписывания, это как апория об «Ахиллесе и черепахе».
            Пока новая версия сделает половину фичь старой системы, в старую систему добавят ещё фичь.
            Только полная консервация старой системы и новые фичи только в новую систему! Только хардкор!
            <:o)
              +4

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


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

                +1

                «Ваша работа в опасности» — это вообще не очень ясный пассаж. Что там может быть в опасности, что самое худшее вообще может произойти?

                  0
                  Самое опасное тут — это энтузиазм. Не буду приводить известную картинку «Новый проект — сразу сделаю все правильно!», но именно такая слепая уверенность в том, что мы теперь умные и перепишем все как надо, и является основной опасностью. Наоборот, по второму разу надо быть куда осторожнее в предположениях, обещаниях и прогнозах, иначе есть шанс снова прочихать все ресурсы с еще худшим результатом.
                  +4

                  Мне кажется, стоит ещё учитывать вот какой момент.
                  Вероятно, многие костыли и 'особенности реализации', которые были в старой системе, были сделаны не просто так. Не все они появились от недостатка времени, иногда это издержки выбранной архитектуры, фреймворка, либо ещё чего.
                  Если начать переписывать всё по-новому, учитывая все проблемы старой реализации, то непременно появятся новые нюансы.
                  И тут ситуация может стать ещё хуже чем при первом подходе.
                  Я сталкиваюсь с новой проблемой, ко мне приходит условный заказчик и спрашивает, когда будет завершено переписывание. С одной стороны, у меня возникла проблема и мне нужно время на решение. С другой стороны, мы же обещали сделать всё по-новому и правильно (и, вероятно, относительно быстро), и проблем при переписывание вроде как быть не должно (по крайней мере, по мнению заказчика, иначе зачем вообще переписывать).
                  И тут либо опять ставить костыль, либо называть не совсем подходящее решение 'особенностью реализации', либо ещё глубже закапываться в переписывание.


                  Надеюсь, более-менее удалось донести мысль, достаточно сумбурно получилось)

                    +2
                    Наша компания прошла путь переписывания одного продукта около 5 раз. Все неудачны. Разные подходы, языки и команды.
                    Хорошо, когда старый продукт ещё достаточно крепок, что позволяет «играть» в реформатора продукта, но не доводить до конца.
                      +1
                      Статья затянутая, много воды ни о чём.

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

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

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

                        +1
                        Интересно, есть ли вообще примеры когда большое работающее ПО переписывалось с нуля и становилось лучше? Я могу вспомнить только примеры когда становилось хуже.
                          +1

                          Ошибка выжившего. Те, которые стали лучше, никто не обсуждает

                            0
                            Почему никто их не обсуждает? Должен же на всём белом свете быть хоть один такой пример, явно же не засекреченная информация.
                        +2
                        При достаточно глубоком и подробном анализе кризиса, вызванного техническим долгом, автор не говорит бладаря чему этот технический долг появляется.

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

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

                        А как же эффективные менеджеры? Они разве не за это деньги получают, чтобы это не случилось?

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

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

                        Ведущие специалисты, видя несоразмерность объемов работы реалиям, так или иначе уйдут с проекта (или забьют на свою ведущую роль что еще хуже) и нарушится “кристалическая решетка проекта”. Пропали узлы которые контролировали части проекта в смысле качества кода и своевременности перехода на новые технические решения.
                        И всё, дальше покатилось по наклонной. Какие проблемы накапливаются потом написано достаточно подробно.
                        Чем раньше это понять и начать ловить ситуацию, тем меньший ущерб надо гасить.

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

                        Если вы это слышите, либо же это вы произносите, то знайте — ваш проект, ваша работа в большой опасности.

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


                        А может быть это просто неизбежный этап, создание новой “кристалической решетки” проекта?
                        Новые люди берут на себя ответственность за новые технические решения. Как иначе дать человеку ответственность за некую часть проекта, но не дать возможность реализовать это так, как он считает технически обоснованным?

                          0
                          … автор не говорит бладаря чему этот технический долг появляется.

                          Говорит, но чуть ниже по тексту:
                          Технический долг же — это сумма накопленных, но не согласованных в рамках системы изменений, сумма не упорядоченных между собой артефактов эволюции, которая и приводит к экспоненциальному нарастанию сложности, о которой говорилось выше.
                            +1
                            На мой взгляд это определение технического долга, а не объяснение в результате чего эти артефакты эволюции появились.
                              0
                              Весь абзац, откуда взята цитата, посвящен именно этому.
                          +2

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


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


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


                          Последний эксперимент переписывание небольшого, но важного модуля: уступил напору молодых, ну и хотел посмотреть будут ли выполнены обещания. Обещания: 3 месяца — базовый функционал, 6 месяцев продакшен. Ужас в QA, от обилия новых багов. Результат базовый функционал примерно 4 месяца, продакшен — 1.5 года. Объем кода вырос на порядок. Скорость внесения новых изменений — не увеличилась.


                          Значительно более успешный подход, это рефакторинг существующих компонент. Причем не преписвание "с нуля", а по частям.


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

                            0
                            Потому что вот так, как у автора — оно успешным и не получится, это сразу же дорога в никуда.
                            Потому что для начала за стол садится «команда» из менеджеров и разработчиков, где обсуждаются следующие вопросы:
                            -есть ли у команды опыт переписывания с нуля проекта на 1000000+ строк кода? Ну, хоть у кого-нибудь? Можно даже неудачный?
                            -есть ли в команде толковые архитектор и бизнес-аналитик?
                            Если на оба вопроса звучит уверенное «нет», то это очень серьёзный повод задуматься, что вы в принципе не готовы к данной работе.
                            Если всё-таки принято решение двигаться дальше, то в следующем раунде за тем же столом должны собраться «команда» и владельцы бизнеса, чтобы обсудить следующие вопросы:
                            1. Зачем это нужно бизнесу? Что это даст на выходе? Какие риски?
                            Автор конечно даёт ответы, но сугубо технические, а они нужны в понятных для бизнеса метриках, очень утрируя: «в итоге клиентская база у нас будет расти на писят процентов в год».
                            2. Сколько времени это займёт?
                            На этом этапе озвученные разработчиками сроки даже не можно, а нужно умножать не на 2-3 как обычно, а на все пять.
                            3. Сколько это будет стоить?
                            А к этому вопросу подготовиться будет ещё сложнее, чем к первым двум. А для людей, которые эти самые деньги платят — он чуть не самый важный и именно через эти суммы будут оцениваться ответы на первый вопрос.
                            Если после этого все стороны твёрдо уверены, что «да, переписываем», то переходим к следующему раунду.
                            В котором за столом сидит команда и владельцы бизнес-процессов, хотя бы ключевых.
                            Первый вопрос тут тот же самый: объяснить, что они с этого будут иметь, какие риски их ожидают, например, готовы ли они на этапе внедрения работать в двух системах, как это частенько бывает и вот это вот всё.
                            Второй — а что мы вам собираемся предложить? Упрощённо существует две модели а) мы делаем в новом технологическом стеке систему, максимально приближенную к существующей или б) делаем всё по-новому, грубо говоря, были winforms, а у нас будет веб-клиент. А это опять же, риски и деньги — во втором случае придётся переучивать весь персонал/клиентов, например. Готовы ли они к этому?
                            Результаты этих переговоров (в общем-то всех надо бы, но вот эти просто обязательно) надо письменно зафиксировать на всех уровнях. И ещё не исключено, что на обе эти модели придётся склепать MVP и с совершенно не нулевой долей вероятности услышать в ответ «идите нафиг, нам и здесь хорошо».
                            Если и после этого «двигаемся дальше», то возвращаемся к первой стадии и ещё раз всё вдумчиво проговариваем и фиксируем договорённости.
                            Тут ещё надо понимать, что вот это всё в зависимости от очень многих факторов может занять не иллюзорно так времени. Полгода — считайте сильно повезло, серьёзно.
                            Дальше мы уже пишем код? А вот и нет. Дальше мы формируем проектную команду.
                            Архитектор и бизнес-аналитик. Сразу говорю, что скорее всего их придётся искать со стороны. И ещё надо понимать, что архитектор и БА это представители менеджмента, а не разработки.
                            Потому что отдавать архитектуру на откуп текущей команде разработки — это значит гарантированно загубить всю работу, потому что они начнут тянуть новомодные технологии, языки, фреймворки и блаблабла, в чём было бы интересно поковыряться и подкачаться, собственно у автора это всё как раз и расписано, в общем так делать совсем нельзя. Архитектор делает технический аудит существующей системы и предлагает новый оптимальный технологический стек. И вот тут запросто может выясниться, что существенная часть текущей команды к этому и не готова. То есть им либо нужно время (которое деньги) на вхождение, либо они вообще не захотят. У меня был реальный пример в подобном проекте, когда два сотрудника по рабочей системе наотрез отказались переучиваться в предложенные новые технологии. И вот что делать? Текущую систему поддерживать тоже надо, кто их направления на себя возьмёт? А новый код кто писать будет? И не надо про «чтобы было удобно всем», недовольные будут всегда.
                            Про работу БА до начала разработки даже не буду начинать писать, выдохся уже немного по части количества букв. Могу только отметить, что если у вас нету тёти если его у вас нет и некого назначить крайним, то искать вы его будете долго, реально толковых БА в масштабе РФ крайне мало.
                            И ещё в обязательном порядке должны быть в живом контакте с командой те самые владельцы (или их представители) ключевых бизнес-процессов, причём крайне заинтересованные в том, что вы делает. Без них тоже крайне не рекомендуется начинать.
                            В общем, с момента «благая весть» прошёл уже как самый минимум год и возможно мы вот-вот наконец-то приступим непосредственно к программированию. Возможно.
                              0
                              Ваш посыл сводится к одному — семь раз отмерь, один отрежь.

                              Это всё красиво на словах и когда нет других проблем. Но если есть проблемы? Обычно это конкуренты. У них новая версия продукта ХХХ, новые модные фичи, куча рекламы, народ ведётся и переходит к ним. Что делать? А давайте сделаем такие же новые фичи! Задаём вопрос разработчикам — сколько времени? Ответ — ну где-то год. То есть в реальности года три. И вот тут надо бы уже что-то делать, а времени нет. Конкурент вытесняет, и за три года может вообще выбросить с рынка. В такой ситуации пить Боржоми уже поздно.

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

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

                              Хотя можно надеяться на отсутствие серьёзных проблем длительное время (на наш век хватит). Но «это несерьёзно» (с).
                            +1

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

                              0

                              “Важно помнить, что если вы начинаете все с начала, то нет ни единого основания предполагать, что у вас получится сделать свою работу лучше, чем вы сделали ее в первый раз”
                              Очень странный пассаж. Оглядываясь назад, я вижу, что многие прошлые проекты сейчас я бы сделал гораздо лучше. Это же абсолютно нормально, что люди учатся, приобретают опыт. У нас вот был выбран весьма странный подход: "давайте наберём студентов, и они перепишут систему". Они, дескать, не будут повторять ошибки "стариков". Они даже и не повторили. Внесли свои. Ну кто бы мог подумать, что надо заботиться о конкуренции доступа? Ой, тут ещё и последовательность действий роль играет! Беда-беда! О, свежая идея — давайте веб-интерфейс будет заниматься бизнес-логикой!

                                0
                                Тут речь у Спольски идет скорее о том, что если вы не смогли удержать ведение проекта на протяжении последнего (сравнительно продолжительного) времени, то, скорее всего, у вас не получится этого сделать и при переписывании. Рекомендую прочитать статью по ссылке.

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

                              Самое читаемое