G>Могу добавить, что PSP/TSP запрещает даже менеджеру доступ к индивидуальным статистикам. Их видит только сам исполнитель. Это требование процесса, которое должно реализовываться PSP-тулом.
Как-то мой опыт, интуиция протестуют. Но ничего конкретного сказать не могу.

G>Опять же, ты исходишь из того, что данные метрики объективно показывают качество работы программиста. Это не так, и в этом вся проблема.
Нет, я считаю что можно подобрать метрики так, что они будут объективно показыать некачественную работу программиста. Т.е. я только за те метрики которые однозначно указывают на изъяны.

Я еще вчера сказал, что нету рейтинга, а раз нету рейтинга, то нету и конкретных баллов.
Есть только объективные показатели:
1) покрытие 53% (надо 60%),
2) несоответствие стилю кодирования 6 мест,
3) 3 метода имеют комплисити больше 5,
4) тест SomeModule.DoThat провалился
...

G>Надо ли вести метрику, кто сколько раз ломает билд? Может быть. Говорит она о том, кто лучший программист? Да в общем, нет. Это исключительно характеристика разгильдяйства или невезучести.
Разгильдяю по башке, невезучему не может невезти всегда

G>Весь фокус не в самой метрике, а в процессе вокруг нее. Вот каким образом ты будешь ими пользоваться? А именно — кто, когда, и зачем будет их смотреть?
В основном сами программисты будут следить за своими успехами/неуспехами, достоинствами/недостатками.
Тимлид мониторит динамику: прислушиваются ли разработчики к советам робота. Однажды покрытие тестами всей системы упало ниже 50%. В чем причина? Все разработчики не пишут тесты, или кто-то один всех тянет вниз. Как это узнать?

G>1) Дубилрование кода
G>Интересно, как именно ты предлагаешь эту метрику считать.
Я знаю что есть тулзы которые считают. Более подробно этот вопрос не исследовал.
G>Но в любом случае — лучше не допускать этого на code review (вместе с проверкой соответствия стилевому руководству и стандарту кодирования) или design review.
Одно другому не мешает. К ревью можно приступить имея на руках результат автоматического анализа.
G>Когда у тебя код оказался задублирован в репозитории, и он успешно проходит тесты, строго говоря претензии к качеству предъявлять поздно.
Всегда можно сделать новый коммит, который уберет дублирование.
G>Код работает, ошибок нет — качество в порядке.
Неверный вывод. Качество это не только внешняя составлящая. Но еще и внутренняя. Недавно из коммандировки я привез приложение изнутри представляюее собой кучу говнокода, а для пользователей это приложение выглядит конфеткой и самое главное -- работает корректно. Но добавить в приложение небольшое изменение представляется проблематичным (1,5 недели у меня занял таск, который при нормальном дизайне отнял бы не больше дня).

G>2) Покрытие нового кода тестами
G>Технически сложно снять такую метрику. У тебя поменялось 10 файлов, каждый на 10-20 процентов — типичная ситуация для ОО программы. Это легко посчитать по продукту целиком или по подсистеме, но не по отдельному чекину.
Тулы проверки покрытия кода считают буквально построчно. Можно посмотреть, например, здесь (обрати внимание на картинку внизу: подсветка отдельных строчек).

G>Возвращаясь к вопросу кто когда и как — по хорошему надо ставить цель в области качества, и достигать ее. Скажем, покрытие кода по метрике строк кода делаем 100%. И это будет означать ровно одно — что у тебя нет кода, который в принципе ни разу не вызывался. Но это вовсе не говорит тебе о том, что у тебя программа хорошо оттестирована. А в другой метрике достичь 100% практически невозможно, это дорого и бесмысленно.
Я не предлагаю панацею, я предлагаю вспомогательный инструмент!!!!!!!!

G>3) Сложность методов (вложенные ифы, форы, ...)
G>Гхм. Эта метрика совершенно бесполезна, как и остальные метрики "сложности". Потому, что на ее основании вообще нельзя никаких выводов сделать. Ну "сложный" у тебя метод, ну дальше что? Если ты реально решил запретить слишком длинные и глубокие методы — вноси это в код стандарт, и контроллируй на code review. Так ты добьешься выполнения правила. А этой метрикой — кто, когда, и как?
G>Кроме того, можно плохой код десятком способов написать, а по твоей метрике чтобы написать хороший — достаточно нарезать на короткие методы как попало с бессмысленными названиями и все (кстати, именно так и поступит человек, который захочет подняться в твоем рейтинге).
По голове во время следующего код ревью.

G>4) В принципе, сюда можно добавить и количество строк кода. С одной стороны много не напишешь -- нужно покрытие тестами, много не скопипастишь,... , а с другой этому критерию можно дать низкий вес.
G>И что, чем больше пишем, тем лучше? Я могу одно и тоже в разницей в два раза написать легко, причем одинаковый тест даст то же самое покрытие.
Эта метрика выпадает из "нового видения" (см. начало поста)

G>>>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
A>>Как?
G>Cтавить конкретные цели в области качества (это правда очень сложно), и достигать их посредством code & design review. Серьезно заниматься политикой тестирования.
Ок, я только не понимаю почему в эту систему не вписывается автоматическая проверка? Предварительно, как помощь для человеческих методов оценки.

Z>Я попытался объяснить, что он будет часто мешать, в случае, когда оценка робота хоть что-то значит для программиста.
Непонимаю почему?

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

Вот цитата из моего поста:

