Достаточно часто перед менеджерами разработки, включая тимлидов, стоит задача по оценке качества кодовой базы. Такое может возникать в случае принятия кода от аутсорс-команды (или даже одного аутсорсера) либо при покупке компании целиком.
Сложность здесь заключается в том, что для того, чтобы оценить кодовую базу максимально полно, необходимо просмотреть весь код, а еще и желательно поработать с ним. В случае же оценки обычно нет такого количества времени. Я предлагаю набор вариантов, с помощью которых можно оценить кодовую базу с различной точностью, в зависимости от ресурсов, которые имеются в наличии.
Быстро, но не точно.
Наличие документации. Если документация существует и она актуальна, то это хороший знак. В частности стоит обратить внимание на наличие следующей информации:
Разворачивание кода в различных окружениях;
Описание структуры кода;
Используемые язык программирования, фреймворки. Версии используемых инструментов;
Схемы работы программы;
Наличие тестов различного уровня. Если тесты есть и можно посмотреть процент покрытия, то это жирный плюс. Стоит обратить внимание на следующие тесты:
Unit-тесты;
API-тесты;
Интеграционные тесты;
Нагрузочные тесты;
Фаззинг-тесты;
Используемые технологии. Используемый в коде стек может быть "не родным" для компании, которая принимает код. Это означает, что компетенций в этом стеке может не хвататить для эффективной работы с кодом, плюс надо задуматься о найме специалистов либо об обучении текущих, что выливается в финансовые затраты.
Версии используемых технологий. Если используются последние версии (в т.ч. LTS - Long Term Support), это плюс. Использование же старых версий выльется в необходимость обновления и потенциальные проблемы с ИБ (особенно, если приемщику кода необходимо проходить аудиты ИБ);
Метрики кода. Например, цикломатическая сложность, размеры функции, связность-сцепление кода и так далее. Такую информацию можно получить с помощью инструментов типа SonarQube.
Медленно, но точно
Разворачивание кода. Можно проверить, насколько просто разворачивается локальное окружение. Для этого можно привлечь штатных сотрудников либо нанять аутсорсов со знанием нужного стека. Такая проверка покажет в реальности, сколько времени (и, как следствие, денег) необходимо потратить на старт работы с кодом. Если с локальным окружением все хорошо и нужна более детальная информация, можно развернуть код на тестовом окружении;
Внесение пробных изменений. Относительно дорогая операция, но покажет достаточно много, так как реализует самый распространенный сценарий работы с кодом. Здесь также можно привлечь штатных сотрудников либо аутсорсеров со знанием нужного стека.
Я представил лишь несколько методов оценки: быстрый (проверка документации, тестов, технологий) и медленный (разворачивание кода, пробные изменения). Выбор зависит от ресурсов и целей. Важно помнить, что оценка - лишь начало процесса, требующего анализа и планирования. Правильная оценка снижает риски и обеспечивает успешную интеграцию или поддержку кода.
