Каждый раз, когда стартую свой новый проект, я думаю:
Так, а вот тут мне нужно сделать по грамоте и сразу продумать дизайн и архитектуру.
Или же делать как делается и будь как будет.
Казалось бы, всё индивидуально, и как говорит любой архитектор: "Зависит от контекста."😅
Но мы можем дать вполне рациональный ответ, если зададим 2 вопроса:
1️⃣ Сколько в проекте строк кода (LOC - Lines Of Code)?
Измерять LOC, придумали еще на заре разработки. Примерно в 70х.
Тогда просто брали сумму всех строк во всех файлах проекта.
Казалось бы что из этого можно сделать?
— А прикиньте есть модель COCOMO1, по которой можно предсказать стоимость проекта, время его разработки и кол-во человек в команду, указав только кол-во строк кода 🤯
Можете поиграться тут. Но я обязательно в будущем про это напишу!
Мы же хотим понять, от какого количества строк нам нужно начать думать про дизайн и архитектуру.
Тут консенсуса нет. Никто не замерял разницу в эффективности хаотичной и структурированной системы.
Например Wang в Software Engineering Foundations, которого я так часто цитирую предлагает все проекты в которых >5000 LOC считать достаточно сложными (я уже упоминал об этом)
Мне лично этого не достаточно, потому я нашел статью System Design and the Cost of Architectural Complexity, в которой замеряли продуктивность 178 разработчиков на протяжении 8 релизов в проекте размером в 5.5M LOC (почти ядро Linux).) 😱
10x разработчики вообще реальны? (нет) 🤣 Мем из статьи
Из графика на странице 128 (см. картинку к посту) мы можем увидеть, как продуктивность разработчика, на 100% занятого разработкой нового функционала (синяя линия), падает в зависимости от сложности* почти в 2 раза:
6k LOC при 100% сложности и ~11k LOC при 0% сложности**.
* в статье используется Architectural Complexity посчитанная через Design Structure Matrix
**но это только симуляция из регрессионной модели составленной на основе исследования
Или проще говоря, на основе исследования написали симуляцию, чтобы получить краевые значения
Из чего выводы:
🔹 Если программа планируется размером >11к LOC, вам 100% нужно думать насчет архитектуры
🔹 Если программа планируется размером <6k LOC, можно не запариваться
❗️Но помните, вы можете потерять в продуктивности на создании новых фичей до 2 раз, если вовремя не заложите эффективные дизайн и архитектурные решения.
TL;DR цифры разнятся, но значение в 5k LOC предложенное Wang можно считать нижним порогом.
2️⃣ Как долго проект находится в разработке?
Чтобы ответить на второй вопрос просто обратимся к Rational unified process framework'у.
Он предлагает рассматривать разработку любого ПО как итеративный процесс, где каждая итерация идет от 2 до 6 недель.
❗️Дальше не реально будет понять смысл, если не открыть картинку.
Архитектурные и дизайн-решения, исходя из этого framework'а, нужно закладывать на стадии Inception и Elaboration, т.е. в первые 1-3 месяца от старта проекта.
Дальше, уже во время фазы Construction, количество новых решений будет постепенно снижаться.
В целом это очень хорошо согласуется с моим опытом:
На проекте Combat Quest я первые 3 месяца закладывал основу на которой потом 90% времени разрабатывался проект.
Вывод:
🔸 Если проект планируется размером >5k LOC, продумывайте дизайн и архитектуру сразу. Иначе рискуете потерять в продуктивности до 2 раз.
🔸 Если проект стартовал больше полугода назад, нет смысла предлагать новые архитектурные решения. Все решения уже приняты.
Тут сделаю оговорку: амбициозные архитектурные решения. Мелкие улучшения всегда приветствуются.
🔸 Самое лучшее время для продумывания архитектуры — первые 3 месяца от старта проекта.
Фух, это было круто! Я получил дикое удовольствие пока готовил материал и писал эту статью 😊
Весь этот контент в развернутой форме обязательно будет в моем курсе.
В это Воскресенье поделюсь прогрессом и программой!
Включай уведомления чтобы не пропустить 🫡
Сохраняй себе, чтобы не потерять и делись с коллегами 📞
Ставь 👍 если тебе заходит такого рода контент!
#software_engineering@UniArchitect