Я еще вчера сказал, что нету рейтинга, а раз нету рейтинга, то нету и конкретных баллов.
Есть только объективные показатели:
1) покрытие 53% (надо 60%),
2) несоответствие стилю кодирования 6 мест,
3) 3 метода имеют комплисити больше 5,
4) тест SomeModule.DoThat провалился
...

Z>Достаточное среднее покрытие в 60% например, означает 100% покрытие 60% методов, а не 60% покрытие 100% за которым может уследить робот. Таким образом он будет ставить минусы за 40% комитов, что далеко от хорошей мотивации. С другой стороны, за 70% покрытие методов требующих 100% будет поставлен плюс, что запросто может играть роль отмазки от нудной доработки.
Это тоже отлавливается. А что отлавливается можно включить в метрику.
Z>Нарушения стандартов кодирования, которые легко проверить автоматически довольно редки и также легко исправляются автоматически (Resharper -> Reformat all) не являются особой проблемой, которая мешает проекту.
Довольно редки для тебя, для меня,... У новичков дело обстоит похуже.
Но в любом случае это не значит, что их не стоит держать хотя бы для страховки (если строители ходят в казках, это не значит, что им на голову каждый день кирпичи падают).
Z>Нарушение других стандартов (например правил именования сущностей в программе, правила использования исключений) проверяются далеко не так тривиально.
Что не может проверить робот -- проверяет человек.
Z>Возможно получилось излишне сумбурно. Главная мысль — оценку кода должен делать человек который отвечает за его качество (или те, кому он делегировал эту ответственность)
Бесспорно, но помочь ему робот может.
Z> и никто другой.
Как ты понимаешь, я с этим не согласен
Z>Ресурсы на разработку, внедрение и поддержку данного робота, тоже не стоит сбрасывать со счетов. Врядли они окажутся копеечными.
Внедрение -- да, поддержку -- врядли. Но не думаю, что это сложная задача.
Говорю не голословно, так как поднимал интегрэйшен сервер у себя в команде, на nAnt-овских скриптах (чисто get code, compile, deploy и письмо команда в случае неудачи). Поддержки это не требует никакой.

Здравствуйте, Aikin, Вы писали:

Z>>Я попытался объяснить, что он будет часто мешать, в случае, когда оценка робота хоть что-то значит для программиста.
A>Непонимаю почему?

A>Эти метрики конечно же не должны мешать работе. В этих метриках должны быть зашиты общие принципы (которые можно формализовать) требований к качеству.
A>Причем я не предлагаю отказывать в комите на основе этих показателей (а это можно сделать). Если есть причины проигнорировать комментарии робота -- игнорируй. Но ты должен сделать это осознанно.

A>1) покрытие 53% (надо 60%),
Как считать покрытие нового кода? Откуда взялись 60% именно для данного комита?
A>2) несоответствие стилю кодирования 6 мест,
Это наиболее объективная метрика из всех.
A>3) 3 метода имеют комплисити больше 5,
О чем это говорит?
A>4) тест SomeModule.DoThat провалился
Это проверит запуск тестов, билд окажется поломаным и никакой отчет робота уже не потребуется.

Z>>Достаточное среднее покрытие в 60% например, означает 100% покрытие 60% методов, а не 60% покрытие 100% за которым может уследить робот. Таким образом он будет ставить минусы за 40% комитов, что далеко от хорошей мотивации. С другой стороны, за 70% покрытие методов требующих 100% будет поставлен плюс, что запросто может играть роль отмазки от нудной доработки.
A>Это тоже отлавливается. А что отлавливается можно включить в метрику.
И как робот будет отличать код который требут 100% покрытия от кода не требующего покрытия вообще.

Z>>Нарушения стандартов кодирования, которые легко проверить автоматически довольно редки и также легко исправляются автоматически (Resharper -> Reformat all) не являются особой проблемой, которая мешает проекту.
A>Довольно редки для тебя, для меня,... У новичков дело обстоит похуже.
A>Но в любом случае это не значит, что их не стоит держать хотя бы для страховки (если строители ходят в казках, это не значит, что им на голову каждый день кирпичи падают).
Страховки от чего? От того, что кто-то увидит код с плохоми отступами? Это не крипич по голове, это нажатие 2х кнопок и устный выговор тому, кто это закомитил. В принципе я не против робота в данной ситуации, но игра стоит свеч только при очень высоких требованиях к стандартизации кода, например разработка библиотек и фреймворков.

Z>> и никто другой.
A>Как ты понимаешь, я с этим не согласен
Вобщем-то оценивать может кто угодно, лишь бы он не лез с этой оценкой в процесс разработки.

Z>>Ресурсы на разработку, внедрение и поддержку данного робота, тоже не стоит сбрасывать со счетов. Врядли они окажутся копеечными.
A>Внедрение -- да, поддержку -- врядли. Но не думаю, что это сложная задача.
A>Говорю не голословно, так как поднимал интегрэйшен сервер у себя в команде, на nAnt-овских скриптах (чисто get code, compile, deploy и письмо команда в случае неудачи). Поддержки это не требует никакой.
Интеграцию робота в CI я вообще не учитывал.

Имелись ввиду работы по разработке, внедрению и поддержке самого робота. Поддержка понадобится, настройки менять придется постоянно на этапе внедрения, да и позже.

Имейте ввиду, что каждому новичку придется уживаться не только с VCS, баг и таск трекером, CI сервером и еще какими-то инструментами, но еще и с роботом. Лишний инструмент должен давать очень хорошие бонусы, чтобы оправдать связаный с ним геморрой.

