Привет! Меня зовут Дмитрий Панькин, я основатель компании Resolventa. Мы создаем сложные ИТ-продукты для клиентов: сайты маркетплейсов, B2B-порталы, личные кабинеты, приложения, кастомные CRM- и ERP-системы.
Когда компания хочет обновить свою ИТ-систему, ее ждет куча вредных советов от программистов: удалить, выкинуть, написать заново на другом языке. Этот подход в 99% выгоден только самим разработчикам, бизнесы из-за него разоряются. А теперь подробнее.
Когда пора обновлять сервис или систему
Почти ни одна ИТ-система не может работать вечно только на одной техподдержке — ни интернет-магазин, ни CRM-система, ни личный кабинет. Вот почему сервису рано или поздно потребуется полное обновление или замена.
Бизнес вырос или изменился. Иногда на старте предпринимателю сложно предположить, что небольшой «гаражный» проект разрастется до огромной компании с несколькими департаментами. Поэтому техзадание для ИТ-системы часто пишут так, будто она всегда будет маленькой. Разработчики не учитывают последующее масштабирование:
- не используют автоматизированные тесты;
- не строят устойчивую архитектуру;
- не проводят перекрестное код-ревью;
- не следят за чистотой кода.
На старте такой подход бывает даже выгодным: можно быстро создать минимально жизнеспособную версию сервиса и выйти с ним на рынок, чтобы протестировать в реальных условиях. Но если пропустить момент, когда масштаб увеличится, начнут вылезать бесконечные баги, сервис станет медленно обрабатывать запросы и перестанет справляться с объемом данных.
Технологии устарели. С момента написания ИТ-системы может выйти несколько новых версий языка программирования — в итоге ваша версия устареет и окажется без официальной поддержки. А значит, уязвимости в ней уже не устранят и новых функций не добавят. Это критично для развития и масштабирования любого бизнеса, поэтому нужно обновлять сервис и переходить на новую версию языка.
Мы в Resolventa используем PHP, поэтому в статье будем говорить именно о нем. Например, мы настоятельно рекомендуем обновить сервис, если версия PHP ниже, чем 7.0. То же касается устаревших фреймворков, например: Yii, CodeIgniter, CakePHP, Symfony 2.0.
Чтобы понять, поддерживается ли версия языка, которую вы используете, загляните в список релизов на официальном сайте. В случае с PHP нужно зайти на php.net, а для фреймворка Symfony — на symfony.com.
Проект писала недостаточно квалифицированная команда. Бывает, что сервис изначально пишут небрежно и наспех. В результате код грязный, программисты не делают рефакторинг и ревью — некогда. В этом может быть вина не только разработчиков, но и менеджеров: они могут ставить слишком сжатые сроки и постоянно подгонять команду, провоцируя на новые ошибки.
Иногда у бизнеса на старте просто нет денег на опытную команду разработчиков — и ИТ-систему заказывают у того, кто предложит более доступную цену. Пока сервис небольшой, низкое качество кода не бросается в глаза, но с развитием бизнеса наступает коллапс. Это не значит, что подход был неверный. Просто команда не среагировала вовремя и не обновила систему до того, как возникли проблемы.
Итак, если что-то из перечисленного выше про ваш сервис, значит, его нужно обновить.
Почему разработчики иногда дают вредные советы
Представьте: логистическая компания «Перевозки» заметила, что внутренняя система для сотрудников стала тормозить из-за большого объема данных, и обратилась с этой проблемой в ИТ-агентство. Кроме того, ей надо добавить новую функцию в личном кабинете и сделать адаптивную версию, чтобы сервисом было удобно пользоваться со смартфона, но текущие технологии не позволяют это сделать.
С вероятностью 90% в агентстве состоится следующий диалог:
— На каком стеке сейчас написан ваш сервис?
— Разработчики говорят, что на PHP…
— Отсюда и проблемы. Давайте напишем всё с нуля на современном Node.js. Это позволит использовать единый язык JavaScript, чтобы писать код как на стороне клиента, так и на сервере. В итоге получится намного быстрее, а разработчикам на фронтенде и бэкенде будет проще сотрудничать друг с другом.
— А точно нет никакого способа сохранить то, что есть?
— Это будет вам самим невыгодно. Поверьте нашему опыту.
— Окей…
Представили? Именно так обычно и заканчиваются переговоры о том, как лучше пересоздать свой сервис. Написание с нуля выгодно для программистов, но чаще всего критично плохая идея для бизнеса.
Объясню, почему вообще программисты дают такие советы.
У каждой компании свой технологический стек: одно агентство специализируется на PHP, другое — на Python, третье — на Node.js. Если у заказчика другой стек, разработчики просто не могут погрузиться в его проект, потому что у команды нет специалистов, которые работают на этом языке программирования.
Разработчики недостаточно компетентны. Разобраться в чужом коде намного сложнее, чем написать проект заново. Нужен опыт в решении аналогичных проблем и персональный подход, а не только практика решения типовых задач. Для этого требуются квалифицированные сотрудники. Если вам предлагают переписать проект с нуля, — возможно, в штате компании просто нет сеньор-программистов, чтобы провести модернизацию.
Агентству выгодно взять ваш заказ, а вот поэтапно модернизировать сервис слишком напряжно. В итоге программисты закономерно начинают продавливать свое решение полностью переписать проект. Так они получают деньги и не усложняют себе жизнь работой с чужим стеком и легаси. Аргументируют это обычно тем, что технологический стек и подход к решению задач у агентства самые современные, а у заказчика дремучие и устаревшие, — вот все и тормозит.
Мы считаем, что задача добросовестного разработчика — сохранить сервис, если это возможно. Давайте разберемся, почему в большинстве случаев выгоднее модернизировать старую ИТ-систему и когда все-таки придется переписывать всё с нуля.
Почему писать сервис с нуля — плохая идея в 99% случаев
На разработку сервиса с нуля обычно уходит примерно столько же времени, сколько было потрачено на его создание в первый раз. Например, если интернет-магазин сделали за год, то и его новая версия появится не раньше.
Все это время бизнес должен жить со старой ИТ-системой, которая хоть и не выполняет своих функций полностью, но все-таки необходима. Есть два варианта, что с ней делать: оставить всё как есть — на техподдержке — или ставить костыли и чинить сервис параллельно с созданием нового. У каждого решения есть свой существенный минус:
❌ Если вы не трогаете старый сервис, то теряете возможную прибыль. Например, в нашей практике был заказчик с B2B-порталом, он продавал подписки на свой сервис. Предполагалось, что, пока мы делаем новую версию портала, клиенты будут пользоваться старой и ждать релиза. Но некоторых не устраивали баги и неадаптивный дизайн, поэтому они отписывались от сервиса. В итоге заказчик упускал часть прибыли.
❌ Если вы чините старый сервис вместе с созданием нового, вы удваиваете расходы. Вам придется содержать две команды разработчиков: платить вдвое больше и тратить управленческий ресурс, чтобы контролировать обе. Это большая нагрузка на бизнес. А еще есть риск конфликта: разработчики текущей версии чувствуют, что устаревший сервис похоронят вместе с ними, поэтому могут саботировать сотрудничество с новой командой.
Когда писать с нуля все-таки нужно
По моему опыту, практически не бывает ситуаций, когда систему невозможно восстановить: перебрать старый код и модернизировать платформу можно всегда. Но есть случаи, когда это нецелесообразно. Вот два обстоятельства, при которых, систему лучше все же переписывать с нуля:
Используемые технологии безнадежно устарели. Проект придется создавать заново, если технологии не просто морально устарели, а умерли. Так бывает, если версия языка, на котором написан ваш сервис, уже давно не поддерживается. Например, когда продукт написан на PHP 5.0, который устарел еще в 2008 году.
↑ Если код вашего сервиса выглядит так — модернизировать его не стоит. Лучше похоронить и писать с нуля
Использованы CMS. Такие конструкторы, как WordPress и Bitrix, хороши для небольших или типовых интернет-магазинов и других несложных ИТ-систем. Если бизнес растет, со временем ему потребуются новые индивидуальные решения, которые невозможно реализовать на CMS.
Увы, модернизировать сервис, изначально написанный на CMS, невероятно дорого и сложно. Для этого нужно знать устройство конкретной CMS изнутри и не просто конфигурировать ее, а уметь переписывать важные части исходного кода. На рынке таких специалистов очень мало.
Почему поэтапно модернизировать старый сервис — лучшее решение для бизнеса
Во всех остальных случаях, когда сервис написан на версии языка, которая еще поддерживается, и не используются CMS, я рекомендую модернизацию. Для бизнеса перестраивать старый сервис почти всегда лучше, чем делать новый.
Если руководство выбирает тактику поэтапной модернизации, можно будет расширять и наращивать эффективность бизнеса параллельно с воссозданием ИТ-системы. Не придется ставить процессы на паузу на пару лет, пока пишется новая программная платформа для компании.
Руководству бизнеса может показаться, что модернизировать сервис дороже, чем разработать заново. Это не всегда так. На окончательную цену влияют несколько факторов. Рассмотрим сначала те, что повышают цену поэтапного восстановления:
- Оплата квалифицированных кадров. Модернизация сложнее, чем создание проекта, поэтому здесь требуются специалисты более высокого уровня. Их стоимость выше, поэтому зарплаты могут увеличить бюджет.
Но, с другой стороны, низкобюджетная команда вряд ли сможет хорошо написать даже новый проект — есть риск, что через пару лет его придется переписывать вновь.
- Временные издержки. Поэтапно модернизировать систему трудоемко, это может занять значительное время. Бизнес будет нести эту финансовую нагрузку дольше, изымая деньги из других статей бюджета.
Но есть моменты, которые снижают цену работ по модернизации:
- Использование готовых частей кода. При восстановлении не нужно переписывать участки старой системы, которые хорошо функционируют. Это позволяет сократить затраты на разработку. При создании проекта заново такое невозможно: сто процентов кода надо писать с нуля.
- Работа всего одной команды. Нет необходимости держать отдельных разработчиков для поддержки старого сервиса и создания нового, вы не раздуваете штат программистов.
Чтобы точно определиться, какой вариант оптимален для бизнеса, я рекомендую провести квалифицированный внешний ИТ-аудит. Специалисты посмотрят, в каком состоянии находится ваш сервис, подсчитают затраты на написание с нуля и на модернизацию и помогут сделать вывод.
Итоги: что делать с устаревшим сервисом
- Обновляйте сервис, если бизнес сильно вырос или изменился, технологии морально устарели или, например, прошло 10 лет с последней модернизации.
- Поэтапно модернизировать проект — самое выгодное решение для компании в большинстве случаев. Так вам не придется удваивать расходы, терять прибыль и клиентов, а также замораживать рост бизнеса.
- Переписывайте сервис с нуля, если он сделан на PHP 5.0 и более ранних версиях или написан с помощью CMS. В этих случаях модернизировать сервис будет сложнее, чем писать заново, — а значит, это займет много часов у программистов и обойдется чересчур дорого.
Мы в Resolventa помогаем стартапам и крупному бизнесу по всему миру перезапускать сервисы и создавать новые с 2012 года. Также проводим технический аудит: понадобится, если еще не решили, модернизировать систему или переписывать, что конкретно в ней изменить и как оптимизировать.
Приходите ко мне в Телеграм — разберем проблему и назначим дату консультации по вашему ИТ-проекту. Или можно оставить заявку на сайте компании.
Я, у которого половина бизнеса работает через гугл-таблицы и настроенные связи между ними: «Ага, кастомные ERP, интересно»
если хорошо работает,то зачем вам эти сложности )
Ой началось... Вот все дают вредные советы, а мы нитакуси...
Не все, но многие...
Ну 15 лет назад это было нормально ) А вы когда учились?
2 года назад)) Ну я не планировал никогда прогером становится, мне прост надо было научиться кодить чтоб сайты самому себе делать. Учился по видосикам на ютубе, получался грязный код, но было чертовски приятно что вообще получался. Мне до этого казалось, что по видосикам научиться прогать — эт нереально или как минимум очень долго.
Не выгоднее ли тогда компаниям взять толкового разработчика в штат, а не заниматься поисками подрядчиков
Если у компании есть экспертиза, чтобы найти, правильно оценить и потом управлять этим толковым разработчиком, то возможно будет выгоднее. Но если у вас нет серьезной экспертизы в ИТ, то зачастую и проще, и дешевле довериться надежному подрядчику.
Некоторым компаниям(небольшим) выгоднее просто взять разработчика в партнеры, если бизнес критично зависит от IT.
А мне всегда казалось, что грамотно написать "с нуля" труднее, чем изучить готовое решение.
В любом случае разбираться в старом коде придется. Вот я переписываю сейчас проект, в котором >500 тыс. строк(не показатель сложности конечно) и хотя в новую версию я вношу фундаментальные отличия по архитектуре, я прекрасно ориентируюсь в старом коде и для меня он содержит много подсказок и идей, которые можно развить.
Кстати (опять же сугубо по своему опыту) если разработчик открещивается от изучения легаси и сразу рвется в бой "переписать с нуля", то это запросто приведет к изобретению своих (и часто не всегда лучших) велосипедов, а самое худшее — повторению ошибок предыдущей команды.
Если мы исходим из того, что предыдущую систему писали не идиоты (хотя бы потому, что она какое-то время выполняла свои задачи ), разумно все-таки детально изучить решения прежней команды.
Комментарий недоступен
Эм, а какой 7ой php речь, если на дворе 8.2 уже минималка ?
И по поводу cms . Есть опыт работы с крупными проектами как на wp, так и на битре. Высоконагруженные, много бизнес логики , интеграций. Команды пилят новый функционал, подчищают косты..
Да, есть нюансЫ с вендор локом и миграций ядра и баз, но решаемо .
Говорить, что скорей всего придется отказаться от cms , ну такое ...
Наверное, любой подход касательно доработки сложных систем очень сильно зависит от пациента. Иногда дешевле и быстрее вылечить консервативно. А иногда без операции никак). Конечно от мастерства тоже многое зависит. Но я про то, что универсальным подход можно назвать только в определенных рамках, а не в абсолюте.
Получается, на CMS лучше вообще не писать?)) Если хочешь в дальнейшем большую продвинутую ИТ-систему
По факту, да. Если планируется развитие и усложнение системы, то CMS это почти всегда тупиковый путь ( Рано или поздно придется выкинуть и создавать все заново. Стартовать на CMS имеет смысл, если бюджет ограничен и нет каких то серьезных планов по развитию системы.
Да не слушайте вы этих модных балаболов. Используйте CMS, они на порядок дешевле и хватит вам на долго. С нуля у вас и бизнес-требований не будет нормальных.
Разумно :)
Узнал себя, когда учился прогать ахаха. Что-то примерно такое и получалось. Прогером не стал =)
Странно, я почему-то думала, что наоборот — переписывать сложнее. Там же надо с нуля всю логику придумывать. Может, мне тоже мозги промыли?))
В больших и сложных системах зачастую сложнее разобраться и в том, что уже написано и изменить это, чем написать что-то с нуля.
А как найти компанию, которая точно нормально модернизирует сервис, а не наломает дров? На что смотреть, что спрашивать на созвоне?
Да в общем то наверное так же как и любого другого подрядчика - смотреть портфолио, кейсы, адекватность и т.д.
Все это очень спорно и полемично.
Но я попробую придраться к итогам.
"Обновляйте сервис, если бизнес сильно вырос или изменился, технологии морально устарели."
Зачем? Зачем, ломать и перестраивать то, что работает?
Если калькулятор на столе у бухгалтера работает уже 10 лет, значит ли это что его надо поменять? Ведь и элементная база старая, и морально он устарел. Новые калькуляторы намного красивее и считают быстрее на 0,2 секунды!
Может все-таки стоит исходить от изменений бизнеса, новых потребностей?
"Поэтапно модернизировать проект — самое выгодное решение для компании в большинстве случаев"
Тут есть оговорка "в большинстве", уже хорошо )
Но эта фраза вытекает из теоремы что "писать сервис с нуля — плохая идея в 99% случаев", которую доказывается утверждением:
"На разработку сервиса с нуля обычно уходит примерно столько же времени, сколько было потрачено на его создание в первый раз."
Что собственно, на мой взгляд, является безосновательным.
Почему столько же времени?
Идея уже имеется, бизнес-логика проработана, даже интерфейс нарисован.. Почему столько же времени то?
И поэтапная модернизация, опять же на мой взгляд, самое дорогое решение.
И как раз вот это "Использование готовых частей кода", является одним из самых дорогих решений.
Так как:
-многократно используемые компоненты в три раза более трудоемки, чем одноразовые компоненты;
-Модификация повторно используемого кода крайне чревата ошибками. Если надо изменить более 20-25% кода компонента, то лучше переписать его с самого начала.
Ну и под "коду":
Стоимость сопровождения обычно составляет от 40 до 80% (в среднем 60%) стоимости ПО. Следовательно, эта фаза его жизненного цикла, возможно, самая важная. Примерно 60% расходов на сопровождение приходится на улучшение кода и около 17% – на исправление ошибок. Таким образом, в основном сопровождение и поддержка ПО заключается в добавлении в него новых возможностей, а не в его исправлении.
Спасибо, что так подробно!))
Илья, мне кажется, что вы в своих рассуждениях упустили самое главное - постоянные изменения в бизнесе, которые за собой тянут такие же постоянные изменения в приложении. Очень редкая ситуация, когда приложение создали и дальше пользуются им годами без каких-то изменений. Ваш пример с калькулятором именно про это. Бухгалтеру через 10 лет уже не калькулятор нужен, а планшет с самой свежей версией его бухгалтерской программы, а вы его калькулятором заставляете пользоваться...
Вопрос в том, изменились ли потребности бизнеса.
У одного старого заказчика до сих пор крутится код, который я написал в 2003-м году (выглядит ещё хуже, чем в примере в статье ;). Писалось это на php4, на 5.3 работает, дальше уже нужны существенные изменения. Ничего, в максимально изолированной виртуалке с бэкпортом php 5.3 на современный Debian работает - и нормально, та функциональность до сих пор устраивает.
А вот что-то там (кроме совсем мелочей) пытаться менять точно бесполезно, проще переписать с нуля.
Не факт, что новая система не повторит ошибок старой. Но обычно старые системы настолько запутаны и привязаны к кривым бд, что проще написать новую
Разработчикам, конечно, проще написать новую. А вот для бизнеса это далеко не всегда оптимальное решение. Об этом и статья.
Когда я был джуном думал, вот бы написать с 0...
Прошло 10 лет, теперь я так не думаю.
Для бизнеса важно здесь и сейчас, особенно когда есть конкуренты.
То есть делать, добавлять фитчи которые приносят новые деньги.
То что, хочется программисту !== то, что нужно бизнесу.
Можно проще сказать = лень поддерживать старое, разбираться)
А как вы боретесь с распространенной логикой, когда клиент хочет реализовать функционал, а студия брешет "вам это не нужно." Собственно такая логика стала частично причиной неимения у нас собственных разработок. Из своего опыта зная несколько крупных компаний, которые благодаря таким разработчикам имеют дырявые сайты, с которых влёт можно угнать данные и финансы не имея соответствующего образования.
Евгений, а мы с таким не сталкивались особо. Могу предположить лишь то, что разработчики делали сайты на каких-нибудь CMS, типа битрикса, и они просто ограничены функционалом этой платформы, поэтому отбиваются от нестандартных хотелок заказчика как могут.
У нас, наоборот, кастомная разработка, поэтому чем сложнее и необычнее задача, тем нам интереснее с ней работать.
Начал читать (много здравых мыслей), но дальше наткнулся на ЭТО.
«Почти ни одна ИТ-система не может работать вечно только на одной техподдержке — ни интернет-магазин, ни CRM-система, ни личный кабинет. Вот почему сервису рано или поздно потребуется полное обновление или замена»
Почему не сможет работать IT-система? Почему потребуется обновление?! Хостинг предоставляет выбор версий, среди них версия 5.3 или 5.6, на которых всё работает, эти версии ещё с десяток лет (а может, и больше) будут держать, уязвимости закрыты, сервисы активно используются, ничего не тормозит, сбор мусора ежедневный по крону, запас места под базы – 3/4 доступного объёма, пользователей всё устраивает, с чего вдруг её нужно обновлять?! Просто потому что?
«Проект придется создавать заново, если технологии не просто морально устарели, а умерли. Так бывает, если версия языка, на котором написан ваш сервис, уже давно не поддерживается».
Что значит – технологии умерли? Как это определить? Ну вот, скажем, технология молотка, топора, двуручной пилы – морально устарели или нет? А технология крестовой отвёртки? А кварцевых наручных часов? Или: версия языка не поддерживается – кем? Хостингом? Так у меня тогда CRM попросту перестанет работать в момент окончания поддержки – придётся срочно искать другого хостера или ставить на выделенном сервере нужную мне версию. Но если хостер давно уже не поддерживает используемую в проекте версию языка – то никакого проекта не существует, так как он так же давно уже недоступен после прекращения поддержки.
Или: а почему PHP 7.0 рекомендуется, а не 5.6? Не спорю, «семёрка» быстрее и есть новшества, но удобна она только для разработчиков – заказчикам вообще пофиг, на чём написано. Разница же в скорости, как показывает практика, начинает ощущаться только при реализации алгоритмов через одно очень заднее место – для сравнения, грамотно написанный алгоритм на 5.6 будет исполняться за 0,15 сек., а на 7.0 – за 0,08 сек., но сколько нужно терминалов и персонала, чтобы эта разница стала критической?
Нет, конечно, если бизнес заказчика и пользователей все устраивает, то и не надо ничего обновлять. Я давал общие, усредненные рекомендации. Статья в первую очередь для менеджеров, у которых проблемы с устаревшими ИТ системами, а им ездят по ушам...
Естественно, каждый случай индивидуальный и невозможно дать какой-то единый четкий алгоритм для абсолютно любой системы.
Мы несколько лет назад перевели все проекты на PHP7 (причем не так много усилий ушло) и были очень сильно рады, прирост производительности был значительный. Даже не ожидал что в 2023 году кто-то ещё на пятере работает.
Разработчики недостаточно компетентны. Разобраться в чужом коде намного сложнее, чем написать проект заново.
Может проще использовать CMS, чем копаться в чужом говнокоде?
Есть огромное количество проектов, где CMS системы не подходят.
Тенденция, однако. Или CMS, или говнокод. Третьего не дано? Чистого, эффективного кода индивидуальной разработки для конкретных БП?
А как вы выбираете, на каком фреймворке переписывать систему? Есть какие-то закономерности? Типа если модернизируете, то лучше вот такой фреймворк, а если с нуля — то такой
Мы предпочитаем фреймворк Symfony. Он отлично подходит, как основа для поэтапной модернизации проекта, так и для старта новых больших и сложных проектов с нуля.
По-моему, сейчас лучший выбор для фулстека — это .NET + TypeScript в связке с каким-нибудь React для фронтедна.
Комментарий недоступен
1
У меня сервис на NodeJS. Начиная с какой версии рекомендуете обновлять?
5
По-хорошему, когда новая LTS-версия выходит, желательно обновить, если у вашего сервиса нет критичной зависимости от какого-нибудь сильно устаревшего пакета. В любом случае обновлять придется, поэтому желательно делать это регулярно.
лень-двигатель прогресса, из- за лени и происходит автоматизация процессов
Или перекладывание работы на чужите плечи. Хотя это тоже своего рода автоматизация...
Комментарий недоступен
О, а вот и защитники "все выкинуть и написать с нуля" подтянулись. Конечно, это сложно, и думать надо, и разбираться... И да, дорого, но зачастую выгоднее для бизнеса, чем все переписать.
Когда стану разработчиком, возьму этот лайфхак про написание с нуля на заметку хахаха
Шучу, конечно, заказчики на долгосрок в приоритете)
Комментарий недоступен
не только писать сервис с нуля, но и что-то начинать с нуля не очень хорошая идея
Это зависит от того, с какой стороны этого процесса Вы находитесь. Тот, кто платит, или тот, кому платят :)))