Аудит кода и рефакторинг

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

Код-ревью проверяет изменение, аудит — всю систему

Код-ревью (code review) — проверка одного изменения. Разработчик сделал доработку, коллега читает её до того, как она попадёт в общий код, и так команда держит качество каждый день. Аудит — разовая проверка всей системы внешней командой, и итог у него другой: отчёт для владельца о том, что в продукте есть, чем он рискует и сколько стоит его развивать. Подробнее о ревью как о практике — в справочнике о код-ревью.

Что проверяем при аудите кода

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

Безопасность смотрим в коде: права доступа, пароли и ключи, оставленные в репозитории, устаревшие библиотеки с известными уязвимостями, хранение данных пользователей. Проверка прав стоит в этом списке первой не случайно. В OWASP Top 10 (это открытый перечень самых частых уязвимостей веб-приложений) на первом месте ошибка, при которой пользователь видит или меняет то, что ему не положено.

Какой получится отчёт

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

Кроме находок, в отчёте две оценки развития: сколько будут стоить следующие доработки в нынешнем коде и сколько после исправления критичного. Мартин Фаулер, автор книги о рефакторинге, называет эту разницу процентами по техническому долгу: функция, которая в понятном коде заняла бы 4 дня, в запутанном занимает 6. Положив две оценки рядом, собственник видит, сколько переплачивает за каждую доработку и через сколько доработок исправление вернёт вложенное.

Рефакторинг без остановки продукта

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

«Может, проще переписать с нуля?»

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

Доступы, NDA и цена аудита

Для начала нужны доступ к репозиторию и серверам, документация, если она есть, и по возможности разговор с теми, кто писал код. Работаем под NDA. Цену аудита называем, когда увидим репозиторий, потому что она зависит от объёма кода, числа сервисов и интеграций. План работ остаётся у вас, и исправлять найденное может ваша команда или мы.

Вопросы об аудите кода