Начну с того, что метрики которые я дал в самом начале были даны как пример. Сейчас мы обсуждаем целесообразность этого метода вообще, а не конкретные метрики. Конкретные метрики обсудим позже. Но за основу можно взять Reporting plugins к Maven (checkstyle, clover, docck).
Дальше, почему запуск тестов проводимых автоматически (по сути роботом) мы отделяем от робота который анализирует код? Ведь это тоже анализ кода.

Z>И как робот будет отличать код который требут 100% покрытия от кода не требующего покрытия вообще.
А зачем ему это отличать?
У него прошито: каждый метод должен иметь покрытие не меньше 60% (число примерное, забитое в настройках число), он это и проверяет.

Z>>>Нарушения стандартов кодирования, которые легко проверить автоматически довольно редки и также легко исправляются автоматически (Resharper -> Reformat all) не являются особой проблемой, которая мешает проекту.
A>>Довольно редки для тебя, для меня,... У новичков дело обстоит похуже.
A>>Но в любом случае это не значит, что их не стоит держать хотя бы для страховки (если строители ходят в казках, это не значит, что им на голову каждый день кирпичи падают).
Z>Страховки от чего? От того, что кто-то увидит код с плохоми отступами? Это не крипич по голове, это нажатие 2х кнопок и устный выговор тому, кто это закомитил. В принципе я не против робота в данной ситуации, но игра стоит свеч только при очень высоких требованиях к стандартизации кода, например разработка библиотек и фреймворков.
Не утрируй. Из маленького разгильдяйства часто вырастает большое рас^%@*дяйство. А "цена свеч" не так уж и высока.

Z>>> и никто другой.
A>>Как ты понимаешь, я с этим не согласен
Z>Вобщем-то оценивать может кто угодно, лишь бы он не лез с этой оценкой в процесс разработки.
Т.е. ты там поиграйся с кодом, а отчет можешь себе в ... засунуть?
Еще раз: отчеты робота носят рекоментдательный характер с одной стороны, и предварительный анализ с другой.

Z>Имелись ввиду работы по разработке, внедрению и поддержке самого робота.
Z> Поддержка понадобится, настройки менять придется постоянно на этапе внедрения, да и позже.
Не буду утверждать то, чего не знаю. Но думается мне, что большинство CI серверов либо уже имеют такие плагины, либо предоставляют удобный интерфейс для написания своего.

Z>Имейте ввиду, что каждому новичку придется уживаться не только с VCS, баг и таск трекером, CI сервером и еще какими-то инструментами, но еще и с роботом.
И? Ну не будет робота, не получит он от него замечаний. Зато получит во время код ревью. А был бы робот он бы объяснил ему, что и как он делает не так. Что принято в команде. И объяснит получше, чем 30-страничный труд "требования к комитам в команде".

Z>Лишний инструмент должен давать очень хорошие бонусы, чтобы оправдать связаный с ним геморрой.
А какие бонусы дает CI, багтрекер, тасктрекер,... для маленького проекта на 5 человек и двух контактных лиц со стороны заказчика по сравнению с "гемороем"... Никаких!
Дело в другом, что все это обычно ставиться на организацию в целом, поэтому расходы по поддержке этих вспомогательных средств с течением времени стремяться к нулю.

Нет, я понимаю о чем ты говоришь. Даже разделяю твой скептицизм. И со многим согласен. Но я представляю сторонников подхода (так как я ее предложил)
Самое главное, что я хочу извлечь из этого обсуждения: нужно ли рассматривать эту идею в работе или нет.
Например идея с рейтингом (пуличным и нет) с треском провалилась. За это спасибо Гапертону. Вполне возможно вся идея так же провалится. Тоже хорошо.

Здравствуйте, Aikin, Вы писали:

G>>Код работает, ошибок нет — качество в порядке.
A>Неверный вывод. Качество это не только внешняя составлящая. Но еще и внутренняя.

Вот тольки не надо передёргивать термины. Качество — это соответствие между требованиями и продуктом.

То, что ты называешь "внутренним качеством" — это эстетические свойства, документированность, какая-нибудь там "степень ортогональности дизайна" и т.п., вплоть до литературных оценок. Код может быть красивым, чистым, понятным, хорошо (само-)документированным, ещё каким-то, но при этом не выполнять ту задачу, ради которой написан. В последнем случае он будет некачественным.

Да, можно выставить некоторые эстетические требования (например — соглашение о наименовании, ограничение дины строки, размер отступа и т.п.) и на основании замеров таких показателей вывести некий показатель "внутреннего качества кода", но к качеству конечного продукта этот показатель будет самое опосредованное отношение. Ты ещё попробуй докажи, что, например "высокие эстетические характеристики" обусловили выполнение проекта в срок. Во поэтому в целях экономии ресурсов менеджмент не занимается такой чепухой, как вычисление "эстетики" путём просчёта глубины if.

То же самое и с покрытием тестами. Да, можно покрыть каждый модуль на 100%, но что это даст? Правильный ответ: это даст самоудовлетворение разработчику от того, какой клёвый, всесторонне проверенный модуль он написал. Всё. На этом прямая польза заканчивается, потому что можно написать совершенно правильный модуль по очень неправильной спецификации. А если спецификация правильная, то достаточно чтобы текущий test case покрывал потребности модуля (модулей) верхнего уровня. При это совершенно не имеет значения, покрывается 95% внутренней структуры низкоуровневого модуля или, скажем, 41%.

