Хабрахабр

[Из песочницы] Чистая архитектура. Часть I — Введение

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

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

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

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

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

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

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

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

Предисловие

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть