Привет! Меня зовут Дмитрий Панькин, я основатель компании, которая создает сложные ИТ-продукты для клиентов: сайты маркетплейсов, B2B-порталы, личные кабинеты, приложения, кастомные CRM- и ERP-системы.

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

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

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

Когда пора обновлять сервис или систему

Практика бизнеса показывает, что почти ни одна ИТ-система не может работать вечно только на одной техподдержке — ни интернет-магазин, ни CRM-система, ни личный кабинет. Вот причины, по которым рано или поздно потребуется полное обновление или замена.

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

• не используют автоматизированные тесты;

• не строят устойчивую архитектуру;

• не проводят перекрестное код-ревью; 

• не следят за чистотой кода.

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

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

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

Мы в Resolventa используем PHP, поэтому в статье будем говорить именно о нем. Например, мы настоятельно рекомендуем обновить сервис, если версия PHP ниже, чем 7.0. То же касается устаревших фреймворков, например: Yii, CodeIgniter, CakePHP, Symfony 2.0.

Чтобы понять, поддерживается ли версия языка, которую вы используете, загляните в список релизов на официальном сайте. В случае с PHP нужно зайти на php.net, а для фреймворка Symfony — на symfony.com.

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

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

Итак, если что-то из перечисленного выше про ваш сервис, значит, его нужно обновить.

Почему разработчики иногда дают вредные советы

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

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

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

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

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

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

Почему писать сервис с нуля — плохая идея в 99% случаев

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

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

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

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

Когда писать с нуля все-таки нужно

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

Используемые технологии безнадежно устарели. Проект придется создавать заново, если технологии не просто морально устарели, а умерли. Так бывает, если версия языка, на котором написан ваш сервис, уже давно не поддерживается. Например, когда продукт написан на PHP 5.0, который устарел еще в 2008 году.

<!DOCTYPE html>
<html>
<head>
    <title>Блочная верстка</title>
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>
<div id="container">
	<?php include ("blocks/header.php");?>
	<?php include ("blocks/navigation.php");?>
	<?php include ("blocks/sidebar.php");?>
	<div id="content">
	<h2>Основной контент страницы</h2>
	</div>
		 
	<?php include ("blocks/footer.php");?>

</div>
</body>
</html>

↑ Если код вашего сервиса выглядит так — модернизировать его не стоит. Лучше похоронить и писать с нуля

Использованы CMS. Такие конструкторы, как WordPress и Bitrix, хороши для небольших или типовых интернет-магазинов и других несложных ИТ-систем. Если бизнес растет, со временем ему потребуются новые индивидуальные решения, которые невозможно реализовать на CMS.

Увы, модернизировать сервис, изначально написанный на CMS, невероятно дорого и сложно. Для этого нужно знать устройство конкретной CMS изнутри и не просто конфигурировать ее, а уметь переписывать важные части исходного кода. На рынке таких специалистов очень мало.

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

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

Пример из практики. В 2015 году мы перезапустили немецкий B2B-портал о вине и виноделии wein.plus. Владельцы портала продают подписки на свой ресурс, участникам доступна разнообразная отраслевая информация: каталоги вин и производителей, справочники, рейтинги, журнал.

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

Сервис можно было только написать с нуля, и вот почему:

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

• Проект написан неоднородно. Одни разделы — на чистом PHP без фреймворков, другие — с помощью WordPress.

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

• Данные копились в проекте с 1998 года, таблицы и поля в них тоже заполняли на двух иностранных языках вперемешку.

Что мы сделали. Разработали новый портал с нуля с помощью современного фреймворка Laravel. Для клиента было важно полностью сохранить всю базу данных — мы изучили 172 таблицы и перенесли информацию на новый портал.

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

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

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

Почему поэтапно модернизировать старый сервис — лучшее решение для бизнеса

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

Если руководство выбирает тактику поэтапного восстановления, можно будет расширять и наращивать эффективность бизнеса параллельно с воссозданием ИТ-системы. Не придется ставить процессы на паузу на пару лет, пока пишется новая программная платформа для компании.

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

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

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

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

Но есть моменты, которые снижают цену работ по модернизации:

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

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

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

В нашей практике много примеров, когда модернизация спасала компанию от простоя и помогала активно развиваться параллельно со всеми доработками.

Пример из практики. Сайт FishingSib создали в 2000-е как форум для рыбаков-любителей. Сейчас он насчитывает 10 тысяч посетителей ежедневно. На портале есть доска объявлений, новостная лента, карта рыбных мест, персональные блоги и другие разделы.

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

Что мы сделали. Плавно модернизировали сервис и перенесли его на современный фреймворк Symfony. Для этого мы сделали следующее:

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

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

3. Настроили связь между фреймворками CakePHP и Symfony. Без нее было невозможно наладить одновременную работу разделов сайта, которые были написаны с разницей почти в 10 лет. Разработчики писали функции так, чтобы при необходимости можно было выполнить блок кода из CakePHP в Symfony и наоборот.

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

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

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

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

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

Итоги: что делать с устаревшим сервисом

• Обновляйте сервис, если бизнес сильно вырос или изменился, технологии морально устарели или, например, прошло 10 лет с последней модернизации.

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

• Переписывайте сервис с нуля, если он сделан на PHP 5.0 и более ранних версиях или написан с помощью CMS. В этих случаях модернизировать сервис будет сложнее, чем писать заново, — а значит, это займет много часов у программистов и обойдется чересчур дорого.