Противоположный пример — модули общего использования, здесь может требоваться 100% покрытие. Может, хотя и не обязано, потому что общие модули тоже содержат свои под-модули, внутренние функции и т.п., для которых выполняется всё то, что я написал абзацем выше.

То есть опять таки, какие-то априорно необходимые показатели покрытия сработают в неизвестную сторону.

A>Недавно из коммандировки я привез приложение изнутри представляюее собой кучу говнокода, а для пользователей это приложение выглядит конфеткой и самое главное -- работает корректно. Но добавить в приложение небольшое изменение представляется проблематичным (1,5 недели у меня занял таск, который при нормальном дизайне отнял бы не больше дня).

Ну откуда мы знаем, а вдруг оставшийся "говнокод" был написан в рекордно короткие сроки маленькой командой разработчиков, которая, если бы занималась изысками "внутреннего качества", разрабатывала бы его в пять раз дольше, поставив под вопрос само существование проекта?

G>>>>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
A>>>Как?
G>>Cтавить конкретные цели в области качества (это правда очень сложно), и достигать их посредством code & design review. Серьезно заниматься политикой тестирования.
A>Ок, я только не понимаю почему в эту систему не вписывается автоматическая проверка? Предварительно, как помощь для человеческих методов оценки.

Ну потому что в первую очередь политика управления качеством нацеливается на качество конечного продукта, а не на то, насколько красив и изящен код и сколько в % Copy-Paste. Соответственно, и test cases должны в первую очередь покрывать сценарии работы конечного пользователя.

Автоматизированные замеры структурной сложности хороши, в общем, только для одной цели: примерно узнать соответствие между сложностями формулировок заданий и сложностью их выполнения. Такую статистику можно потом как-то попытаться использовать для прогнозирования трудозатрат. Но не более того. Пытаться, например, заставить кого-то "снизить среднюю цикломатическую сложность методов" — ну, это не смешно, потому что та же ЦС может быть обусловлена требованиями к структуре интерфейса, способом проверки параметров... И таких примеров можно найти или придумать — вагон.

Здравствуйте, Aikin, Вы писали:

A>Самое главное, что я хочу извлечь из этого обсуждения: нужно ли рассматривать эту идею в работе или нет.

Ни в коем случае, если ты предполагаешь негативную мотивацию разработчиков. Шо за манера, вообще — везде кнут искать. Выкинь из головы такие плохие мысли.

Ты, видимо, не заметил, в каком случае Гапертон употребил "по голове" — это был сугубо вопрос соблюдения процедуры. Здесь и в самом деле иногда без ругани не получается, но при этом, как я понимаю, нет цели унизить, это такой способ выражения эмоций, что есть хорошо.

Понимаешь, процедура — это строго заданная последовательность действий, которую должен выполнить отдельно взятый разработчик не имея при этом средств, которые гарантируют правильность прохождения этой самой последовательности. Например, общую процедуру разработки программы нарушить нельзя — сначала пишем код, потом компилируем. А вот процедуру checkin — очень даже можно.

Здравствуйте, Aikin, Вы писали:

A>Дальше, почему запуск тестов проводимых автоматически (по сути роботом) мы отделяем от робота который анализирует код? Ведь это тоже анализ кода.
Запуск тестов никоим образом не анализ кода.

A>У него прошито: каждый метод должен иметь покрытие не меньше 60% (число примерное, забитое в настройках число), он это и проверяет.
Я уже говорил, что тестируемые классы должны быть покрыты по максимуму, ближе к 100%, не тестируемые могут быть не покрыты вообще, какой смысл считать покрытие для отдельно взятого комита (в том мифическом случае, в котором мы вообще сможем посчитать "покрытие комита")?

A>Из маленького разгильдяйства часто вырастает большое рас^%@*дяйство.
Это я слышал, когда добивался свободного графика для себя и команды, тошнит от лозунга.
A>А "цена свеч" не так уж и высока.
Хочется увидеть хотя бы проект данной системы с оценкой трудозатарат. Спросите у ребят из JatBrains сколько стоит их система анализа кода.

Z>>Имелись ввиду работы по разработке, внедрению и поддержке самого робота.
Z>> Поддержка понадобится, настройки менять придется постоянно на этапе внедрения, да и позже.
A>Не буду утверждать то, чего не знаю. Но думается мне, что большинство CI серверов либо уже имеют такие плагины, либо предоставляют удобный интерфейс для написания своего.
Еще раз, интеграция робота в CI вообще не рассматривается как задача, по сравнению со всем остальным ей можно пренебречь.

Z>>Имейте ввиду, что каждому новичку придется уживаться не только с VCS, баг и таск трекером, CI сервером и еще какими-то инструментами, но еще и с роботом.
A>И? Ну не будет робота, не получит он от него замечаний. Зато получит во время код ревью. А был бы робот он бы объяснил ему, что и как он делает не так. Что принято в команде. И объяснит получше, чем 30-страничный труд "требования к комитам в команде".
У нас очень простое требование к комитам: законченый таск и зеленые тесты. Можно узнать, что у вас содержит занимательный документ на 30 страниц? Стандарты кодирования? К комиту они не имеют отношения.

Z>>Лишний инструмент должен давать очень хорошие бонусы, чтобы оправдать связаный с ним геморрой.
A>А какие бонусы дает CI, багтрекер, тасктрекер,... для маленького проекта на 5 человек и двух контактных лиц со стороны заказчика по сравнению с "гемороем"... Никаких!
Это даже коментировать не хочется. Это отлаженные и проверенные временем и множеством пользователей инструменты. Какой может быть геморой от их внедрения кроме выделения сервера и установки софта? Доказывать их рациональность не входит в мои планы и тему данной дискуссии.

