Prioritizing Technical Debt as If Time & Money Matters • Adam Tornhill • GOTO 2022
Крутой доклад от Адама Торнхилла, который продолжает тему complexity в разработке ПО, которая была главной в книге A Philosophy of Software Design, которую я вспоминал вчера. Сначала автор приводит Lehman's "Laws" of Software Evolution, которые показывают почему вопрос управления сложностью важен
- Continuing change - система должна постоянно адаптироваться или она будет прогрессирующе становиться менее приемлемой
- Increasing complexity - по мере эволюции системы complexity возрастает, пока не будут выполнена работа по поддержке или уменьшению complexity Это накопление complexity приводит к появлению технического долга, который замедляет time to market, снижает предсказуемость работы над системами, приводит к организационным проблемам, а также снижает возможности к инновациям. Дальше автор предлагает способы его померить при помощи Behavioral Code Analysis, который состоит из трех компонент: code, people, context. Все это можно подтянуть из VCS. Автор предлагает мерить 2 параметра
- Code complexity - метрика сложности кода, про нее чуть дальше отдельно
- Code change frequency - метрика частоты изменения кода (тут просто количество изменений кода за период времени) В сумме эти два параметра позволяют понять какие части кода являются сложными и которые приходится часто править.
Code Complexity автор предлагает мерить опять не одной метрикой, а используя набор метрик для оценки здоровья кода:
- На уровне модулей - low cohesion (слишком много ответственности на классе), brain class (low cohesion, + как минимум один Brain метод, который большой, сложный и централизует поведение модуля)
- На уровне функций - brain methods, copy-pasted logic
- На уровне имплементацииl - deeply nested logic, primitive obsession
Дальше автор показывает пример анализа кодовой базы Android для того, чтобы продемонстировать свою концепцию. Распределение частотности работы с разными файлами выглядит как распределение с длинным хвостом, поэтому часто изменяющихся файлов не так много и только часть из них сложные. Собственно нам надо начинать работу с нашим техдолгом именно с этих файлов, а остальные можно игнорировать - это прагматичный, экономически-обоснованный подход. Интересно, что автор утверждает, что это стандартная картина для всех проектов, что он видел. А дальше он находит проблемный файл ActivityManagerService.java и делает drill down, чтобы показать как найти место внутри этого файла, где сконцентрированы основные проблемы - собствеенно это он и называет X-Ray.
Дальше идет рассказ про legacy code, который он определяет следующим образом:
- Lacks in quality - стандартное определение
- We didn't write ourselves - не совсем стандартная часть:) которая мешает начать рефакторить свой код вовремя Дальше автор рассказывает забавную историю про анализ трех разных проектов, где два были свои родные, а один приемный. Они были сравнимы по качеству, но переписать хотели только чужой проект, так как на него пало подозрение в том, что он legacy:)
Ну и напоследок автор рассказывает про то, что можно еще анализировать вклад разных людей в кодовую базу и оценивать количество знаний, сконцентрированных у каждого, а также что-то вроде bus factor для каждого мейнтейнера на случай того, чтобы минимизировать риск потери важной информации при уходе ключевых людей.
P.S. У автора есть сайт https://codescene.com/ и книга "Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis", в которой этот подход подробно разобран.
#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management