Сhurn кода и как его измерить

Что такое churn кода и как его измерить

Компании постоянно ищут способы отслеживать, измерять и оценивать рабочие процессы разработчиков. Это помогает повысить производительность и качество кода, сократить время вывода продукта на рынок и увеличить прибыль. Но измерить эффективность не всегда просто. Иногда в этом помогает анализ оттока кода.

Что такое code churn?

Churn — это показатель того, сколько кода разработчик пишет напрасно (с английского churn — взбалтывать, перемешивать; словом, возвращаться к коду и что-то менять в нем — прим.ред). Благодаря ему можно узнать, сколько раз разработчик удалял те или иные фрагменты кода (например, функцию, файл или класс) в течение первых 2-3 недель после написания. Эти показатели отличаются среди членов команды, в зависимости от опыта и сложности проекта. Нет точного показателя, какой churn кода следует считать нормальным. Удаление и редактирование — это обычный процесс, поскольку код регулярно тестируется и оптимизируется, особенно при решении проблем или после добавления нового кода. Однако чрезмерно высокий показатель churn кода или внезапные изменения этой метрики могут быть симптомом проблем, влияющих на команду разработчиков.

О чем говорит churn кода?

Чрезмерный или нерегулярный churn кода может указывать на то, что разработчик испытывает трудности и ему нужна дополнительная поддержка — наставничество или парное программирование. Это также может означать, что человек перфекционист или склонен изобретать колесо в решении проблем, тратит драгоценное время впустую и мало чего добивается своими усилиями. Если оставить все как есть, это может привести к неудовлетворенности работой и выгоранию. Постоянные правки могут говорить о том, что тимлиду нужно четче сформулировать, что означают статусы «сделано» и «закончено» для задач. Churn кода также дает представление о текущих рабочих нагрузках и распределении ресурсов. Тоби Осборн полагает, что изменение кода может дать полезную информацию. Например: «За последние две недели home.html изменялся 50 раз, а website_controller.rb — 20 раз». Эта статистика показывает:

• где может понадобиться больше тестов (потому там код часто менялся);
• какая часть проекта наиболее сложная для разработчика.

Эти факторы важны: они помогают определить, нужно ли проекту перераспределение ресурсов, более тщательное тестирование или сдвиг дедлайна по проекту. Исследования показывают тесную связь между большим высоким показателем churn кода и количеством дефектов, обнаруженных во время тестирования. Время также важно. Код должен стать более стабильным по мере приближения дедлайна, и если каждый раз происходит обратное, это говорит о том, что после релиза в нем могут обнаружиться дефекты. Высокий churn кода также может указывать на внутренние проблемы команды с коммуникацией, когда большой объем кода “на выходе” считается хорошим результатом.

Как churn кода связан с рефакторингом и техническим долгом?

Рефакторинг исходного кода необходим для поддержания качества, безопасности и производительности кода в долгосрочной перспективе. Он превращает беспорядочный, неправильный и (или) повторяющийся код в чистый. Он решает проблемы стандартизации, которые могут возникнуть, когда несколько разработчиков вносят в проект свой собственный код. Рефакторинг улучшает читабельность и поддержку исходного кода. Без регулярного рефакторинга у разработчиков появляется гигантский технический долг. Долг растет, поскольку на рефакторинг уже не хватает времени, и это затрудняет разработку, особенно если на построена на устаревшем коде. Очень часто проблема состоит в том, с чего начать, когда речь идет о сокращении технического долга за счет рефакторинга.Обратите внимание на изображение. В нем измерение сложности churn на графике XY — это способ расставить приоритеты в важном и срочном рефакторинге кода. Он демонстрирует, что файлы, вызывающие наибольшее количество проблем, — это сложные и часто используемые файлы. Применение такой метрики поможет определить «горячие точки» кода, на которые необходимо обратить внимание в первую очередь при любых действиях по рефакторингу. Стоит подчеркнуть, что отток кода не всегда проблематичен. Это нормально на этапах прототипирования и проектирования, когда разработчик тратит время на исследования и тестирование.

Как измерить churn кода

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

git log --format=oneline [path_to_file]

Также есть churn-php. Pluralsight Flow объединяет исторические данные git в отчеты, выделяя сведения о производительности команды и эффективности процессов. CodeScene использует прогнозную аналитику для поиска скрытых рисков и социальных шаблонов в вашем коде. Он измеряет количество добавленных строк кода и количество удаленных строк. Stepsize рассчитывает отток кода для кода, связанного с техническим долгом. Для разработчиков SaaS, Azure DevOps Server поставляется со встроенным механизмом для измерения churn кода. Он позволяет создавать отчеты, которые раскрывают:

• количество файлов с определенным расширением имени файла, измененное в конкретной сборке;
• количество строк кода в исходной базе для конкретной сборки;
• какие изменения отправлены и каковы подробности каждого изменения? (Например, кто внес изменение, какие файлы были изменены и в какую дату было внесено изменение?)

Заключение

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