A>Дело в другом, что все это обычно ставиться на организацию в целом, поэтому расходы по поддержке этих вспомогательных средств с течением времени стремяться к нулю.
Просто идиллия =) Переходим на C# 4.0, и мы долго и бесплатно пилим лексер робота для его поддержки. А если один из проектов лучше делать на F#?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Автоматизированные замеры структурной сложности хороши, в общем, только для одной цели: примерно узнать соответствие между сложностями формулировок заданий и сложностью их выполнения. Такую статистику можно потом как-то попытаться использовать для прогнозирования трудозатрат. Но не более того. Пытаться, например, заставить кого-то "снизить среднюю цикломатическую сложность методов" — ну, это не смешно, потому что та же ЦС может быть обусловлена требованиями к структуре интерфейса, способом проверки параметров... И таких примеров можно найти или придумать — вагон.

Cyclomatic complexity — это вообще бредовая метрика по сути свей. Она очень примерно оценивает снизу количество тесткейсов, требующихся для проверки отдельных функций, которые генерятся методом white box. И все. Это самая неинтуитивная метрика, которая не дает корреляций ни с одной другой, поэтому ее нельзя предсказать и она бесполезна. Например, часто после рефакторинга бывает, что количество строк кода сокращается, а cyclomatic complexity увеличивается. Потому, что размашисто написанный линейно-копипастный код с дубликатами имеет низкий cyclomatic complexity. А полиморфный многовариантный код — наоборот, высокий .

Здравствуйте, Gaperton, Вы писали:

G>Cyclomatic complexity — это вообще бредовая метрика по сути свей.

Да я в курсе. Это просто для примера, первое, что в голову пришло. ИМХО, вообще единственная метрика, которую имеет смысл пытаться снизить — это те самые LOC. Чем короче программа, тем на самом деле быстрее её можно понять, переколпакировать и выколпаковать. Но это ж настолько очевидно, что и обсуждать нечего. И самое забавное — как тогда привязывать метрики к "производительности труда"?

Здравствуйте, Aikin, Вы писали:

G>>Могу добавить, что PSP/TSP запрещает даже менеджеру доступ к индивидуальным статистикам. Их видит только сам исполнитель. Это требование процесса, которое должно реализовываться PSP-тулом.
A>Как-то мой опыт, интуиция протестуют. Но ничего конкретного сказать не могу.

Твой опыт и интуиция протестует против опыта самого Хамфри, а это автор CMM и PSP/TSP . Который полагается кстати не на интуицию, а на точные методы. Весь PSP/TSP построен на точной статистике с реальных проектов.

G>>Опять же, ты исходишь из того, что данные метрики объективно показывают качество работы программиста. Это не так, и в этом вся проблема.
A>Нет, я считаю что можно подобрать метрики так, что они будут объективно показыать некачественную работу программиста. Т.е. я только за те метрики которые однозначно указывают на изъяны.

Ты неправильно считаешь. Не существует ни одной метрики и их комбинации, которая бы однозначно указывала на изъяны в работе программиста.

A>Есть только объективные показатели:
A>1) покрытие 53% (надо 60%),
В какой метрике твои проценты? Ты в курсе, что количество тестов для полного прогона состояний экспоненциально от размера программы зависит? А по метрике LOC 100% покрытие тестами означает только лишь то, что у тебя нет в программе "мертвого" кода, который вообще ни разу не выполнился тестами (наличие которого, кстати, часто является вполне нормальным и неизбежным явлением) и ничего больше?

Я надеюсь, ты понимаешь что данный показатель не соотносится напрямую с ошибками? Ошибка, как правильно говорит Васильев, есть несоответствие требованиям, и ничего больше. И как максимизация данного процента поможет мне эти несоответствия отловить? А? Я как менеджер этим вообще не пользовался, и считаю глупостью полагаться на это как критерий качества. По двум причинам. Первая — твои 60% ровным счетом ничего не говорят о готовности продукта к релизу и его качестве. То есть они вообще никак к этому не относятся. Надежный показатель — процент проходящих use cases, которые отранжированы по критичности. Таким образом я проверяю соответствие продукта ТЗ, и делать мне надо именно это, а не мерять какой-то абстрактный процент. И если у меня все критичные юз-кейсы работают, то я выпущу продукт в релиз, даже если у меня какая-то чертова тулза покажет всего 20% покрытие тестами. Потому что эта тулза понятия не имеет о том, кто и как будет мой продукт применять. Тратить ресурсы на подъем дурацкого покрытия силами программистов, заставляя их выдумывать тесты больше 60% — блин, лучше я потрачу это время на разработку толкового тестплана, который покажет, какие тесты мне реально нужны, и буду контролировать его наличие и соответствие ТЗ. Толку всяко больше.

Кроме того, не для всякого кода вообще целесообразно писать юнит-тест. Во многих случаях это глупая трата сил, плюс еще и создающая опасную иллюзию, что у тебя якобы хорошо оттестирован продукт.

A>2) несоответствие стилю кодирования 6 мест,
Условие прохождения code review, который делается ДО чекина, а не после. Метрику из этого делать смысла нет.

