вторник, 5 июня 2012 г.

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

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

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

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

clip_image002

ПРИМЕЧАНИЕ
Терминологическая дилемма: многие программисты не стесняются применять оригинальные термины в работе (а иногда и в повседневной жизни), так что вполне возможно применять термин 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 строк кода может дать неплохое представление о качестве кода.

2 комментария:

  1. Я смотрю, у тебя несколько скептическое отношение к agile методикам :). Из своей практики могу сказать, что не 20 процентов кода используется для design review. Тут вопрос скорее психологический. Насколько комфортно чувствует себя человек, когда ругают ЕГО(еще раз ЕГО) архитектурное решение. Нужно очень много работать над собой, чтобы быть уверенным в себе и принимать более лучшие решения(читай чужие) и не комплексовать по этому поводу. А так, если разработчик квалифицированный он сам принимает решение, когда нужно использовать design review. Лично для меня знак что необходимо design ревью - это очевидность, что изменения затронут слишком многое или неуверенность, что все сделано однозначно.

    ОтветитьУдалить
  2. Ну, agile он такой agile :)
    Но ты прав, у меня, в целом, довольно скептическое отношение к этой тяге и их бесконечным принципам. Вот Мейеру я верю, уважаю Боба Мартина, но не люблю его категоричность.

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

    По поводу объема: мы стараемся ревьюить не только код, который много меняет, но и обязательно новую функциональность.

    ОтветитьУдалить