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

A>В Toyota вам придется познакомиться с философией Дзэн. «Как только вы понимаете, что это и есть сам процесс, и искать плато не нужно, вы можете расслабиться. Выполнение работы и улучшение ее качества становятся единым целым, – говорит Шук. – Вот это и означает – приступить к делу».

У нас похоже эта философия плохо приживается http://www.autonews.ru/autobusiness/news.shtml?2008/06/23/1372071

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

ГВ>Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц).

Если брать большие временые промежутки месяц и больше то да есть некое среднее, но на малых колебания на порядки, я например бывает свою среднюю дневную норму могу и за пару часов сделать, а бывает и за неделю

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

A>>P.S. Прошу прощения за сумбурное изложение
M_E>Это все конечно верно, но не совсем
M_E>Но вы немного подменяете понятния — одно дело — свобода творчества, а другое — отлынивание от работы.

Есть один интересный постинг на тему свободы творчества, почитай: Путевой дневник левой сандалеты: Прафутбол и нифутбол — 2: Как именно ему не слабо

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

ГВ>>Я знаю, что звучит это странно. Честно говоря, когда измерил — сам удивился. Ради интереса попробуй сам сделать такие же замеры (скажем — KLOC/Day на интервале в неделю, а лучше — месяц).

FR>Если брать большие временые промежутки месяц и больше то да есть некое среднее, но на малых колебания на порядки, я например бывает свою среднюю дневную норму могу и за пару часов сделать, а бывает и за неделю

Да, как раз об этом и речь. На малых промежутках колебания могут быть +/- бесконечность. Константа появляется на больших интервалах.

Здравствуйте, Michael_E_Smrinov,

не будет ли более эффективным разделить персонал на несколько групп (2-3 группы разработчиков, группа тестеров, группа техподдержки, группа техписателей, etc. — по реалиям организации вашего процесса), назначить/выделить лидов и спрашивать уже с них. А внутри групп — пусть они сами разбираются. Короче, делегируй часть своих полномочий (но не ответственности!).

G>Я знаю, какие они обычно бывают, потому что мы измеряли фактические цифры работая по PSP/TSP.
Так поделись. Или это цифры что даны выше?

Извиняюсь что долго не отвечал -- вермени было мало, а тут нельзя ответить быстро.

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

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

A>>Важно чтобы эту оценку делала "бездушная машина" и могла объяснить почему она это так сделала: 10 очков получил за покрытие тестами, 5 за низкую сложность кода (complexity), 20 очков сняли потому, что закомиченный код на 87% копипаст кода Васи... Это нужно для того, чтобы люди знали что им нужно улучшить в своей работе, чтобы добится хорошего результата.
TL>... тем более что чаще всего большее количество этих "автоматических критериев" выбирается менеджерами и обратно таки "лично-ориентированы", а не "системно-ориентированы".
Мы говорим про критерии которые я предложил или про критерии вообще? В том то и дело что нужно выбирать "системно-ориентированые" критерии -- общие характиристики кода.

TL>С точки зрения "личной мотивации" — таки да, предполагается что типа нехорошо коммитить решение, скопипастеное у Васи, потому как получается "меньший личностный вклад" — а вот с точки зрения системы как раз _правильно_ комитить именно _едиообразное_ решение, дабы не плодить в коде может и "один лучше другого", но, тем ни менее, "зоопарк".
Это был пример, и в качестве "Васи" мог бы выступать тот же самый программер, т.е. "скопипастил у себя". Источник совершенно не важен, важен сам факт дублирования кода, так как оно увеличивает сложность системы.

TL>Правильным решением было бы передать решение участка "на 87% васиного кода" самому Васе, ибо он над этим кодом как миниму думал и наверняка сможет даже более лучшее решение найти быстрее, а заодно и внедрить то же самое улучшенное решение и в свой более старый код — но это, конечно, идеал, и никакой "Вася" при "лично-рейтинговом" подходе к оценке его работы таки заниматься не захочет.
Правильным решением было бы выделить "васин код" в отдельный метод, класс, ... и вызывать из двух разных мест: моего и "васиного".

