Обновление устаревшего кода: когда и зачем это надо? v2

Вы обратились в IT-компанию, чтобы «немного подправить приложение», а вам говорят, что потребуется обновить код?

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

Что такое устаревший код?

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

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

Критерии оценки кода

Длительная работа IT-компании на рынке позволяет выработать свои правила оценки работ с кодом. Мы для себя определили такие:

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

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

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

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

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

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

Обновление кода: определяем степень изменений

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

Давайте разберем это подробнее:

- Как давно написан код — очень важный параметр, поскольку разница между «год назад» и «пять лет назад» существенная. К примеру, за пять лет многое изменилось, и у кода, вполне вероятно, будут проблемы с системой безопасности, а некоторые его части окажутся довольно давними, чтобы переходить на новую версию (их проще переписать).

- Какая архитектура кода и позволяет ли она разделить приложение? Например, можно ли выделить CRM, CMS, веб-сайт и файловое хранилище. Если да, получится обновить код частям. В противном случае, когда части не выделяются, нужно переписывать.

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

 - Развертывание — показывает, как новый код входит в старую систему.

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