Пообщались с другом о производительности в разработке. Сколько бы я не пытался рассуждать на эту тему, всегда рассуждения уходят в сторону производительности производственной системы, а все метрики – это метрики ее эффективности, того, как построена система, в которой мы проектируем и разрабатываем. Примеры приведенных метрик никогда не должны использоваться против людей. Круто же, когда мы просто не пропускаем код, усложняющий продукт? Это автоматом учит людей писать более понятный код. Code Review с этим не поможет, при Code Review ты уже мысленно закончил задачу, если реквест кто-то не принял - ты исправляешь код, но исправление не учит как писат более простой код, – это разные режимы решения, разное давление контекста, разные подходы к работе. Q: Придумали ли уже что-то в мире для сравнения производительности разработчиков? A: Уже приняли, что сравнить производительность отдельных разработчиков нерально, бизнес-проблемы решать – это не стулья собирать. Это та ситуация, когда если нужно сравнить, то не нужно сравнить. Хай перформера в сравнении с лоу перформером будет видно невооруженным взглядом и хай перформер отличается чаще наработками, накопленными со временем. Из того, что имеет смысл – сравние знаний в очень конкретных технологиях. Это имеет смысл, так как знания конкретных технологий – конечны. Чтобы оценить производительность разработчика нужно оценить навык применения этих технологий по отдельности и в комбинации, умение добывать информацию и работать в команде. Ну и опять же, как сравнить производительность в командах, где разработчики работают в парах? И последнее – попытка сравнить производительность разработчиков по-отдельности приведет к их изоляции и разрушению командной работы (провокации конкуренции), даже если командная работа изначально была. То есть объективно оценить производительность разработчика в отрыве от окружающего контекста имхо не получится. Сложную задачу нужно делить на части 🙂 Разработка состоит из трех частей: 1. Знание требуемых технологий 2. Знание предметной области продукта 3. Социальные навыки (умение быть частью команды) Знание технологий можно оценить даже тестами; Знание предметной области можно оценить в диалоге и тестовыми заданиями, в которых нужно предложить решение бизнес-задачи (решение кейсов); Социальные навыки можно оценить по взаимодействию в команде, с коллегами, по решению сложных вопросов, по инициативности, амбициозности, смотря что важно. В дальнейшем диалоге немного развивалсь мысль и получились такие варианты: Сложность кода (цикломатическая сложность например). То есть буквально, коммита кода общая сложность выросла, упала или осталась на прежнем уровне. Инструменты для подсчета есть (sonarqube тот же). Среднее время на разработку при решении задачии, в которой программист принимает участие. Показывает и навык декомпозиции, то есть навык управления сложностью (чем крупнее задача тем выше уровень неопределенности и выше риски; разумная тактика – снижать риски, а за счет декомпозиции мы получаем снижение рисков почти бесплатно), и дисциплину. Тут и софтскилы видно, – будет человек брать задачу которую не понимает (чем выше оценка, тем ниже уровень понимания того, что нужно сделать) или не будет. Тестовое покрытие, – после коммита тестовое покрытие упало, осталось как было или выросло (sonar тоже умеет считать). И вообще-то, если сложность выросла или покрытие упало, надо бы такие коммиты отвергать автоматом. Это применение паттерна Build Threshold (сборка падает при нарушении правил проекта - протечки в архитектуре, медленные тесты, нарушение соглашений об оформлении кода). Еще можно посмотреть через паттерны Short-Lived Branches (бранчи должны быть короткоживущими, в идеале — не более нескольких дней и никогда дольше итерации) и Commit Often (каждый член команды регулярно чекинится в транк - как минимум один раз в день, после готовности каждой задачи) и договориться внутри команды, – если вчера не коммитил, поясни почему. Это провоцирует задать вопрос если затупил, а если человек изворачивается члены команды это тоже быстро заметят.