TL>1) Дублирование кода само по себе без рефакторинга не решается —
Вот, вот! Раз видишь, что "Васин код" может решить твою задачу -- рефакторь его, чтобы ты мог использовать его для решения своей!
TL>пусть лучше будет легко-отслеживаемое дублирования с возможностью дальнейшего нахождения аналогичных участков и вынесения их в обобщение, чем вагон велосипедов, в стремлении "ни в коем случае не скопипастить чужое".
Дублирование это всегда зло. Из каких бы "благих намерений" оно не исходило.
Еще раз: я не говорю про "нельзя использовать чужой код", я говорю: если хватило ума понять, что Васин код может решить твою проблему -- измени его так (выделив метод, класс, ...), чтобы он так же решал бы и твою. Т.о. обе задачи решены, дублирования нет, код стал только проще.
TL>А вообще при подходе "все разжевано архитекторами — над кодом трудится бригада (обезьянок-)кодеров" совершенно непонятно, откуда оное вообще берется — архитекторы чего-то недосмотрели ага?
Откуда вообще взялись архитекторы?

TL>2) Это, конечно, правильно — увы, далеко не всегда реализуемо на практике. Ну и потом грамотное покрытие с должной эффективностью способен сделать грамотный QA Eng. —
QA Eng. -- это потом, это у них будет 100% покрытие тестами и тыды, я говорю про юнит-тесты -- тесты которые пишут разработчики.
TL>у девелоперов, а тем более кодеров, чаще получается именно (1) — "просто дублирование пришедших в голову вариантов".
Пусть даже так, но "хреновые тесты" в любом случае лучше их отстутствия. Хотя бы тем, что люди их пишут (начали писать), а это шаг в правильном направлении.
TL>А так вообще тест-кейзы должны быть заданы еще архитекторами — в идеале...
LowLevel архитекторов в сад

Автор: Gaperton
Дата: 17.06.08

Дедикэйтед архитекторы нужны только для синхронизации действий отдельных команд, т.е. они должны разрабатывать только HighLevel архитектуру.

TL>3) Это в целом просто смешно. Без коментариев.
Ну тогда придеться мне прокомментировать.
Сложные длинные методы с большой вложенностью -- это всегда плохо: плохо понимаются, плохо сопровождается, плохо тестируется, плохо расширяются, плохо...
Длинные методы с большой вложенностью всегда выполняют больше одной обязанности.
Длинные методы с большой вложенностью необходимо снабжать комментариями объясняющими что делает этот кусок кода, а что это.
Длинные методы с большой вложенностью всегда можно разбить на несколько мелких с говорящими именами, упростив тем самым понимание кода.

Посмотрите на литературу по рефакторингу систем: они выделяют методы даже тогда, когда тело нового метода состоит из одной-двух строчек. А все для того, чтобы инкапсулировать решение и дать ему ясное имя.

TL>ЗЫ: интересно, а зачем тогда вообще "делать билд", "заливать код", "писать тесты", если потом святым трепетом бояться все это поломать?
А затем, что у человека элементарно голова должна быть на плечах. Он элементарно должен а) взять из репозитория последние изменения, б) скомпилировать код, в) прогнать все тесты.
Если он это не делает, то о каком качестве и дисциплине может идти речь?

Если же он поломал код или тесты, которые ему недоступны (код и тесты другой команды), то:
Какого он вообще полез в публичный интерфейс их куска, изменил методы, сигнатуры, классы без команды архитектора (high-level)?
Какого он не объявил старый интерфейс Deprecated и Obsolete, чтобы дать возможность другим командам отреагировать на изменения?
....

TL>Лично я с трудом представляю себе "команду", в которой отдельные ее представители и вся команда в целом плохо представляет себе реальный вклад каждого в отдельности в общее дело и для "показания оного" нужны все эти "рейтингомерялки". Если это дивизия никак не связанных друг с другом (обеъзьянок-)кодеров — тогда да. А чтобы _команде_ для понимания своих сложностей в чем-либо — написание юнит тестов, сложный код, копипасты, сроки, опоздания, засиживания, нежелание работать, неопрятный вид, etc. — нужна была "сторонняя ...мерялка"? Извините, но это что угодно, только не _команда_. Проверено лучшими собаководами.
Да, да, да. Только никто не говорит, что у нас уже есть команда! Команду еще нужно создать.

