Оценка качества кодовой базы

Достаточно часто перед менеджерами разработки, включая тимлидов, стоит задача по оценке качества кодовой базы. Такое может возникать в случае принятия кода от аутсорс-команды (или даже одного аутсорсера) либо при покупке компании целиком. 

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

Быстро, но не точно.

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

Медленно, но точно

• Разворачивание кода. Можно проверить, насколько просто разворачивается локальное окружение. Для этого можно привлечь штатных сотрудников либо нанять аутсорсов со знанием нужного стека. Такая проверка покажет в реальности, сколько времени (и, как следствие, денег) необходимо потратить на старт работы с кодом. Если с локальным окружением все хорошо и нужна более детальная информация, можно развернуть код на тестовом окружении;
• Внесение пробных изменений. Относительно дорогая операция, но покажет достаточно много, так как реализует самый распространенный сценарий работы с кодом. Здесь также можно привлечь штатных сотрудников либо аутсорсеров со знанием нужного стека. 

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