4.3 Объём изменений кода и анализ горячих точек

Обзор и мотивация

Объём изменений кода измеряет, как часто файл или модуль меняется со временем: строки добавленные, изменённые и удалённые в последовательных коммитах. Сам по себе объём изменений довольно слабый сигнал: некоторые файлы меняются часто, потому что находятся в активной, здоровой разработке, а некоторые редко меняются, потому что они стабильны и корректны, а не потому что заброшены. Подлинная диагностическая сила подхода этой темы приходит от сочетания объёма изменений со сложностью (тема 4.1): файл, одновременно часто изменяемый и высокосложный, горячая точка, непропорционально вероятно является источником дефектов и тормозом для скорости команды, и эмпирические исследования последовательно подтверждают это по многим кодовым базам и организациям.

Анализ горячих точек, популяризированный работой Адама Торнхилла по software analytics, особенно ценен, потому что не требует никакого ручного опроса или субъективного суждения для нахождения своих целей. История системы контроля версий уже содержит всё необходимое для вычисления и объёма изменений, и, в сочетании с инструментарием статического анализа, сложности, для каждого файла в кодовой базе автоматически. Это позволяет команде или организации определить, с реальным доказательством, а не анекдотом или самой громкой жалобой на ретроспективе, именно какая небольшая доля кодовой базы заслуживает внимания рефакторинга в первую очередь.

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

Ключевые принципы

Объём изменений сам по себе слабый сигнал; объём изменений в сочетании со сложностью сильный. Именно сочетание, а не любая метрика по отдельности, определяет подлинную горячую точку.
Анализ горячих точек не требует ручного опроса. История системы контроля версий уже содержит всё необходимое для его автоматического вычисления.
Горячая точка это сигнал приоритизации, а не автоматический приговор. Человеческое суждение всё ещё необходимо, чтобы решить, какого действия заслуживает конкретная горячая точка.
Частое изменение не является изначально плохим. Некоторый объём изменений отражает здоровую, активную разработку, а не проблему качества.
Этот анализ масштабируется именно там, где интуиция подводит: в крупных кодовых базах, слишком больших, чтобы кто-либо один мог обозреть и приоритизировать их по ощущению.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Приоритизация на основе интуиции	Быстро, не требует инструментария, использует контекстное знание команды	Искажена недавностью, личным предпочтением и тем, кто жалуется громче всех
Только объём изменений	Просто вычислить	Слабый сигнал сам по себе; частое изменение не является изначально плохим
Объём изменений в сочетании со сложностью (анализ горячих точек)	Сильный, основанный на доказательствах, автоматический из существующих данных	Требует сочетания двух источников данных и интерпретации результатов с суждением
Анализ горячих точек, сверенный с данными об инцидентах	Подтверждённый, сильнейшее доказательство для приоритизации	Требует надёжной связи инцидентов с кодом, которой есть не у каждой организации

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

Вопросы для обсуждения в команде

Каковы наши пять главных горячих точек, ранжированных по сочетанию объёма изменений и сложности, и совпало бы это ранжирование с интуицией нашей команды о том, где живут наши худшие проблемы? Запустите анализ и сравните результат с тем, что ваша команда предположила бы до того, как увидеть данные; расхождения часто самая ценная находка.
Коррелируют ли наши определённые горячие точки с фактическими производственными инцидентами или данными об утёкших дефектах? Если у вас есть данные для прямой проверки этого, сделайте это; если нет, этот пробел сам по себе стоит назвать как то, к чему нужно стремиться.
Для нашей главной горячей точки прямо сейчас, лежащая в основе проблема это существенная сложность, законно требующая частого изменения, или случайная сложность, которую рефакторинг мог бы подлинно исправить? Пройдитесь по файлу вместе и сделайте это суждение явно, а не предполагая любой из ответов.
Сохранялась ли ранее определённая горячая точка через несколько циклов анализа несмотря на обозначение? Если да, честно исследуйте почему: устранение фактически никогда не предпринималось, или предыдущая попытка не адресовала реальную лежащую в основе причину.
Приоритизируем ли мы сейчас работу по рефакторингу на основе доказательств или на основе того, кто жаловался недавнее или громче всех? Будьте честны о фактическом текущем процессе приоритизации вашей команды и как он сравнивается с тем, что предложил бы основанный на доказательствах анализ горячих точек.
Во что обойдётся нам, в частоте дефектов или замедлении поставки, оставить нашу текущую главную горячую точку без внимания ещё на год? Этот вопрос вынуждает к конкретной оценке стоимости, которая может закрепить решение о приоритизации, а не оставлять горячую точку абстрактной, легко деприоритизируемой заботой.

Отраслевой взгляд

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

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

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

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

Примеры

Корпорация. Платформа обработки страховых претензий страховой компании, охватывающая более двух миллионов строк кода по десяткам сервисов, накопила годы неформальных жалоб на то, что «модуль валидации претензий» проблемный, но никакая формальная приоритизация никогда не следовала из этих жалоб. Анализ горячих точек, сочетающий шесть месяцев данных объёма изменений с оценками сложности, определил совершенно другой файл, общую утилиту конвертации валют, погребённую глубоко в редко обсуждаемой зависимости, как фактическую главную горячую точку, которая никогда не всплывала ни в одной жалобе на ретроспективе. Сверка с данными об инцидентах подтвердила, что эта утилита была замешана в непропорциональной доле дефектов финансовых расчётов за предыдущий год, и целевой рефакторинг именно этой утилиты, а не модуля, который все неформально обвиняли, произвёл измеримое сокращение связанных инцидентов в следующем квартале.