А даже если у нас уже есть Команда, что мешает провайдить не рейтинг, а общее состояние системы: общий процент дублирования, общее покрытие тестами, общая сложность системы, общее...?


СУВ, Aikin.

G>Угу. Понятно, в каком направлении развивалась бы ваша мысль, если вас сделать менеджером.
Не, тьфу-тьфу-тьфу. Я себя организовать не могу, не то что других
Все мои знания исчерпываются парой книжек Демарко, десятком статей, этим форумом и общими представлениями о работе менеджера со стороны программиста.

G>Софтверные метрики не игрушки, методики, которые на них основаны, например PSP/TSP, категорически запрещают любое их применение для любых оценок персонала. Личные метрики — приватная информация, их нельзя публиковать на таких сайтах.
У меня нет достаточного опыта чтобы критически оценить это утверждение, но так как о тебе у мнея только положительное мнение, то поверю тебе на слово. Спасибо за совет.

G>Публикации подлежат только агрегатные средние метрики команд.
Чисто на правах идеи: а что если вывешивать только агрегатные метрики, а характиристики отдельного комита отсылать только самому программисту, чтобы он мог посмотреть что он сделал не так (или так), что ему нужно улучшить в своей работе... Хранить эту статистику в приватном месте, для последующего анализа менеджером, чтобы на основе их принимать решения об обучении команды, решения о выведении человека из команды, ...

G>Баловство это чистой воды. Эта балльная оценка не имеет никакого отношения к качеству кода и реальному вкладу программистов. И зачем она тогда нужна?
Прошу пояснить.

G>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
Как?

G>Что решается вовсе не вашей "позорной доской" или "доской отличников боевой подготовки".
Позорную доску в топку, я это уже понял, спасибо.

FR>У нас похоже эта философия плохо приживается http://www.autonews.ru/autobusiness/news.shtml?2008/06/23/1372071
Как я понял из статьи, в Питере слишком много заводов, рабочим есть куда идти -- вот они и идут. Причем на той же Тойоте "настоящее время... текучка кадров ... составляет менее 2%". Так что, ИМХО, все еще устаканиться.

Больше всего мне не понравилось мнение российских экспертов: "дайте им больше денег и будет все хорошо". Других предложений нет.
Я конечно понимаю, что сравнивать программеров с рабочими на конвейере не стоит -- программеры (хорошие) любят свою работу, но все же: неужели у нас (СНГ) единственный стимул -- деньги?

ГВ>Правильный ответ: никак. Хренисометрия — удел детского сада.
Ок, а если позволить мерять "хрен" самому владельцу "хрена"? Т.е. "за последний месяц он у тебя вырос на 1 см, а за предыдущий укоротился на 0,2, ..."

К каким косякам это может привести?

V_S>Короче, делегируй часть своих полномочий (но не ответственности!).
А "выделенное" еще почему?
Естественно, что перед вышестоящим начальством отвечать придеться ему лично. Но что мешает доверять членам своей команды и полагаться на их слово? Все перепроверить все равно не получиться.
Например, если я говорю своему тимлиду, что я сделал/сделаю к/нужно дополнительное время/.. для задачи он мне верит, а не перепроверяет мои слова.

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

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

Есть подозрение, что много времени будет уходить на разбирательство, почему вдруг вот этот вполне приличный код вдруг снижает какую-то метрику. Формальное покрытие кода не всегда кореллирует с полезностью данного теста. Уменьшать вложенность ифов и циклов можно довольно зверскими приемами типа:

  switch ((someVar * someVar2 / 3) % 5)
  {
        case 1, 4:
        ...
        break;
        case 2, 3:
        ...
        break;
  }

Очень неприятно когда к программировнию люди начинают относиться слишком формально. Качество кода показатель далеко не формальный, за него отвечает тимлид и ему очень трудно будет кому-то объяснить, что именно здесь надо сделать "хуже" по меркам робота.

