Контекст, в котором не работают метрики
Вы можете подумать, что софтверные метрики вообще не работают. И вы будете не правы.
Они работают. Работают везде. Их работа проявляется в наличии следующих наблюдаемых и измеримых статистических закономерностей:
1) Наличие статистически значимой корелляции время-объем. То есть, метрика объема, например, строки кода, или кубометры выкапываемой ямы, тем в среднем больше, чем больше времени уходит на закрытие задачи по написанию кода или рытью оной ямы, и наоборот.
Да, да. Корелляция наблюдается не смотря на то, что разные программисты склонны укладывать одну задачу в разное количество строк кода, разные землекопы - копать с разной скоростью, и в разных задачах цена строки кода разная, так же, как проще копать песок, чем каменистую почву.
2) Наличие статистически значимой корелляции объема и количества ошибок. То есть, в среднем, количество косяков в работе тем больше, чем больше объем кода или количество кубометров ямы, в которую надо рыть.
3) Наличие обратной корелляции времени, и плотности ошибок. То есть, чем больше времени в среднем затрачено на тот же самый объем, тем меньше будет неустраненных косяков на кубометр или тысячу строк. И наоборот - студент может две тысячи строк кода за выходные нахерачить, но ошибок там будет...
Многие думают, что "статистически значимаемая корелляция" означает прямую зависимость, то есть - величины прямо пропорциональны. Это не так. Это настолько сильно не так, что, если вы пропустили курс тервера с матстатом - вы удивитесь насколько. Облако точек на плоскости, в котором, на ваш взгляд, нет особой зависимости, может давать неплохую корелляцию.
Нафига нам нужны эти корелляции? Для планирования, конечно же.
Разумеется, применительно к программированию, надо уметь правильно считать метрики, чтобы в них наблюдались корелляции. Взять, например, объем. Взять, например, нелюбимые многими строки кода - SLOC.
Они дают наилучшие корелляции со временем из всех метрик объема, если их правильно считать. Что же тут сложного?
Правило. Строкой кода считается такая строка, ошибка в которой может быть найдена тестированием продукта.
Понятное дело, что посчитанные таким образом строки не испортят корелляцию с ошибками, не так ли? :) И улучшат ее со временем. Итак, это правило безусловно означает, что:
1) Пустые строки - не считаются.
2) Комментарии - не считаются.
3) Автогенерированный код - не считается. Вы его ручками не пишете, и времени на его отладку не тратите. И нефиг придираться.
Если этих правил не соблюдать, корелляций не будет вообще. Не безусловно (ибо, мне достоверно известно, что вышеприведенных условий для корелляции достаточно), это правило также означает:
1) Операторные скобки (отдельно стоящие { } begin end etc) - не считаются.
2) Декларации типов/функций - не считаются.
Как правильно? А вы измерьте корелляции время-объем на своих реальных проектах - это совсем не сложно. И посмотрите, где сильнее.
Это, уважаемые коллеги, не обсуждается. Для меня это вопрос давно решенный - я видел эти корелляции как на своем собственном, так и на чужом коде в нескольких организациях. Хотите поспорить - померьте на своих проектах. И учтите, что для заявления о наличии или отсутствии корелляции требуется не менее пяти точек.
Дело в другом. В современном контексте, эти корелляции объективно не работают :).
Причина в современных IDE с рефакторингом - для Java и C#. Штука в том, что автоматический рефакторинг средствами IDE гарантированно не вносит ошибок, и производит туеву хучу изменений кода. Которая размазывает корелляции.
Разумеется, такие изменения идут по категории "автогенеренный код", но как их вычесть из общих изменений? :)
PS: Эту загадку загадал мне сегодня Саша Барахтян. Замечательный инженер и талантливый менеджер.
Он сначала назвал мне аномальные значения метрик по команде, и попросил их объяснить. После того, как у меня кончились гипотезы - рассказал удивительную разгадку. Со словами - "ты прикинь?!" :) Да, мы оба по опыту плюсовики, у нас авторефакторинг был не в ходу. Над названиями полагалось как следует думать _до_, а не после. Ретрограды, ага :)
Они работают. Работают везде. Их работа проявляется в наличии следующих наблюдаемых и измеримых статистических закономерностей:
1) Наличие статистически значимой корелляции время-объем. То есть, метрика объема, например, строки кода, или кубометры выкапываемой ямы, тем в среднем больше, чем больше времени уходит на закрытие задачи по написанию кода или рытью оной ямы, и наоборот.
Да, да. Корелляция наблюдается не смотря на то, что разные программисты склонны укладывать одну задачу в разное количество строк кода, разные землекопы - копать с разной скоростью, и в разных задачах цена строки кода разная, так же, как проще копать песок, чем каменистую почву.
2) Наличие статистически значимой корелляции объема и количества ошибок. То есть, в среднем, количество косяков в работе тем больше, чем больше объем кода или количество кубометров ямы, в которую надо рыть.
3) Наличие обратной корелляции времени, и плотности ошибок. То есть, чем больше времени в среднем затрачено на тот же самый объем, тем меньше будет неустраненных косяков на кубометр или тысячу строк. И наоборот - студент может две тысячи строк кода за выходные нахерачить, но ошибок там будет...
Многие думают, что "статистически значимаемая корелляция" означает прямую зависимость, то есть - величины прямо пропорциональны. Это не так. Это настолько сильно не так, что, если вы пропустили курс тервера с матстатом - вы удивитесь насколько. Облако точек на плоскости, в котором, на ваш взгляд, нет особой зависимости, может давать неплохую корелляцию.
Нафига нам нужны эти корелляции? Для планирования, конечно же.
Разумеется, применительно к программированию, надо уметь правильно считать метрики, чтобы в них наблюдались корелляции. Взять, например, объем. Взять, например, нелюбимые многими строки кода - SLOC.
Они дают наилучшие корелляции со временем из всех метрик объема, если их правильно считать. Что же тут сложного?
Правило. Строкой кода считается такая строка, ошибка в которой может быть найдена тестированием продукта.
Понятное дело, что посчитанные таким образом строки не испортят корелляцию с ошибками, не так ли? :) И улучшат ее со временем. Итак, это правило безусловно означает, что:
1) Пустые строки - не считаются.
2) Комментарии - не считаются.
3) Автогенерированный код - не считается. Вы его ручками не пишете, и времени на его отладку не тратите. И нефиг придираться.
Если этих правил не соблюдать, корелляций не будет вообще. Не безусловно (ибо, мне достоверно известно, что вышеприведенных условий для корелляции достаточно), это правило также означает:
1) Операторные скобки (отдельно стоящие { } begin end etc) - не считаются.
2) Декларации типов/функций - не считаются.
Как правильно? А вы измерьте корелляции время-объем на своих реальных проектах - это совсем не сложно. И посмотрите, где сильнее.
Это, уважаемые коллеги, не обсуждается. Для меня это вопрос давно решенный - я видел эти корелляции как на своем собственном, так и на чужом коде в нескольких организациях. Хотите поспорить - померьте на своих проектах. И учтите, что для заявления о наличии или отсутствии корелляции требуется не менее пяти точек.
Дело в другом. В современном контексте, эти корелляции объективно не работают :).
Причина в современных IDE с рефакторингом - для Java и C#. Штука в том, что автоматический рефакторинг средствами IDE гарантированно не вносит ошибок, и производит туеву хучу изменений кода. Которая размазывает корелляции.
Разумеется, такие изменения идут по категории "автогенеренный код", но как их вычесть из общих изменений? :)
PS: Эту загадку загадал мне сегодня Саша Барахтян. Замечательный инженер и талантливый менеджер.
Он сначала назвал мне аномальные значения метрик по команде, и попросил их объяснить. После того, как у меня кончились гипотезы - рассказал удивительную разгадку. Со словами - "ты прикинь?!" :) Да, мы оба по опыту плюсовики, у нас авторефакторинг был не в ходу. Над названиями полагалось как следует думать _до_, а не после. Ретрограды, ага :)