A>3) 3 метода имеют комплисити больше 5,
И что? У тебя программа хуже работать от этого станет? Разработчики, думаешь будут следить за этой метрикой? А ты проведи опрос на заглавной странице РСДН. Ты вот сам — хорошо, в деталях понимаешь, что показывает метрика complexity, и какой у нее физический смысл? Может, ты ее предсказывать умеешь?

A>4) тест SomeModule.DoThat провалился
Условие успешного закрытия задачи, из этого не надо делать метрику. Смысла нет.

G>>Надо ли вести метрику, кто сколько раз ломает билд? Может быть. Говорит она о том, кто лучший программист? Да в общем, нет. Это исключительно характеристика разгильдяйства или невезучести.
A>Разгильдяю по башке, невезучему не может невезти всегда
Разгильдяю безусловно по башке, о чем я и сказал ниже в том посте.

G>>Весь фокус не в самой метрике, а в процессе вокруг нее. Вот каким образом ты будешь ими пользоваться? А именно — кто, когда, и зачем будет их смотреть?
A>В основном сами программисты будут следить за своими успехами/неуспехами, достоинствами/недостатками.
Ага, щаз. Делать им больше нечего. Им эти твои метрики не нужны, они нужны тебе, и нет ничего, что бы заставило их следить за "успехами и неудачами". Начать стоит с того, что редкий программист будет их связывать со значениями метрик. Опять же, проведи опрос, увидишь кто прав.

A>Тимлид мониторит динамику: прислушиваются ли разработчики к советам робота. Однажды покрытие тестами всей системы упало ниже 50%. В чем причина? Все разработчики не пишут тесты, или кто-то один всех тянет вниз. Как это узнать?

"Однажды покрытие тестами упало ниже 50%". Программисты удалили юнит-тесты?

G>>1) Дубилрование кода
G>>Интересно, как именно ты предлагаешь эту метрику считать.
A>Я знаю что есть тулзы которые считают. Более подробно этот вопрос не исследовал.
Надо хорошо, в деталях, понимать алгоритм рассчета метрик, перед тем как думать, как их применять. У меня вот, скажем, большие сомнения, что эти тулзы способны надежно сосчитать процент креативного копипаста в разрезе людей. А раз так — доверять им и строить на них процесс нельзя.

G>>Когда у тебя код оказался задублирован в репозитории, и он успешно проходит тесты, строго говоря претензии к качеству предъявлять поздно.
A>Всегда можно сделать новый коммит, который уберет дублирование.
Не всегда можно сделать такой коммит. У тебя факт дублирования может быть заложен архитектурно. А идиотов копипастеров, которые копипастят так запросто, я лично на работу не беру. И ни разу такого еще живьем не видел за последние 10 лет. И вообще — это проблема не настолько масштабна и распространена, чтобы вот так специально с ней бороться.

G>>Код работает, ошибок нет — качество в порядке.
A>Неверный вывод. Качество это не только внешняя составлящая. Но еще и внутренняя.

Неверная догадка. "Качество" в управлении разработкой ПО определяется количеством дефектов, которые находят пользователи и тестеры. Это общепринятая терминология, которой тебе лучше следовать, если ты взялся говорить об управлении проектами. Метрика, "характеризующая" качество — это "плотность дефектов" на тысячу строк кода.

A>Недавно из коммандировки я привез приложение изнутри представляюее собой кучу говнокода, а для пользователей это приложение выглядит конфеткой и самое главное -- работает корректно. Но добавить в приложение небольшое изменение представляется проблематичным (1,5 недели у меня занял таск, который при нормальном дизайне отнял бы не больше дня).

Это называется не "качество", а Mainteinability, или "цена внесения изменений". Показатели эти разные. И бывает так, что mainteinability вполне сознательно жертвуют в целом ряде случаев, и это вполне нормально. Скажем, если в подсистему очень редко вносятся изменения, и она давно стабилизировалась — разумеется предпочтительнее вносить туда изменения, которые менее рискованные и менее затратные, не требующие рефакторингов, ценой ухудшающейся mainteinability. Потому что этот коэффициент — это по сути некий резерв и ресурс, которым можно и нужно пользоваться. То, что это противоречит твоей интуиции и эстетическому чувству — извини, но это несущественный фактор.

G>>2) Покрытие нового кода тестами
G>>Технически сложно снять такую метрику. У тебя поменялось 10 файлов, каждый на 10-20 процентов — типичная ситуация для ОО программы. Это легко посчитать по продукту целиком или по подсистеме, но не по отдельному чекину.
A>Тулы проверки покрытия кода считают буквально построчно. Можно посмотреть, например, здесь (обрати внимание на картинку внизу: подсветка отдельных строчек).

За скриншот конечно спасибо, но ты думаешь, я не знаю, что такое test coverage? Ты привел тул, который дает самую тупую метрику coverage, вообще-то. В строках кода. Есть существенно более продвинутые метрики, которые учитывают разные способы, которыми ты попадаешь в блок кода. Тем более, к вопросу это не относится.

По отдельному чекину покрытие когда сообразишь как считать, тогда скажи, хорошо? Еще интересно узнать, как ты будешь иметь дело с раздельными чекинами кода и юнит-тестов. А еще — с ситуацией, когда один разработчик накрывает тестами подсистему, которую писали двое или трое.

G>>Возвращаясь к вопросу кто когда и как — по хорошему надо ставить цель в области качества, и достигать ее. Скажем, покрытие кода по метрике строк кода делаем 100%. И это будет означать ровно одно — что у тебя нет кода, который в принципе ни разу не вызывался. Но это вовсе не говорит тебе о том, что у тебя программа хорошо оттестирована. А в другой метрике достичь 100% практически невозможно, это дорого и бесмысленно.
A>Я не предлагаю панацею, я предлагаю вспомогательный инструмент!!!!!!!!