A>Дублирование это всегда зло. Из каких бы "благих намерений" оно не исходило.
A>Еще раз: я не говорю про "нельзя использовать чужой код", я говорю: если хватило ума понять, что Васин код может решить твою проблему -- измени его так (выделив метод, класс, ...), чтобы он так же решал бы и твою. Т.о. обе задачи решены, дублирования нет, код стал только проще.
Из любого правила есть исключения, иногда копипейст алгоритма правильнее его повторного использования просто потому, что похожесть Васиного и твоего алгоритма всеголишь сиюминутное требование которое может изменится в любой момент. Сильно мотивированный данной метрикой программист может наворотить плохоподдерживаемого кода.

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

Вобщем я за то, чтобы для оценки качества кода программист использовал мозг, вместо робота.

Здравствуйте, Aikin,

разве я где-нибудь писал о недоверии и многократных перепроверках? Своим людям (каждому! члену своей команды) нужно доверять! Что, конечно же, не снимает с лида/пиэма ответственности принимаемые решения и за успех проекта в целом, — не только перед начальством, заказчиками и т.п., но и перед своей командой — в первую очередь. Ибо успешно завершенный проект "цементирует" команду гораздо лучше как бы team-building'овых совместных посиделок с пивом. (Впрочем, одно не исключает другое )

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

G>>Я знаю, какие они обычно бывают, потому что мы измеряли фактические цифры работая по PSP/TSP.
A>Так поделись. Или это цифры что даны выше?

Примерно такие. Эти цифры зависят сильно от разработчика, и у нас колебались в среднем от 20 до 40%. Кто-то любит быстро колбасить и рефакторить, у него будет небольшой процент. Кто-то любит думать, а потом делать. Причем, что интересно, значимого влияния на общее время решения задачи этот показатель в большинстве случаев не оказывает. По крайней мере, если о "средних" по сложности и относительно небольших по длительности изолированных задачах говорить, которые одному человеку поручаются, и на которые нарезан план. В крупном масштабе и при групповой разработке, понятное дело, этот фактор будет играть гораздо сильнее.

А вообще — ты легко можешь замерить свои цифры сам программой для замера времени.

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

G>>Публикации подлежат только агрегатные средние метрики команд.
A>Чисто на правах идеи: а что если вывешивать только агрегатные метрики, а характиристики отдельного комита отсылать только самому программисту, чтобы он мог посмотреть что он сделал не так (или так), что ему нужно улучшить в своей работе... Хранить эту статистику в приватном месте, для последующего анализа менеджером, чтобы на основе их принимать решения об обучении команды, решения о выведении человека из команды, ...

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

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

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

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

G>>Баловство это чистой воды. Эта балльная оценка не имеет никакого отношения к качеству кода и реальному вкладу программистов. И зачем она тогда нужна?
A>Прошу пояснить.

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

1) Дубилрование кода
Интересно, как именно ты предлагаешь эту метрику считать. Но в любом случае — лучше не допускать этого на code review (вместе с проверкой соответствия стилевому руководству и стандарту кодирования) или design review. Когда у тебя код оказался задублирован в репозитории, и он успешно проходит тесты, строго говоря претензии к качеству предъявлять поздно. Код работает, ошибок нет — качество в порядке.

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

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

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

3) Сложность методов (вложенные ифы, форы, ...)

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

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

4) В принципе, сюда можно добавить и количество строк кода. С одной стороны много не напишешь -- нужно покрытие тестами, много не скопипастишь,... , а с другой этому критерию можно дать низкий вес.

И что, чем больше пишем, тем лучше? Я могу одно и тоже в разницей в два раза написать легко, причем одинаковый тест даст то же самое покрытие.

G>>Надо не рейтинги подводить, а реально обеспечить необходимое качество кода и дизайна, в этом задача менеджмента.
A>Как?

Cтавить конкретные цели в области качества (это правда очень сложно), и достигать их посредством code & design review. Серьезно заниматься политикой тестирования.

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

ГВ>>Правильный ответ: никак. Хренисометрия — удел детского сада.
A>Ок, а если позволить мерять "хрен" самому владельцу "хрена"? Т.е. "за последний месяц он у тебя вырос на 1 см, а за предыдущий укоротился на 0,2, ..."