Государство. Десятилетиями старая система лицензирования государственного агентства транспортных средств прошла анализ горячих точек как часть бизнес-кейса модернизации. Анализ определил небольшой кластер файлов, представляющий менее 3% всей кодовой базы, ответственный за непропорциональную долю и объёма изменений, и сложности, а сверка с журналом инцидентов агентства показала, что этот же кластер составлял почти 40% всех зарегистрированных системных дефектов за предыдущие три года. Эта конкретная, основанная на доказательствах находка, гораздо более убедительная, чем общее заявление, что «система старая и нуждается в модернизации», стала центральным элементом успешного запроса бюджета на целевые, постепенные усилия модернизации, сфокусированные именно на этом кластере, а не гораздо более дорогую полную замену системы.

Бизнес-кейс: мотивация, ROI и TCO

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

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

Антипаттерны и ловушки

Использование только объёма изменений без сложности: слабый сигнал сам по себе, который может пометить здоровый, активно разрабатываемый код как ложное срабатывание.
Отношение к ранжированию горячих точек как к автоматическому списку действий без человеческого суждения: упускает различие существенной и случайной сложности, определяющее правильный ответ.
Приоритизация рефакторинга на основе самой громкой жалобы, а не доказательств: часто неправильно направляет усилия прочь от того, где данные фактически показывают, что живёт проблема.
Никогда не сверять горячие точки с данными об инцидентах или дефектах: упускает шаг подтверждения, укрепляющий кейс для действия на основе анализа.
Запуск анализа один раз и никогда не повторение: упускает, работает ли усилие по устранению фактически со временем.
Игнорирование постоянно обозначаемой горячей точки без исследования, почему устранение не закрепилось: тратит впустую диагностическую ценность повторного анализа.

Модель зрелости

Уровень 1, Инициация: Приоритеты рефакторинга устанавливаются интуицией или объёмом жалоб, без данных объёма изменений или сложности, информирующих решение.
Уровень 2, Развитие: Некоторые команды неформально проверяют данные объёма изменений или сложности, но нет последовательной, общеорганизационной практики анализа горячих точек.
Уровень 3, Стандартизация: Анализ горячих точек, сочетающий объём изменений и сложность, запускается регулярно и последовательно информирует приоритизацию рефакторинга по всей организации.
Уровень 4, Управление: Горячие точки сверяются с данными об инцидентах и дефектах для подтверждения анализа, а тренд через последовательные циклы активно отслеживается.
Уровень 5, Оркестрация: Организация может указать на конкретные, измеримые улучшения частоты дефектов или поставки от информированной горячими точками инвестиции в рефакторинг, а анализ является рутинным, доверенным входом в решения об инженерных инвестициях.

Идеи для обсуждения

Как бы выглядел наш список главных горячих точек, если бы мы запустили этот анализ сегодня?
Совпал бы этот список с текущим неформальным ощущением нашей команды о наших худших проблемных областях, или противоречил бы ему?
Есть ли у нас данные для сверки горячих точек с фактическими инцидентами?
Сохранялась ли известная проблемная область несмотря на предыдущие попытки её исправить, и почему?
Во что обойдётся нам оставить нашу текущую главную горячую точку без внимания ещё на год?

Основные выводы

Объём изменений в сочетании со сложностью определяет подлинные горячие точки гораздо надёжнее, чем любая метрика по отдельности.
Анализ горячих точек не требует никакого ручного опроса; он вычислим автоматически из существующих данных системы контроля версий и статического анализа.
Относитесь к ранжированию горячих точек как к доказательству для приоритизации, а не автоматическому приговору; человеческое суждение всё ещё требуется.
Сверяйте горячие точки с данными об инцидентах и дефектах, чтобы подтвердить анализ и укрепить кейс для действия на его основе.
Отслеживайте горячие точки через последовательные циклы анализа, чтобы подтвердить, что устранение фактически работает, а не только как единый снимок.

Источники и дальнейшее чтение

Your Code as a Crime Scene, Адам Торнхилл (основополагающий текст по анализу горячих точек, сочетающему объём изменений и сложность из данных системы контроля версий).
Software Design X-Rays, Адам Торнхилл (дальнейшие техники поведенческого анализа кода с использованием истории системы контроля версий).
Nagappan, Nachiappan, and Thomas Ball, “Use of Relative Code Churn Measures to Predict System Defect Density,” ICSE (2005): эмпирическое исследование связи между объёмом изменений и плотностью дефектов.
Refactoring: Improving the Design of Existing Code, Мартин Фаулер (техники адресации случайной сложности после её определения).

4.3 Объём изменений кода и анализ горячих точек

Обзор и мотивация

Ключевые принципы

Рекомендации

Вычисляйте объём изменений и сложность вместе и ранжируйте по их сочетанию

Исследуйте главные горячие точки с человеческим суждением перед действием

Сверяйте горячие точки с данными об инцидентах и дефектах

Отслеживайте тренд горячих точек через последовательные анализы, а не только единый снимок

Используйте данные горячих точек для информирования, а не замены разговоров о приоритизации на уровне команды