[Из песочницы] Чистая архитектура. Часть I — Введение
Это вольный и очень краткий пересказ новой книги Роберта Мартина (Дяди Боба) «Чистая Архитектура», выпущенной в 2018 году.
Вступительное слово
Программная архитектура немного напоминает строительную архитектуру. В зданиях тоже есть фрактальная структура: здания состоят из отсеков, отсеки состоят из комнат, комнаты — из стен, стены — из кирпичей. Программы же состоят из модулей, которые состоят из пакетов, которые состоят из классов, которые состоят из функций и т.д. Однако разнообразие структур программ намного шире, чем зданий, поэтому Дядя Боб считает программную архитектуру «более архитектурной», чем строительную архитектуру.
Кроме того, строительную архитектуру проще визуализировать в голове, чем программную, потому что здания мы видим каждый день, а архитектура программ от нас скрыта внутри исходного кода. Программная архитектура не похожа ни на что.
С другой стороны, программная архитектура тоже должна помнить про физические ограничения, потому что программы запускаются на реальном железе с ограниченной производительностью, памятью, пропускной способностью сети и т.д.
Что такое хорошая архитектура? Это такая архитектура, которая удовлетворяет потребностям пользователей, владельцев бизнеса и программистов не только в текущий момент времени, но и со временем.
«Если вы считаете, что хорошая архитектура — это дорого, то попробуйте плохую».
«Единственный способ идти быстро — это идти хорошо».
Предисловие
Дядя Боб пишет код более 50 лет. Он писал самые разнообразные программы: большие, маленькие, GUI, консольные, веб и т.д. И пришёл к выводу, что правила архитектуры везде одни и те же! И даже за 50 лет они не изменились несмотря на гигантский рост производительности железа.
Языки программирования тоже стали значительно лучше, но базовые конструкции остались теми же самыми: if, присваивание, циклы и т.д. Если посадить программистку из середины прошлого века за современный МакБук, то она сначала офигеет, но потом будет нормально писать Java-код в Идее.
Но за полвека был накоплен большой опыт, которого ещё не было 50 лет назад. Были сформулированы правила, которым и посвящена данная книга.
Введение
Написать рабочую программу нетрудно. Трудно написать программу правильно. Это требует знаний, опыта и умений, для выработки которых нужно большое время и дисциплина.
Когда программа сделана правильно, то её легко поддерживать и вносить в неё изменения. Там очень низкий процент дефектов. Для неё не нужны орды программистов, тонны документов с требованиями и навороченные трекеры.
Это звучит утопично, но Дяде Бобу удавалось работать в таких проектах. Но к сожалению, в большинстве случаев нам приходится работать в условиях ужасного дизайна.
Что такое дизайн и архитектура?
Давайте считать, что дизайн и архитектура — это одно и то же.
Архитектура — это не только верхний уровень, это верхнеуровневые и низкоуровневые детали в целом. Одного без другого не существует.
Цель программной архитектуры — минимизировать человеческие ресурсы, необходимые для построения и поддержки требуемой системы.
Если усилия невелики и остаются таковыми в течение всей жизни, значит дизайн хороший. Если усилия возрастают с каждым релизом, то дизайн плохой.
В качестве примера Дядя Боб показывает график реального проекта, в котором количество сотрудников возросло в 50 раз, но количество строк кода возросло всего в 2.3 раза (3M → 7M). Более страшный график — это возрастание стоимости одной строки кода в ~40 раз. Т.е. продуктивность упала со 100% практически до нуля. Программисты работают усердно во всю силу, но по сути ничего не могут сделать. А теперь самое страшное: если в первом релизе приходилось платить сотрудникам несколько сот тысяч долларов в месяц, то в конце эта цифра стала 20 миллионов долларов в месяц!
Далее Дядя Боб вспоминает про притчу про зайца и черепаху. В ней черепаха выиграла гонку, потому что заяц был слишком самоуверенный, лёг спать и проспал всю гонку.
То же самое и с разработкой: программист тешит себя уверенностью, что он сможет по-быстрому выкатить продукт, а навести порядок позже. Однако проблема в том, что после релиза ему нужно делать следующую фичу, иначе он отстанет от конкурентов на рынке. В конце концов его продуктивность через несколько месяцев просто упадёт до нуля и он проиграет.
Далее он приводит пример эксперимента, проведённого неким Джейсоном Горменом, где он пишет простую программу несколько раз. И у него получается, что c TDD первый раз получается быстрее, чем даже третий раз без TDD. То есть если писать правильно, то в итоге получается быстрее.
Разработчик должен нести ответственность за беспорядок, который он привносит в проект. К качеству архитектуры нужно относиться серьёзно. Но для этого нужно знать, что такое хорошая архитектура.
Рассказ о двух ценностях
Есть две ценности — поведение и архитектура.
Поведение означает, что программа удовлетворяет функциональным требованиям и тем самым приносит деньги владельцам бизнеса. Проблема в том, что многие программисты верят, что только это и есть их работа.
Вторая ценность — это качество, при котором программа остаётся в поддерживаемом состоянии. То есть её легко изменять. Сложность изменений должна быть пропорциональна масштабу этих изменений, но не их форме. Архитектура не должна делать предпочтений одних форм по отношению к другим, иначе запросы владельцев будет реализовать сложнее и сложнее с каждым разом.
Что важнее — поведение или архитектура? Менеджеры считают, что важнее, чтобы система работала. Но программисты должны считать наоборот, что важнее архитектура.
Матрица Эйзенхауэра говорит, что важное и несрочное имеет более высокий приоритет, чем срочное и неважное. А архитектура всегда важна в отличие от поведения, поэтому она более приоритетна.
Программист должен бороться за архитектуру. Программист — это тоже участник бизнеса. Архитектура — это его ответственность.
Продолжение следует…