Объясняю метафорически: засунь свою линейку туда, откуда вынул. У меня своя линейка.

Понятно?

A>К каким косякам это может привести?

Ещё раз повторяю: засунь свою линейку...

Значит я не так тебя понял.
V_S>делегируй часть своих полномочий (но не ответственности!).
Что означает: "но не ответственности!"
ИМХО, ответственность делегировать все равно не получиться -- начальство будет против. Ответственность можно делегировать, но она в любом случае будет ответственностью перед тобой.

Короч неважно.

Приятно было с вами пообщаться

Начну отвечать с конца.

Z>Вобщем я за то, чтобы для оценки качества кода программист использовал мозг, вместо робота.
Так одно другому не мешает. Даже больше -- голова это самый главный инструмент человека (тем более в IT). Но голова не всегда может справиться одна. Обычно на все времени не хватает. А тем более на рутину типа покрытия кода тестами, соответствие стилю кодирования, ...
Код ревью никакой робот не заменит и можно привести сотни примеров когда формальный код (робот даст максимум) будет говнокодом, но, ИМХО, большая часть говнокода будет признана говнокодом после автоматической оценки. Потому как говнокод проходящий формальные тесты написать, ИМХО, ничуть не легче, чем хороший код с той же характеристикой.

Z>Есть подозрение, что много времени будет уходить на разбирательство, почему вдруг вот этот вполне приличный код вдруг снижает какую-то метрику.
Могу представть это только на время обкатки критериев, а точнее границы хорошо/плохо.
То же покрытие у девелоперов не должно быть 100% (будет только хуже) оно должно быть где-то 60% (эту цифру нужно уточнить).
Копипаст же, чтобы однозначно было признаным копипастом должнен содержать больше 80% совпадений (опять же цифра не точна). Я даю 100%, что если дать один и тот же таск (нетривиальный) разным девелоперам, то фиг мы получим болше 80% совпадений.
Сложность методов довольно скользкий момент, но благо легко решаемый выделением нового метода. Поэтому к этому тоже стоит приучивать.
Проверка на соответствие стилю кодирования однозначно должна быть отдана роботу, так как отлично формализуется. Про компилируемость и тесты тоже нет вариантов.

Z> Формальное покрытие кода не всегда кореллирует с полезностью данного теста.
Человек написал формальные тесты. Добился 60%-го покрытия. Т.е. он потратил время. Потратил еще раз, еще, ...
Потом ему репортят баг -- он чешет репу: а почему вот этот тест не отловил его Раз я на него тратил время, может нужно было потратить еще 5% времени и написать тест лучше?..
...
В любом случае это путь в правильном направлении.

Z>Уменьшать вложенность ифов и циклов можно довольно зверскими приемами типа:
Ну этот код не пройдет другие проверки, например по стилю кодирования ("волшебные числа" и именование переменных). Привели в соответствие со стилем кодирования. Все тесты прошли. Ну и что? Робот ведь не последняя инстанция. Будет еще код ревью (который этот кусок может просто не заметить)...

Z>Очень неприятно когда к программировнию люди начинают относиться слишком формально. Качество кода показатель далеко не формальный, за него отвечает тимлид и ему очень трудно будет кому-то объяснить, что именно здесь надо сделать "хуже" по меркам робота.
Отвечает? Пусть отвечает. Я не говорю про замену тимлида роботом (а прикольная идея , я знаю такие экземпляры которые можно безболезненно заменить ), я говорю про то что робот может помочь тимлиду.

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

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

СУВ, Aikin

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

A>Отвечает? Пусть отвечает. Я не говорю про замену тимлида роботом (а прикольная идея , я знаю такие экземпляры которые можно безболезненно заменить ), я говорю про то что робот может помочь тимлиду.

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

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

Нарушения стандартов кодирования, которые легко проверить автоматически довольно редки и также легко исправляются автоматически (Resharper -> Reformat all) не являются особой проблемой, которая мешает проекту. Нарушение других стандартов (например правил именования сущностей в программе, правила использования исключений) проверяются далеко не так тривиально.

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

Ресурсы на разработку, внедрение и поддержку данного робота, тоже не стоит сбрасывать со счетов. Врядли они окажутся копеечными.