How Technical Problems Cause Organizational Friction • Adam Tornhill • GOTO 2023 (Рубрика Architecture)
Интересный доклад от Adam Tornhill на тему социотехнических запахов (презентация доступна здесь). Суть в том, что наши современные системы очень сложны и они включают как software, так и людей, которые его пишут (пока не это не стали делать LLMs самостоятельно). Обеспечить баланс достаточно сложно, так как из кода напрямую не ясен социотехнический контекст - кто и зачем его написал, а также какие в нем были изменения. Adam Tornhill предлагает использовать подход behavioral code analysis, где мы сочетаем в себе анализ кода с данными о том, как команды взаимодействуют внутри кода, например, кто вносит изменения и насколько параллельно это происходит, как выглядят параметры cohesion и coupling, а также насколько сложно поддерживать код с высоким техническим долгом. Интересно, что за год до этого Adam рассказывал крутой доклад на тему приоритизации техдолга и я об этом рассказывал. Если же возвращаться к behavioral code analysis, то автоор предлагает, использую их, уменьшить организационное трение и сосредочить внимание на ряде общих задач
- Выявите узкие места архитектурной координации и поймите технические root causes
- Визуализируйте неявные зависимости между командами, а дальше действуйте так, чтобы отделить (decouple) команды
- Выявите риски знаний, измерив bus factor. Узнайте, как смягчить его
- Сообщите о рисках масштабирования, присущих закону Брукса, показав данные о том, как он влияет на вашу доставку
- Выйдите за рамки технического воздействия, зная, как плохой код приводит к низкому моральному духу и увеличению истощения
Ну и социотехнические факторы, которые называет автор звучат примерно так 1. The overcrowded system - когда слишком много людей работают над одной системой и дают слишком маленький выхлоп:) 2. Coordination bottlenecks in the code - проблема с большим количеством изменений в одних и тех же файлах вашей системы людьми из разных команд. Здесь очень велика сложность поддержания ментальной модели кода, поэтому это приводит к большему количеству багов и более сложным внесениям изменений. Кажется, что в этой части еще пригодились бы подходы из whitepaper "Architecture Anti-patterns: Automatically Detectable Violations of Design Principles", про которую я рассказывал раньше 3. A propagating cost of change - про change coupling и как изменения в одном месте тянут за собой большое количество изменений в других местах, если change coupling высокий. Как раз недавно я рассказывал про книгу Кента Бека "Чистый дизайн" ("Tidy First?"), где неплохо разбирались вопросы change couplin 4. Dependent work crossing team boundaries - здесь автор говорит примерно про обратный маневр Конвея, где нам нужно так выбрать структуру команд, чтобы она матчилась с желаемой архитектурой. Плюс нам надо так организовать архитектуру системы, чтобы она хорошо укладывалась на problem domain и позволяла организовать естественные границы для команд 5. Unhealthy code with a low Truck Factor - тут автор вспоминает про bus factor и выбывающих людей, а дальше показывает, что если это наложить на нездоровый код, то мы получаем большую проблему. Условно, если мы теряем эксперта по запутанному коду, то наши знания о деталях реализации систем сильно уменьшаются и осуществлять изменения становится дольше и дороже.
P.S. У автора есть сайт https://codescene.com/ и книга "Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis", в которой этот подход подробно разобран. Лицензция стоит $300 в год на разработчика.
P.P.S. Whitepapers, на которые ссылался автор
- The business impact of Code Quality
- On-boarding costs in unhealthy code
- Happiness and the Productivity of Software Engineers
- The Influence of Organizational Structure On Software Quality
#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management