Вы обратились в IT-компанию, чтобы «немного подправить приложение», а вам говорят, что потребуется обновить код?
Частенько у клиентов при таком повороте событий возникают сомнения в том, насколько правильно и честно будущий исполнитель оценил объем работ. Мы периодически сталкиваемся с подобными случаями, потому уверен, разобраться нужно детально. О подготовительном этапе я рассказывал в предыдущей статье, теперь поговорим о самом обновлении устаревшего кода.
Если мы сейчас о нем говорим, значит, ваше приложение уже работает либо находится на финальной стадии запуска, но программисты никак его не доделают.
Как и вся наша жизнь, ваш бизнес не стоит на месте, тем более, с таким быстрым развитием технологий и цифровизацией. Поэтому вполне закономерно, что возникла необходимость добавить в приложение некоторые функции. Однако разработчики не могут просто их туда «вставить», не вмешиваясь в код, поскольку в нем все взаимосвязано. В то же время, каждый код уникален. Только проанализировав его архитектуру, качество и покрытие тестами, можно определить, насколько реально дополнить тем, о чем вы просите, и каким образом это сделать.
Критерии оценки кода
Длительная работа IT-компании на рынке позволяет выработать свои правила оценки работ с кодом. Мы для себя определили такие:
Вариант 1. Не беремся за обновление старого кода, если после анализа видим, что домен приложения достаточно сложный. В таких случаях попытки переделывать чужую «грязную работу» часто приводят к большим трудозатратам и неоправданной стоимости, которая не устраивает заказчика. К тому же, не всегда можно полностью достичь желаемого результата из-за плохого качества исходного кода.
В данной ситуации обсуждаем с клиентом, приводя конкретные примеры и факты, почему проще, качественнее (а нередко и дешевле) написать код с нуля. При этом старый код используем, чтобы понять бизнес-логику продукта или проанализировать запланированную функциональность и избежать уже допущенных ошибок.
Вариант 2. Работаем с базой кода клиента по четко определенным этапам, добавляя нужные функции при обновлении. Соглашаемся на такой вариант, только когда структура кода понятная, логичная и полностью протестирована. При этом в обязательном порядке сотрудничаем с командой разработчиков клиента, поскольку для качественного рефакторинга понадобится определенная документация.
В то же время, до начала обновлений мы объясняем клиенту всю сложность работы с чужим кодом, сравнивая с написанием кода с нуля.
Еще один способ внести нужные дополнения в уже созданное приложение — структурировать имеющийся код, тогда не нужно изменять или переписывать его часть для добавления новых функций. Понадобится только информация о форме входящих и исходящих данных. Однако далеко не все коды поддаются такому структурированию.
Вариант 3. Очень редко в старую кодовую базу мы просто предлагаем добавить новые функции. Так бывает, если код написан и продуман очень хорошо. Однако подобные случаи скорее исключение, ведь у каждого IT-специалиста свое видение архитектуры.
Обновление кода: определяем степень изменений
Решившись на обновление кода, вы сделаете только первый шаг. Далее нужно определить степень и важность изменений, то есть возраст, архитектуру кода, охват тестированием и развертывание.
Давайте разберем это подробнее:
- Как давно написан код — очень важный параметр, поскольку разница между «год назад» и «пять лет назад» существенная. К примеру, за пять лет многое изменилось, и у кода, вполне вероятно, будут проблемы с системой безопасности, а некоторые его части окажутся довольно давними, чтобы переходить на новую версию (их проще переписать).
- Какая архитектура кода и позволяет ли она разделить приложение? Например, можно ли выделить CRM, CMS, веб-сайт и файловое хранилище. Если да, получится обновить код частям. В противном случае, когда части не выделяются, нужно переписывать.
- Качество тестового покрытия дает возможность определить, достаточно ли тестов либо команде нужно их писать самостоятельно.
- Развертывание — показывает, как новый код входит в старую систему.
Итак, вполне вероятно, что процесс, который вам кажется «небольшим дополнением функций», вполне может тянуть на обновление устаревшего кода. Наша практика показывает — хорошо написанных кодов пока не так много, как хотелось бы. Но далеко не все заказчики понимают специфику, поэтому советую детально обсуждать с исполнителем проблематику и варианты решения задач.