А инструмент без методики его применения, и конкретной и насущной потребности, которую он решает, никому не нужен!!!!! Ты в курсе?!!!!!!

Вспомогательный инструмент предлагают разработчики этой тулзы, ссылку на которую ты дал, и тулза эта — рабочий инструмент разработчика юнит-теста, которая помогает ему понять, как лучше писать юнит-тест, в процессе его написания. А инструмент для раздавания люлей после чекинов и поиска виноватых, что настойчиво собираешься делать ты.

G>>3) Сложность методов (вложенные ифы, форы, ...)
G>>Гхм. Эта метрика совершенно бесполезна, как и остальные метрики "сложности". Потому, что на ее основании вообще нельзя никаких выводов сделать. Ну "сложный" у тебя метод, ну дальше что? Если ты реально решил запретить слишком длинные и глубокие методы — вноси это в код стандарт, и контроллируй на code review. Так ты добьешься выполнения правила. А этой метрикой — кто, когда, и как?
G>>Кроме того, можно плохой код десятком способов написать, а по твоей метрике чтобы написать хороший — достаточно нарезать на короткие методы как попало с бессмысленными названиями и все (кстати, именно так и поступит человек, который захочет подняться в твоем рейтинге).
A>По голове во время следующего код ревью.

1) Менеджмент имеет мало общего с битьем по голове и прочим kicking the ass.
2) Код ревью просто-напросто не пропускает код с ошибками в репозиторий, в чем его функция и состоит. Ошибкой считается либо реальный баг, либо несоблюдение кодстандарта и стилевого руководства. Все остальное — не ошибка. И если у меня есть код ревью, то мне не нужна эта твоя метрика. Просто ну совершенно не вперлась. Ну будет у меня в репозитории "плохого" кода.

G>>4) В принципе, сюда можно добавить и количество строк кода. С одной стороны много не напишешь -- нужно покрытие тестами, много не скопипастишь,... , а с другой этому критерию можно дать низкий вес.
G>>И что, чем больше пишем, тем лучше? Я могу одно и тоже в разницей в два раза написать легко, причем одинаковый тест даст то же самое покрытие.
A>Эта метрика выпадает из "нового видения" (см. начало поста)

При этом, эта метрика — единственная, которая реально полезна, из всех, которые ты перечислил. Прикинь?!

G>>>>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
A>>>Как?
G>>Cтавить конкретные цели в области качества (это правда очень сложно), и достигать их посредством code & design review. Серьезно заниматься политикой тестирования.
A>Ок, я только не понимаю почему в эту систему не вписывается автоматическая проверка? Предварительно, как помощь для человеческих методов оценки.

Во-первых потому, что проверка, о которой ты говоришь, не предварительная. Coverage по LOC полезнее всего мерять в процессе создания unit-test, а не после того, как он отчекинен. Во-вторых, потому, что данная проверка по факту лишена смысла и пользы особой не несет — если ты не провел статистически достоверного исследования корреляций плотности ошибок с процентом тестового покрытия, то ты не можешь осмысленных и внятных целей ставить по проценту покрытия не с потолка. Проведешь такое исследование? А ведь для него метрика "строки кода покрытые тестами" не подойдет, корреляции не даст. Корреляцию теоретически может дать более тонкая метрика — процент покрытия входов логических выражений в условиях и ветвлениях.

И то, кстати, еще непонятно, насколько строгая корреляция будет, и насколько экономически выгодно все накрывать юнит-тестами с хорошим покрытием. Я, например, сторонник техники инвариантов, которые в сочетании с меньшим тестовым покрытием дает гораздо больший отлов дефектов, и обходится дешевле.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да я в курсе. Это просто для примера, первое, что в голову пришло. ИМХО, вообще единственная метрика, которую имеет смысл пытаться снизить — это те самые LOC. Чем короче программа, тем на самом деле быстрее её можно понять, переколпакировать и выколпаковать. Но это ж настолько очевидно, что и обсуждать нечего. И самое забавное — как тогда привязывать метрики к "производительности труда"?

Дык. Считать коэффициент LOC/day, как это я описываю в презентации, и делать все, чтобы ни у кого даже тени подозрения не возникло, что это кто-то в принципе может применить для оценки производительности труда. Тогда — эти коэффициенты реально помогут при планировании — конечно при условии что время и объем вообще даст корреляцию на твоих завершенных проектах. Это надо проверить.

Презентация здесь. http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf

Здравствуйте, Геннадий Васильев, Вы писали:

G>>Cyclomatic complexity — это вообще бредовая метрика по сути свей.

ГВ>Да я в курсе. Это просто для примера, первое, что в голову пришло. ИМХО, вообще единственная метрика, которую имеет смысл пытаться снизить — это те самые LOC. Чем короче программа, тем на самом деле быстрее её можно понять, переколпакировать и выколпаковать. Но это ж настолько очевидно, что и обсуждать нечего.

Кстати. Вот сейчас умный мысль скажу.

