При проведении аудита качества кода ИТ мы выделяем два главных направления работ: оценка «качества и красоты» кода и безопасность кода. 

Оценка качества кода

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

        Основные показатели, характеризующие «качественный код»:

1. соответствие правилам;

2. сложность кода;

3. дубликаты;

4. комментирование;

5. покрытие тестами.

        Теперь подробнее поговорим о каждом из показателей.

        1. Соответствие правилам. Здесь мы говорим о рабочем коде, который компилируется и корректно выполняет задачу. В первую очередь, следует сказать о том, что в компании должны существовать правила написания кода. Для чего это нужно? Если есть прописанные требования к оформлению кода, то вне зависимости от того, кто из программистов написал код в соответствии с этими правилами, любой другой программист с легкостью будет читать этот код, не тратя время на адаптацию, например, к синтаксису. 

        Мы выделяем несколько групп правил:

• синтаксические правила. К ним можно отнести стиль именования переменных (camelCase, через подчеркивание), констант (uppercase), методов, стиль написания фигурных скобок и т.д. Особенно удобно для проектов, в которых разные модули написаны разными программистами. Единые для всех правила в значительной мере облегчают читаемость кода.

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

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

        Например, закрытие склада в MS DyN занимает несколько дней. А тот же самый алгоритм, реализованный в MS SQL отрабатывает ту же задачу за несколько минут. Способность писать оптимальный производительный код сильно коррелирует с алгебраическими способностями разработчика. Для обеспечения работоспособности неоптимального кода приходится тратить сотни тысяч долларов на сервера большей производительности. 

        2. Сложность кода. Здесь, в первую очередь, мы говорим о цикломатической сложности. Цикломатическая сложность— количество линейно независимых маршрутов через программный код. Например, если исходный код не содержит никаких точек ветвления или циклов, то сложность равна единице, поскольку есть только единственный маршрут через код. Если код имеет единственный оператор IF, содержащий простое условие, то существует два пути через код: один, если условие оператора IF имеет значение TRUE и один — если FALSE.Чем индекс ниже тем лучше, и тем легче в будущем будет менять структуру кода.

        3. Дубликанты. Важная характеристика, которая отображает насколько легко в будущем (или настоящим) можно будет вносить изменения в код. Метрику можно обозначить в процентах как соотношение строк дубликатов к всем строкам кода. Чем меньше дубликатов, тем легче будет жить с этим кодом.

        4. Комментирование. Мы относимся к той части специалистов, которые считают наличие комментариев необходимым и удобным дополнением кода.
Для комментирования можно выделить две важные метрики:

• отношение комментариев ко всему коду — из этой метрики можно сделать вывод насколько детальные комментарии и насколько они могут быть полезными. 

• комментирование публичных методов — отношение комментированных публичных методов к общему их количеству. Так как публичные методы используются вне пределов класса или пакета, то лучше прокомментировать, что этот метод должен делать и на что может повлиять. Количество публичных методов без комментариев, по нашему мнению, должно стремится к нулю.

        5. Покрытие тестами. Это очень важная характеристика качества кода. Уровень покрытия рассчитывается как отношение количества покрытых тестами элементов кода к количеству всех существующих.

        Мы выделяем следующие типы покрытия:

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

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

• покрытие методов — тот же способ исчисления метрики. Но покрытие методов может найти более широкое распространение: если у вас на проекте существует правило покрывать каждый метод хотя бы одним тестом, тогда с помощью этой метрики можно быстро найти код не соответствующий правилам.

• покрытие строк — одна из наиболее используемых метрик по покрытию. Тот же способ исчисления, только за объект берется строка.

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

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

        Важно, что чем выше покрытие кода тестами тем меньше риск поломать часть системы и оставить это незамеченным.

Оценка безопасности кода

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

        Основные классы указанных уязвимостей:

• переполнение, чтение и запись вне буфера;

• выход вычислений за пределы определенного диапазона при преобразовании переменных числового типа;

• формирование отрицательного значения длины строк байт или количества элементов массива;

• некорректное приведение типов;

• отсутствие инициализации данных;

• утечка, нехватка, использование освобожденной памяти;

• ошибки определения времени и синхронизации;

• ошибки блокировок в многопоточных средах и др.

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

        Выделяют несколько методов аудита безопасности кода:

1. просмотр (инспекция) кода вручную;

2. статический анализ кода по шаблону;

3. динамический анализ выполнения кода.

Мы проводим аудит качества кода. Даем рекомендации и оценку квалификации сотрудников. Так же этот вид аудита может послужить одним из оснований для увольнения «токсичных» программистов.