Лучшая метрика для определения качества кода

Небезызвестный камрад Боба Мартин в своей книге «Чистый код» использует очень интересную метрику для определения качества кода. В оригинальном издании книги эта метрика определялась количеством WTFs/minute, замеченных во время инспекции кода (code review).

Однако при переводе произошла досадная ошибка и наши локализаторы вместо замечательной метрики, “WTFs/minute”, добавили, можно сказать, свою собственную метрику, чуждую отечественному разработчику: «количество чертей в секунду».

Любой опытный программист, который хотя бы раз в жизни проводил code review (или его замечательный код подвергался этой процедуре), знают, что никакими «чертями» в этом процессе и не пахнет. Во время чтения чужого кода непонимание и восхищение выражается самым разнообразным образом, но если уж адаптировать оригинальный термин к русскоязычной аудитории, то я бы сказал, что наиболее близким вариантом этой метрики является количество «чезанахов» в минуту.

ПРИМЕЧАНИЕ
Терминологическая дилемма: многие программисты не стесняются применять оригинальные термины в работе (а иногда и в повседневной жизни), так что вполне возможно применять термин WTF в своей работе. Более того, благодаря своей выразительности, этот термин может легко заменить ряд других устойчивых выражений, таких как code smell и antipattern.

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

Бывают и более формальные инспекции, когда на помощь приходят инструменты (Crucible, Code Collaborator или TFS), тогда «чезанахи» могут быть более детальными и развернутыми, могут существовать различные уровни «чезанахов», начиная от «чезанах, а как же наше стили кодирования» и «чезанах здесь вообще происходит», до «чезанах, это же грохнется в рантайме».

Design Review

Основной смысл нашей работы заключается не в уменьшении количества удивленных взглядов со стороны коллег во время code review, а в уменьшении «чезанахов» со стороны пользователей наших систем. Все мы знаем, что стоимость ошибки обратно пропорциональна времени ее нахождения. Это значит, что чем раньше мы найдем ошибку во время жизненного цикла разработки, тем лучше. Именно поэтому нахождение ошибок на стадии code review предпочтительнее, нежели нахождение оной тестировщиком или, тем более пользователем.

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

Обычно для решения этой проблемой перед этапом разработки идут этапы анализа и дизайна. Этап проектирования (дизайна) по своей природе очень тесто связан с самой разработкой (по сути, они идут итеративно друг за другом), поэтому он редко выделяется и зачастую полностью игнорируется. Этап проектирования мало кому интересен, да еще и все новомодные agile методологии уменьшают его роль. В эпоху зарождения XP вообще считалось, что дизайн и архитектура – это нечто совершенно несущественное и хороший дизайн и так волшебным образом возникнет из тестов и хорошего кода (хотя сейчас даже ярые адепты agile методологий не столь категоричны).

Однако с точки зрения управляемости процесса разработки design review может быть даже важнее, поскольку «чезанах» на этом этапе может сберечь массу времени, потраченного впустую на неверное или ненужное решение. Да и code review будет на порядок эффективнее, если человек анализирующий чужой код отлично представляет основные моменты решения.

Заключение

Как и любой другой инструмент, инспекции кода могут быть полезным инструментом или глупым этапом бюрократической машины. Чтобы это дело работало, нужна соответствующая культура; когда «чезанахи» воспринимаются командой как личное оскорбление, то толку от инспекций будет мало. Да и применять его можно не ко всему коду, а к 20% наиболее критических мест, стоимость ошибок в которых будет максимальной.

Если же применять этот инструмент по назначению, то количество «чезанахов» в минуту или на 100 строк кода может дать неплохое представление о качестве кода.