Цитата из "красной" книги:
И еще:
Т.е. еще в 2000-х годах было понятно, что с ростом кодовой базы мало того, что нелинейно падает скорость разработки,
так еще и практически экспоненциально растет стоимость проработки архитектуры, требований, интеграции и тестирования. Причем если интеграцию и тестирование до какого-то момента можно победить централизацией и регламентом, то контролировать архитектуру на больших объемах невозможно. Нужны "клоны" главного архитектора, а до таких глубин наука (этика?) пока не дошла)
При этом микросервисы вошли в моду где-то в 2015 году, чему способствовало развитие Docker, k8s и облаков.
А для облачных провайдеров больше сервисов = больше денег)
И они быстро подхватили этот тренд и объявили о поддержке микросервисов.
На самом деле микросервисы - это логическое развитие архитектуры ПО.
C одним но - не всегда shift left выгоден)
Уменьшать размер микросервиса до минимума можно. И формально строк кода в год (день, час) будет написано больше. AI поможет)
Но если бы сделать график стоимости разработки всей системы, а не одного сервиса, то я полагаю, что там будет две экспоненты:
одна при размере микросервиса в 1-5K LoC (строк кода), вторая - 1-5M LoC.
#arch #dev_performance
Доля конструирования снижается, потому что с ростом размера проекта все составляющие конструирования:
проектирование, кодирование, отладка и модульное тестирование — пропорционально масштабируются,
однако затраты на другие виды деятельности растут гораздо быстрее (рис. 27-4).
...
В близких по размеру проектах будут выполняться примерно одинаковые операции,
однако при расхождении в размерах виды выполняемых действий тоже начнут различаться.
... если Gigatron Deluxe в 10 раз больше начального Gigatron,
он потребует в 25 раз больше затрат на конструирование,
в 25–50 — на планирование, в 30 — на интеграцию и в 40 — на архитектуру и системное тестирование.
И еще:
Табл. 27-2. Размер проекта и производительность
Размер проекта (число строк кода) Число строк кода на человека в год
1K 2500–25 000
10K 2000–25 000
100K 1000–20 000
1 000K 700–10 000
10 000K 300–5000
Источники: Составлено на основе данных из «Measures for Excellence» (Putnam and Meyers, 1992),
«Industrial Strength Software» (Putnam and Meyers, 1997),
«Software Cost Estimation with Cocomo II» (Boehm et al., 2000),
и «Software Development Worldwide: The State of the Practice» (Cusumano et al., 2003).
Т.е. еще в 2000-х годах было понятно, что с ростом кодовой базы мало того, что нелинейно падает скорость разработки,
так еще и практически экспоненциально растет стоимость проработки архитектуры, требований, интеграции и тестирования. Причем если интеграцию и тестирование до какого-то момента можно победить централизацией и регламентом, то контролировать архитектуру на больших объемах невозможно. Нужны "клоны" главного архитектора, а до таких глубин наука (этика?) пока не дошла)
При этом микросервисы вошли в моду где-то в 2015 году, чему способствовало развитие Docker, k8s и облаков.
А для облачных провайдеров больше сервисов = больше денег)
И они быстро подхватили этот тренд и объявили о поддержке микросервисов.
На самом деле микросервисы - это логическое развитие архитектуры ПО.
C одним но - не всегда shift left выгоден)
Уменьшать размер микросервиса до минимума можно. И формально строк кода в год (день, час) будет написано больше. AI поможет)
Но если бы сделать график стоимости разработки всей системы, а не одного сервиса, то я полагаю, что там будет две экспоненты:
одна при размере микросервиса в 1-5K LoC (строк кода), вторая - 1-5M LoC.
#arch #dev_performance