Аудит программного кода. Почему его нужно делать. Структура аудита

Меня зовут Андрей Морозов, компания FIRECODE, и сегодня я расскажу зачем делается аудит программного кода ИТ-продукта, кто его заказывает и покажу пример аудита, который делают наши специалисты.

У нас большая команда, офисы компании находятся в 5 городах России, и основная часть штата это разработчики, которые покрывают практически весь стек технологий. Аудит программного кода - это очень популярная услуга, которую мы делаем достаточно часто, и сейчас я об этом расскажу.

Зачем делать аудит

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

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

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

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

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

Второе мнение

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

Команда для аудита

В большинстве случаев у нас формируется выделенная команда, которая может комплексно проверить продукт. Примерный состав команды:

  • разработчики (back и front) определенных стеков
  • аналитики
  • DevOps
  • тестировщики
  • проектные менеджеры

Каждый из специалистов делает свой отчет, далее отчеты объединяются в единый документ, который проверяется тимлидом или CTO и только потом отправляется заказчику.

Структура аудита, что в него входит

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

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

Состав аудита зависит от особенностей проекта, сроков реализации аудита и наличия ряда артефактов (таких как документация), максимальный перечень следующий:

1. Архитектура приложения и инфраструктуры;

2. Соответствие стандартам и требованиям;

3. Проверка подключенных сторонних библиотек и модулей (актуальность, доступность, безопасность);

4. Актуальность технологий, возможность их дальнейшего масштабирования с учетом будущих требований к проекту;

5. Читаемость и грамотность кода;

6. Логирование;

7. Резервное копирование;

8. Отказоустойчивость;

9. Потенциальные проблемы с легаси;

10. Функциональное тестирование, тестирование API;

11. Утечки памяти;

12. Быстродействие;

13. Неоптимизированные запросы к БД;

14. Безопасность;

15. Аудит документации;

16. Соблюдение законодательства

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

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

Мы не враги, мы - друзья

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

Преимущества своевременного аудита очевидны для всех сторон:

1. Гарантия качества: аудит кода помогает заказчику убедиться, что разрабатываемое программное обеспечение соответствует высоким стандартам качества и безопасности, а исполнителю не “попасть” на гарантийное устранение проблем и/или неприемку проекта.

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

3. Улучшение производительности и масштабируемости: аудит помогает выявить проблемы, которые могут влиять на производительность и масштабируемость проекта, и принять меры для их устранения.

4. Доверие заказчика: проведение аудита программного кода демонстрирует заказчику, что разработчики серьезно относятся к качеству и безопасности разрабатываемого программного обеспечения.

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

Если вы хотите провести аудит своих программных продуктов или получить консультацию, то можете оставлять комментарии или связаться с нами - наши контакты.


Также не стесняйтесь, подписывайтесь на мой блог и ставьте лайки!

0
2 комментария
Георгий Баручян

Спасибо за материал!

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

Ответить
Развернуть ветку
В А

Норм контора, не школьники сидят, работают прилично.

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда