Инспекция кода — это хорошо. Мы используем эту технику в своих проектах не так давно — около трех месяцев, — однако положительные результаты налицо. Мы уже рассказывали на Хабре о внедрении инспекций в процесс разработки, о документообороте при инспекциях, рассказывали о том, как можно оптимизировать процесс инспектирования с помощью инструмента Code Collaborator. Сегодня мы хотим подвести итоги и представить результаты, которых нам удалось достичь за время инспектирования. Поехали!..
На самом деле, плюсов много, поэтому в этом топике мы коснемся лишь нескольких основных.
Утвердился общий стиль написания кода. Конечно, и до внедрения инспектирования в нашей команде существовало некое представление о том, что такое хорошо и что такое плохо, которого все старались придерживаться. Однако благодаря инспекциям общий стиль был окончательно отточен и фактически «закрепился в голове» у каждого разработчика.
Парк велосипедов пополняется медленней. Все реже возникают ситуации «я придумал гениальное решение», и все чаще мы используем проверенные решения из сторонних библиотек. Возник интересный эффект «коллективного знания», когда один член команды знает об отдельной библиотеке что-то, чего не знают другие, и предлагает оптимально использовать ее лучшие качества.
Улучшилось общее владение кодом. Стало больше живого общения по различным аспектам проекта: почему это сделали так, а не по-другому? может быть, следовало бы поступить вот так? В результате понимание того, как работают различные части системы, стало равномерно распределяться среди разработчиков, а не концентрироваться у кого-то одного.
Активизировался обмен опытом и знаниями. Теперь мы чаще используем в разработке успешные методики и практики коллег, реализованные в других частях системы. Подобный опыт, на наш взгляд, может передаваться только через чтение чужого кода: другого пути просто не существует. Любой метод нужно «пережить» самому, лишь тогда его может сделать «своим», освоить. Для такого «погружения» нет ничего лучше, чем хороший пример чужого кода из знакомой предметной области: это куда эффективнее абстрактных геометрических примеров типа shape, circle и box.
Кодовая база стала более «сопровождаемой». Здесь целый список улучшений:
- магические константы блокируются проверяющими;
- уменьшилось дублирование кода (DRY);
- алгоритмы стали проще (KISS);
- документация классов и публичных методов улучшилась значительно (практически на каждый публичный класс и метод инспекторы требуют добавить документацию);
Единственный недостаток внедрения инспекций кода — увеличение времени разработки. На начальном этапе внедрения время увеличилось на 50—100% (иногда бывало и больше), но в результате в общем репозитории стало гораздо меньше некачественного кода, меньше «шлака».
В данный момент, после первоначальной отладки всех процессов, дополнительные временные затраты сократились до примерно 20—50%. Основной всплеск связан с притиркой команды к общему стилю кодирования; много времени ушло на принятие общих практик и методик. Для опытных команд, на наш взгляд, нормальное среднее увеличение времени разработки — 10%.
Checklist
Данный термин часто встречается в англоязычной литературе и обозначает, по сути, памятку инспектора — список контрольных вопросов для облегчения процесса инспектирования.
Контрольный список лучше создавать для каждого проекта и для каждой команды, поскольку он может сильно различаться в зависимости от используемых платформ, библиотек, архитектурных решений. При этом со временем список эволюционирует и начинает более полно отвечать текущим задачам проекта.
Суммируя накопленный опыт инспектирования, мы начали понимать, как нужно составлять контрольный список. Вот как выглядит наш список на данный момент.
Контрольный список — памятка инспектора Positive Technoligies
1. Корректность реализации предметной области.
- Функциональность реализована в полном объеме.
- Соответствие спецификациям.
- Верность заданных констант.
- Обоснованность принятых допущений и соглашений.
- Верная последовательность обработки.
2. «Читабельность» кода.
Тут главный контрольный вопрос нужно задать самому себе: «Смогу ли я в случае необходимости добавить новую фичу или пофиксить баг в инспектируемом коде?». Ответ должен быть положительным, в противном случае автору следует изменить код.
3. Наличие и полнота тестового покрытия.
- Все публичные классы и методы тестируются.
- Тестируются граничные условия.
- Достаточность тестирования «положительных веток» выполнения.
- Достаточность тестирования «отрицательных веток» выполнения.
4. Стоит добавить в свою копилку хорошие практики из чужого кода.
5. Корректность многопоточного кода.
- Доступ к общим данным синхронизирован.
- Отсутствуют deadlocks.
- Для синхронизации используется идиома RAII.
- Корректно обрабатывается возврат ресурсов в обработчиках ошибок.
- Нет утечки ресурсов.
6. Код обрабатывает возможные ошибки корректно.
7. Отсутствие видимых нежелательных побочных эффектов в других частях системы.
8. Корректность языковых конструкций.
- Применяются верные идиомы используемого языка и фреймворка.
- Использование корректных библиотек.
- Отсутствие вновь изобретенных «велосипедов».
- Отсутствие дублирования кода.
9. Все переменные проинициализированы правильными значениями.
Возможно, наш контрольный список поможет составить подходящий для вашего проекта.
Нужно отметить также еще один очень важный момент. Для проектов, в которых нет модульных тестов, инспекция — это, по большому счету, единственная эффективная методика предотвращения дефектов в коде. По крайней мере ничего другого на ум не приходит. Поэтому если в вашем проекте нет модульных тестов, в первую очередь следует внедрять инспекции и только потом — практику написания модульных тестов.
Итак, почему же инспекции настолько эффективны? Часто бывает, что при проектировании или работе с кодом у разработчика в какой-то момент «замыливается глаз», ум накрепко привязывается к определенному проектному решению или конкретному фрагменту кода. Инспекция является простым способом обратиться к коллективному разуму, который обладает большей гибкостью и свободой, — по принципу «две головы лучше».
Спасибо за внимание! Желаем вам приятных инспекций :)
Автор: ptsecurity
