Что такое аудит кода, как его провести. Критерии оценки

Писать код — все равно что решать уравнение: есть несколько разных способов это сделать, но верный ответ только один. Чтобы убедиться, что выбранный способ решения корректный и эффективный, проводят аудит кода. Мы в Форе предоставляем такую услугу, но это можно сделать и самостоятельно. В этой статье рассказали, как и на что обратить внимание.

Что такое аудит кода?

Аудит кода — это процесс изучения и оценки качества кода. Он помогает выявить потенциальные проблемы в разных аспектах, понять состояние написанного кода, его надежность и слабые стороны, предупредить о потенциальных проблемах.

Результат аудита — подробный отчет, в котором по пунктам указывается состояние категорий кода, с пояснениями и примерами.

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

В Форе мы проводим аудит кода по 7 ключевым критериям:

• Code Formatting — форматирование кода
• Best Practices — современные стандарты
• Maintainability — поддерживаемость
• Architecture — качество архитектуры
• Documentation — качество документации
• Safety — безопасность
• Efficiency — эффективность

Теперь о каждом в деталях.

Форматирование

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

Почему единое форматирование важно?
Если код неоднороден в форматировании, это может вызвать сложности в его чтении и понимании. Это в свою очередь скажется на скорости погружения в проект новых разработчиков. Дополнительные часы = дополнительные траты бюджета.

Современные стандарты

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

Также проверяем, насколько эффективно код обрабатывает ошибки и логирует (фиксирует) их.

Еще один важный пункт — как особенности конкретного языка разработки используются в проекте.

Почему это важно?

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

Поддерживаемость

Смотрим, наcколько код поддерживаемый. То есть, соответствует ли его написание общим правилам, которые не зависят от конкретного языка.

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

В противном случае код будет сложно понимать. Он становится более хрупким и подверженным ошибкам. А если нужно внести изменения или исправления, на это потребуется больше времени = больше денег.

Архитектура

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

Почему это важно?

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

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

Документация

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

Почему это важно?

Отсутствие документации грозит потерей знаний, особенно если в команде разработки происходили изменения или перестановки. Это затрудняет понимание работы системы и может привести к зависимости от ограниченного круга сотрудников, которые знакомы с кодом.

Безопасность

Проверяем безопасность кода и выявляем его уязвимости. А именно:

• Уязвимости ввода данных. Проверяем, как обрабатываются пользовательские входные данные, корректно ли система фильтрует, валидирует и экранирует ввод пользователя. Проверяем уязвимости — например, инъекции SQL или скриптов.
• Аутентификация и авторизация. Оцениваем, как реализованы механизмы аутентификации (проверка подлинности) и авторизации (управление доступом) в коде. Проверяем, безопасные ли методы хранения паролей используются, есть ли механизмы предотвращения атак перебора паролей или подбора сессионных идентификаторов.
• Шифрование и защита данных. Проверяем, чтобы конфиденциальные данные (пароли, личная информация пользователей) хранились в зашифрованном виде. Убеждаемся, что используются безопасные протоколы шифрования при передаче данных по сети.

Почему это важно?

Пренебрегая безопасностью кода, вы повышаете риск:

• Утечки конфиденциальных данных пользователей или нарушение их конфиденциальности.
• Взлома системы или внедрения вредоносного кода. Нарушения целостности данных.
• Потери доступа к системе или сервису.
• Финансовых потерь или правовых проблем.
• Ущерба репутации и доверию пользователей.

Эффективность

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

Почему это важно?

Потенциальные риски при неправильном выполнении этого критерия могут включать:

• Низкую производительность и длительное время выполнения операций.
• Избыточное использование ресурсов (памяти, процессорного времени и дискового пространства).
• Ограничения масштабируемости системы.
• Неустойчивость и непредсказуемое поведение кода при обработке больших объемов данных или при высоких нагрузках.
• Ухудшение пользовательского опыта и недовольство пользователей.

В заключение

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

Мы будем рады провести аудит за вас! Напишите нам, созвонимся и обсудим детали :)