Впрямую стимулировать короткие программы весьма затруднительно, по крайней мере не понятно, как это делать. Однако. Есть пара фактов:
1) В среднем разброс в размере LOC для одной и той же задачи укладывается в коридор "вдвое". Это то, что я видел своими глазами на тренингах по PSP/TSP — скажем, 7 человек уложилось в порядка 100 строк, в то время как остальные 13 — в порядка 200 строк. Единичные выбросы не считаем, на то они и выбросы.
2) Опять же, факт, что на предварительное проектирование разные люди тратят разный процент времени решения задачи. При этом, что странно, время решения задачи изменяется от этого процента почти не зависит, по крайней мере если говорить об изолированных задачах средней сложности.

Я подозреваю, что процент времени на предварительное проектирование обратно пропорционален размеру кода, ну может не пропорционален, но должен кореллировать. Отсюда вывод такой — надо стимулировать тратить больше времени на предварительное проектирование. И тогда ты добьешься более компактного кода. Менеджерам — не надо боятся делать фазу проектирования длиннее. Это именно то, что советует Том ДеМарко в Deadline — "кодируйте в последний момент". Правда, Том говорит о 1/6 на кодирование как цель, что, гхм, вызывает у меня некоторое недоверие. Но от себя скажу — не менее трети времени на проектирование, это должно быть must have. Ну, а более 60% мне становится уже как менеджеру закладывать страшновато по любому.

Здравствуйте, Aikin, Вы писали:

G>>Могу добавить, что PSP/TSP запрещает даже менеджеру доступ к индивидуальным статистикам. Их видит только сам исполнитель. Это требование процесса, которое должно реализовываться PSP-тулом.
A>Как-то мой опыт, интуиция протестуют. Но ничего конкретного сказать не могу.

Я могу. Это называется самоутверждением и поиском методов самоутверждения. Не переживай и не пугайся, это проходит.

Хуже другое, нормальная команда должна быть свободна от того, чтобы её члены пытались самоутвердиться за счёт своих коллег. Ну, там, развесить ярлыки "хуже-лучше", помериться длиной органов и т.п., если это не в шуточном виде, конечно. Скандалить — можно, ругаться — вполне, а вот унижать других равных — ни-ни.

Вот поэтому Хамфри и ввёл запрет на публикацию личных метрик. У нас это, к сожалению, не понимают зачастую ни руководители, ни подчинённые.

Здравствуйте, Gaperton, Вы писали:

G>Дык. Считать коэффициент LOC/day, как это я описываю в презентации, и делать все, чтобы ни у кого даже тени подозрения не возникло, что это кто-то в принципе может применить для оценки производительности труда. Тогда — эти коэффициенты реально помогут при планировании — конечно при условии что время и объем вообще даст корреляцию на твоих завершенных проектах. Это надо проверить.

Да. Да. Да. Только прогнозирование.

G>Презентация здесь. http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf

А я её смотрел. По-моему, даже твой постинг с этой презентацией как-то отметил.

Спасибо всем кто принял участие в дискуссии. Особенно Гапертону и Ziaw-у.
Еще спасибо Геннадию Васильеву за участие. Единственно жаль, что я, судя по всему, еще не дорос до того, чтобы понять его советы.

В общем идею признаю провалившейся по всем направлениям.

Лучше поставить ReSharper с плагином AgentSmith которые будут "снимать метрики" в RealTime. Или другую аналогичную тулзу. Которая будет рекомендовать стиль кодирования программисту, следить за наличием документации и другими характеристиками кода.
Периодически проводить код ревью и пояснять почему стоит послушаться Решарпер.
А на интегрейшен сервер возложить только билд и прогонку тестов. Никаким дополнительным анализом заниматься ему не надо.

Что еще можно добавить?

Еще раз всем спасибо, с уважением Aikin.

Здравствуйте, _Dinosaur, Вы писали:

M_E>>Я думаю можно сделать автоматическую рассылку — чтобы все получали список сотрудников и кол-во задач, которые они закрыли за день или неделю.

_D>В этом случае, надо быть готовым к ответу на следующий вопрос:
_D>"почему при закрытии меньшего числа тасков или объема работ другой сотрудник получает такую же или большую з/п"

Ну тут как раз всё просто. Ответ такой: "потому что зарплата у нас определяется должностью, а вот promotion — уже дело индивидуальное" и многозначительно подмигиваешь глазом

Как обычно — Гапертон дело говорит

Мотивация от строк кода — вообще бред, особенно на поддержании уже созданного продукта.

A>Любая оценка отдельных людей будет провоцировать конкурентные отношения в команде. В итоге у вас получится группа индивидуумов каждый из которых "тянет одеяло на себя".

+10

Великолепно! как я сам не догадался

Да, так можно спровоцировать, например, "прижимистость" типа "никого не пущу в свой код, это мое!". Зла от нее больше, чем добра.

Еще есть риск промотивировать лизание зада, не прямыми унижениями, а по типу "да-да-да, я знаю генеральную линию компании и я ей следую изо всех сил, больше других!".

В таких случаях ценят тех, кто дольше работает и "имеет безупречную операцию". Вот за это и давайте звезды — за выслугу годов. Например, индексируйте 13-ю ЗП в зависимости от выслуги и репутации. Старичкам — более удобные места, более новые компы, смотреть сквозь пальцы на график работы и т.д.
Также будет действенна иногда и стратегия "кнута" — не двайте зазнаваться и почивать на лаврах старичкам, не позволяйте молодым расхалаживать коллектив и нарушать дисциплину.
Скорее всего в такой области надо заранее смирится с текучкой кадров, вам важно оставить и держкать "костяк" — тех на которых это все держится, это скорее всего будет несколько самых опытных человек. Вот их и мотивируйте указанным выше способом.