Практические советы для эффективного инспектирования кода. Часть 2
Первая часть практических советов для эффективного инспектирования кода была написана более двух лет назад, но актуальность не потеряла. В данной статье содержатся ещё несколько советов, которые позволяют повысить эффективность этой сложной и ответственной практики. Если коротко, то инспекции надо проводить быстро, рассказывать о них, визуализировать и не пытаться объять необъятное.Инспекции должны заканчиваться быстро. Законченная инспекция — это когда весть код проинспектирован, все обнаруженные дефекты исправлены, а исправления проверены инспектором. Если инспекция длится долго, то возникают следующие проблемы: Трудно понять, кто чем занимается. Разработчики расфокусируются, то есть появляются одновременно несколько инспекций и задач, над которыми они работают, что ведет к ухудшению продуктивности. Инспекции становятся неактуальными, то есть на инспекцию был выдан один код, а реально в системе контроля версий уже другой. Инспекции становятся расфокусированными. Чем дольше идет инспекция, тем больше инспектируемый код получит исправлений, тем сложнее проводить инспекцию. Если инспекция длится больше трех дней, то с ней что-то не так — либо кто-то затягивает, либо пытается объять необъятное. Иногда инспектор видит, что задача подобного рода уже неоднократно решалась и если сделать некоторый рефакторинг, то похожие задачи можно было бы решать гораздо дешевле. В результате перед инспектором встаёт дилемма: либо писать в рамках инспекции замечание о том, что надо выполнить рефакторинг, либо не писать, так как рефакторинг может быть трудоёмким и незапланированным.С одной стороны, замечание надо запротоколировать, так как понимание нужности рефакторинга есть полезный результат работы инспектора, который надо сохранить. Кроме того, если не выполнить рефакторинг, то мы продолжим тратить впустую усилия при выполнении очередной похожей задачи. С другой стороны, если инспектор заведет такой дефект, то появится другая проблема — очень длинные инспекции. Выходом из ситуации является создание новой задачи по рефакторингу вне рамок этой инспекции. То есть, тяжёлые дефекты лучше заводить в виде отдельной задачи, для которой будет создана отдельная инспекция. Примерная оценка того, что такое «тяжёлый дефект» — это такой дефект, на исправление которого требуется потратить более двух часов.
Ничто не заменит живого общения. Бывают объективно сложные задачи, которые имеют сложные решения. В этом случае перед проведением инспекции автор может в живую рассказать и показать инспекторам решение с помощью пальцев, IDE, бумажки, или доски с фломастерами. Причем в идеальном случае автор сделает это до реализации решения, хотя лучше поздно, чем никогда. Но тут есть опасность — не стоит пытаться устными объяснениями исправить плохой нечитаемый код. Код остается плохим, даже если про него подробно все рассказали.Кстати, на такие рассказы иногда полезно приглашать тестировщиков. Знание деталей реализации поможет им тестировать более качественно и находить нетривиальные ошибки.
Инспектирование кода — это важная фаза жизненного цикла задачи наравне с разработкой и тестированием. Если вы используете scrum или canban доску, то имеет смысл выделить ещё один столбец для фазы инспектирования между столбцами «в разработке» и «готово к тестированию». В этом случае, доска будет более точно отражать реальное состояние дел, что от неё и требуется.
