Чистая архитектура. Часть I — Введение

в 20:49, , рубрики: Программирование, Проектирование и рефакторинг

Это вольный и очень краткий пересказ новой книги Роберта Мартина (Дяди Боба) «Чистая Архитектура», выпущенной в 2018 году.

Вступительное слово

Программная архитектура немного напоминает строительную архитектуру. В зданиях тоже есть фрактальная структура: здания состоят из отсеков, отсеки состоят из комнат, комнаты — из стен, стены — из кирпичей. Программы же состоят из модулей, которые состоят из пакетов, которые состоят из классов, которые состоят из функций и т.д. Однако разнообразие структур программ намного шире, чем зданий, поэтому Дядя Боб считает программную архитектуру «более архитектурной», чем строительную архитектуру.

Кроме того, строительную архитектуру проще визуализировать в голове, чем программную, потому что здания мы видим каждый день, а архитектура программ от нас скрыта внутри исходного кода. Программная архитектура не похожа ни на что.

С другой стороны, программная архитектура тоже должна помнить про физические ограничения, потому что программы запускаются на реальном железе с ограниченной производительностью, памятью, пропускной способностью сети и т.д.

Что такое хорошая архитектура? Это такая архитектура, которая удовлетворяет потребностям пользователей, владельцев бизнеса и программистов не только в текущий момент времени, но и со временем.

«Если вы считаете, что хорошая архитектура – это дорого, то попробуйте плохую».

«Единственный способ идти быстро – это идти хорошо».

Предисловие

Дядя Боб пишет код более 50 лет. Он писал самые разнообразные программы: большие, маленькие, GUI, консольные, веб и т.д. И пришёл к выводу, что правила архитектуры везде одни и те же! И даже за 50 лет они не изменились несмотря на гигантский рост производительности железа.

Языки программирования тоже стали значительно лучше, но базовые конструкции остались теми же самыми: if, присваивание, циклы и т.д. Если посадить программистку из середины прошлого века за современный МакБук, то она сначала офигеет, но потом будет нормально писать Java-код в Идее.

Но за полвека был накоплен большой опыт, которого ещё не было 50 лет назад. Были сформулированы правила, которым и посвящена данная книга.

Введение

Написать рабочую программу нетрудно. Трудно написать программу правильно. Это требует знаний, опыта и умений, для выработки которых нужно большое время и дисциплина.
Когда программа сделана правильно, то её легко поддерживать и вносить в неё изменения. Там очень низкий процент дефектов. Для неё не нужны орды программистов, тонны документов с требованиями и навороченные трекеры.

Это звучит утопично, но Дяде Бобу удавалось работать в таких проектах. Но к сожалению, в большинстве случаев нам приходится работать в условиях ужасного дизайна.

Что такое дизайн и архитектура?

Давайте считать, что дизайн и архитектура – это одно и то же.

Архитектура – это не только верхний уровень, это верхнеуровневые и низкоуровневые детали в целом. Одного без другого не существует.

Цель программной архитектуры – минимизировать человеческие ресурсы, необходимые для построения и поддержки требуемой системы.

Если усилия невелики и остаются таковыми в течение всей жизни, значит дизайн хороший. Если усилия возрастают с каждым релизом, то дизайн плохой.

В качестве примера Дядя Боб показывает график реального проекта, в котором количество сотрудников возросло в 50 раз, но количество строк кода возросло всего в 2.3 раза (3M -> 7M). Более страшный график – это возрастание стоимости одной строки кода в ~40 раз. Т.е. продуктивность упала со 100% практически до нуля. Программисты работают усердно во всю силу, но по сути ничего не могут сделать. А теперь самое страшное: если в первом релизе приходилось платить сотрудникам несколько сот тысяч долларов в месяц, то в конце эта цифра стала 20 миллионов долларов в месяц!

Далее Дядя Боб вспоминает про притчу про зайца и черепаху. В ней черепаха выиграла гонку, потому что заяц был слишком самоуверенный, лёг спать и проспал всю гонку.

То же самое и с разработкой: программист тешит себя уверенностью, что он сможет по-быстрому выкатить продукт, а навести порядок позже. Однако проблема в том, что после релиза ему нужно делать следующую фичу, иначе он отстанет от конкурентов на рынке. В конце концов его продуктивность через несколько месяцев просто упадёт до нуля и он проиграет.

Далее он приводит пример эксперимента, проведённого неким Джейсоном Горменом, где он пишет простую программу несколько раз. И у него получается, что c TDD первый раз получается быстрее, чем даже третий раз без TDD. То есть если писать правильно, то в итоге получается быстрее.

Разработчик должен нести ответственность за беспорядок, который он привносит в проект. К качеству архитектуры нужно относиться серьёзно. Но для этого нужно знать, что такое хорошая архитектура.

Рассказ о двух ценностях

Есть две ценности – поведение и архитектура.

Поведение означает, что программа удовлетворяет функциональным требованиям и тем самым приносит деньги владельцам бизнеса. Проблема в том, что многие программисты верят, что только это и есть их работа.

Вторая ценность – это качество, при котором программа остаётся в поддерживаемом состоянии. То есть её легко изменять. Сложность изменений должна быть пропорциональна масштабу этих изменений, но не их форме. Архитектура не должна делать предпочтений одних форм по отношению к другим, иначе запросы владельцев будет реализовать сложнее и сложнее с каждым разом.

Что важнее – поведение или архитектура? Менеджеры считают, что важнее, чтобы система работала. Но программисты должны считать наоборот, что важнее архитектура.
Матрица Эйзенхауэра говорит, что важное и несрочное имеет более высокий приоритет, чем срочное и неважное. А архитектура всегда важна в отличие от поведения, поэтому она более приоритетна.

Программист должен бороться за архитектуру. Программист – это тоже участник бизнеса. Архитектура – это его ответственность.

Продолжение следует...

Автор: pull

Источник

* - обязательные к заполнению поля