Comments 22
Есть мнение, что бизнес склонен полностью игнорировать накапливающийся технический долг, моральное устаревание системы и тот факт, что с какого-то момента расходы не её развитие начинают расти экспоненциально. В результате бизнес получает свои доходы с устаревающей системы, но эти доходы непрерывно падают, а потом оказывается, что у бизнеса уже нет денег на переход на новую систему. А всё потому, что на падение доходов бизнес отвечал ростом скидок, увеличением рекламных расходов, расширением штата продажников при уменьшении расходов на разработку и прочими не техническими мерами. Но так как продукт не совершенствуется, то клиентская база всё равно падает. А потому примерно совершенно всегда через условные пять лет оказывается, что денег и времени на разработку с ноля нет, так как текущие совершенно фантастические (иногда даже растущие) обороты уходят на то, чтобы вывести имеющееся старьё хотя бы в безубыток. В результате проект хиреет и медленно умирает. А на его место приходят те, кто написан аналог с ноля, использовав при этом 10% годового бюджета обанкротившегося конкурента. И все очень сильно удивляются, что стартап похоронил очередного мамонта.
Короче, бизнес не хочет вникать в техническую часть, неверно оценивает перспективы и совершенно всегда предпочитает реагировать на изменения нетехническими бизнес-мерами, котороые только ухудшают ситуацию.
И ещё бизнес очень не любит думать о том, откуда вообще берутся новые лидеры рынка, если ещё недавно на их месте были монстры с огромными бюджетами, которые с точки бизнеса всё делали совершено правильно. Последний момент особенно забавен, так если менеджерам и управленцам показывать историю развития любого из ушедших лидеров, то они с точки зрения бизнеса одобрят каждый сделанный шак и каждое принятое решение. Но если потом показать, что в результате компания тихо мирно умерла и ушла с рынка, то будет некоторый шок. Но выводов сделано не будет, так как техническая часть, являвшаяся источником проблемы, лежит вне понимания принимающих решения.
Интересная у вас мысль. Думаю, описанная ситуация не редкость, но точно и не единственно возможная. Я больше за то, чтобы рассматривать каждую ситуацию индивидуально, чем делать общие выводы, что менеджер/бизнесмен плохой или недальновидный, а технарь молодец. К своему сожалению, я видел немало проектов, где именно низкая техническая экспертиза команды приводила продукт к коллапсу.
Ну, из моего опыта по мере роста компания всегда скатывается в лютую бюрократию, которая активно играется в корпоративный бизнес, полностью теряя обратную связь от технической команды. Иногда это происходит позже, но, по-моему, происходит всегда. И есть мнение, что это неизбежно, так как качества "хорошего" корпоративного управленца предполагают концентрацию на агрессивном развитии с постановкой задач разработчикам и вообще не предполагают получение фидбека.
Воистину так и есть. А причина простая: если бы бизнес думал о техническом долге, то он бы не "поднялся". "Переобуться" же после роста практически нереально: чем лучше развивался бизнес, тем сильнее владельцы уверены, что агрессивная политика есть наилучшее решение (а технари только мешают).
У всего этого есть вывод: технарям лучше идти работать в ту контору, где программирование является основным видом деятельности. Что до остальных: обращайтесь в конторы из предыдущего предложения.
моральное устаревание системы и тот факт, что с какого-то момента расходы не её развитие начинают расти экспоненциально
Это такой скользкий вопрос, на который нет и не может быть единого ответа. Где-то расходы на поддержание легаси начинают расти экспоненциально. Где-то начинают расти линейно. Где-то легаси безболезненно модернизируется и после фейслифтинга живёт долго и счастливо. Где-то модернизируется дорого и болезненно. Где-то наоборот, новая система не в состоянии догнать старую по накопленному функционалу, и с треском хоронит бизнес, который преспокойно жил бы и развивался, если бы не ломал накопленный опыт.
И ещё бизнес очень не любит думать о том, откуда вообще берутся новые лидеры рынка,
99% бизнеса — это нифига не ИТ-компании, не финтех и не поставщики контента. У них нет такой проблемы, что в один прекрасный момент просыпается молодой стартап и всех стариков съедает.
есть ещё такой нюанс, как эволюция рынка и жизненный цикл продукта. грубо говоря, можно вложиться в разработку идеального пейджера, который вскоре устареет концептуально. обычно люди от бизнеса это понимают лучше, чем разработчики.
Согласна. А еще если переписывать с нуля, то где гарантия, что не налепят такую же фигню, как в первый раз :)) так можно бесконечно переписывать и денежки отстегивать
У любого кода есть предел развития, какую бы архитектуру не заложили изначально, все равно с развитием проекта придется переписывать, потому что уперлись в потолок, и дальше поддерживать выходит слишком дорого. Конечно не стоит переделывать все как только вышел новый фреймворк, который дает чуть больше удобства, но и держаться за старый код и иметь кучу проблем с наймом персонала на легаси- тоже перебор. Идеальный вариант если переписывать можно модулями, не снося все под корень, но такое можно не везде.
В статье не хватает опроса как минимум с такими вариантами
Начать с нуля (на любом языке) не взирая ни на что
Начать с нуля если проект на CMS или мамонт на PHP < 5.0
Покрытие тестами и последующая модернизация
Модернизация с последующим покрытием тестами
Багфиксы пока проект не умрет
На разработку сервиса с нуля обычно уходит примерно столько же времени, сколько было потрачено на его создание в первый раз.
Откуда взята такая информация? По своему опыту скажу, что даже та же самая команда, напишет код второй раз быстрее и "чище". Если отдавать новой команде - то зависит от квалификации. Но опять таки, новой команде будет легче, так как система уже устоявшаяся (не нужно будет в процессе разработки что-то кардинально менять), процессы понятные, на что приходится наибольшая нагрузка - тоже примерно ясно.
В статье упускается такой сценарий, как конкуренция между старой и новой командой. Поэтому дополню: данный сценарий возможен, когда бизнес хочет держать старое в тренде (соответствие требованиям бизнеса) и параллельно писать новое. Но абсолютно забывает о том, что новой команде приходится тоже постоянно подстраиваться под новые требования... замкнутый круг....
Лучшее решение, которое я только встречал, это переписывание проекта по эндпоинтам (первые итерации долгие, но дальше легче) и точечное переключение ендпоинтов на новый код средствами веб-сервера
"Чище" - обычно да. "Быстрее" - бывает по-разному: они же не то же самое пишут, а нечто новое с учётом своих знаний. А когда пишут нечто новое всегда есть соблазн втопить новый стэк, новые плюшки и т.д. И это явно не способствует "быстрее".
Эмпирические данные. Понятно, что это не 100% правило, но обычно так и выходит плюс-минус. Понятно, что с одной стороны уже есть опыт команды на написание первой версии, но не факт, что именно эта команда будет писать новую версию. И бизнес почти всегда накидывает новые требования.
В общем, конечно, оценка очень приблизительная и в первую очередь дана для ориентира менеджерам, а не разработчикам.
Тут на хабре один "аналитег" пишет статьи с исследованиями вероятности успешности проектов от всяких параметров. Так он вывел (в общем-то, логичную вещь), что чем больше проект, тем меньше (существенно меньше) вероятность его успешного завершения. Поэтому всё "согласно купленным билетам": модернизируем существующее (суть много маленьких проектов) - успех, пишем сразу новое и с нуля (суть один большой и долгий проект) - не [очень] успех.
Я вот написал свои пет проект на api 1990х годов, узнал об этом в прошлом году - теперь надо переписывать на свежак хотя 10х годов. Я в ауте от самого себя и того что весь отпуск месячный мне придется читать новое апи и гуглить его ошибки и переписывать. Хотя если не парится о коде то проект вполне mvp
Переписывание проекта это не только обновление технологий, но и переосмысление. Из практики, переписывание старого проекта практически с нуля, привело к тому, что почти половина (а то и больше) функционала просто были удалены, или консолидированы. Также были исправлены бизнес-сценарии, которые раньше просто нельзя было сделать "по техническим причинам". Очевидно, что с технической стороны всё было актуализировано: удалены больше не поддерживаемые библиотеки и решения, обновление протоколов взаимодействия. Прирост производительности, понятно, но это не главное. Главное -- это мониторинг, которого в легаси проектах обычно отродясь не бывает, или он очень плохо совместим с современными инструментами. Что по срокам? Проект, который пилили 2 года, переписан за 2 месяца.
Это я взял один конкретный пример из практики. Понятно, что он не экстраполируется. Но, всё зависит от подхода, компетенций и команды.
Точно также и новый проект с нуля, одна команда напишет и запустит за пол года, другая и за 3 не выпустит ничего внятного. Плохо или хорошо переписывать, ни чем не отличается от вопроса, плохо или хорошо вообще писать проекты с нуля. Всё, как всегда, зависит от.
Несколько примеров "почему":
Выходят новые версии языка, которые приносят кучу новых фич. Например, когда проект начинался был ПХП 5.7 а сейчас уже 8.1 со всеми прелестями.
Проект начинался на Zend, тупо потому что ничего другого раньше не было. Хочется переписать на Symfony, потому что зенд это каждый раз боль и постоянно что-то не поддерживается.
Хотелось бы подкинуть автору идею на тему того, как правильно мыслить, общаясь с бизнесом на все эти столь нелюбимые им технические темы.
Бизнес и технари со своим техдолгом — это как человек и ЗОЖ. Все бы хотели "пить, гулять и веселиться", но мы знаем, к чему это приводит рано или поздно (скорее рано). Если говоря с бизнесом, вы чувствуете, что перед вами не "ЗОЖник", а тот, кто при возможности предпочёл бы "гулять и кутить", скорее всего он предпочтёт экономить на технических вопросах в интересах прибыли. Не тратьте на таких свою жизнь — оставьте их со своим "гедонизмом" наедине. Ищите "ЗОЖников".
Ну, переписывать проекты (с нуля или нет, решать каждому), но меня позабавил абзац где
Если код вашего сервиса выглядит так — модернизировать его не стоит. Лучше похоронить и писать с нуля
Интересно, а что не так в "шаблонизаторе пхп"? Или же нужно натянуть на все это «православный» twig? А может быть тогда вообще разделить фронт и бэк, и сделать если не gRPC, то хотя бы REST?
Да, у меня тоже хватает легаси, которое пережило не одну версию PHP, но у меня почему-то есть ощущение что шаблонизатор на «шаблонизатор» натягивать уж совсем не стоит. Да, используем «нативные шаблоны», если рендеринг на сервере, потому что незачем над «шаблонизатором» вешать еще один (да, в кавычках не просто так, я PHP знаю очень хорошо).
Единственный аргумент для такого — фронтендер не умеет в PHP... Ну, в таком случае он скорее всего и в Twig, Blade, что там еще есть, так что смысла уж совсем нету.
Там дело не в шаблонизаторе, а в отсутствии MVC. Такой код не позволяет отделять логику от представления. А наоборот, внутри представления есть инклюды php-файлов, внутри которых может быть любая логика и обращения к данным. Следовательно, бизнес-логика не сосредоточена по зонам ответственности, а полностью размазана и может изменяться в любом месте приложения, например, в footer.php. Такой подход нельзя разделить на модули, и переписать каждый отдельно. Правильно переписывать сразу весь код проекта.
Нормальный шаблонизатор без фреймворка должен только отображать данные:<div><?php echo $variable;?></div>
Но не инклюдить потенциальную логику.
«Давайте перепишем всё с нуля». Почему такой подход интереснее программистам, а не бизнесу