Паттерны отказоустойчивых приложений. Роберт Ганмер

Это книга о технике обработки ошибок, которая делает работу с ними проще.

В первой части мы прочитаем введение и главы 1–4. Рассмотрим понятия отказоустойчивости, принципы отказоучтойчивого дизайна и архитектурные паттерны.

Введение

Мы не живём в идеальном мире. Во всех системах есть ошибки, которые приводят к отказам. Задача разработчиков — минимизировать количество этих ошибок и их негативное воздействие на систему и пользователей.

Шаблоны — это не панацея. Они решают проблемы внутри определённого контекста. После решения проблемы они могут оставить систему в новом контексте с новыми проблемами.

Глава 1. Введение в отказоусточивость

Неисправность, ошибка и отказ — три разных термина.

• Неисправность (fault) — дефект в системе, причина ошибки (error).
• Ошибка (error) — неправильное поведение системы, которое приводит к отказу (failure).
• Отказ (failure) — поведение системы, которое не соответствует спецификациям.

Причинно‑следственная цепочка выглядит так: fault → error → failure.

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

Отказы бывают нескольких видов.

• Тихий отказ (fail‑silent failure) — такой, при котором отказавшая часть либо не предоставляет результата работы, либо предоставляет правильный результат.
• Аварийный отказ (crash failure) — при котором отказавшая часть прекращает работу после первого тихого отказа.
• Отказ с остановкой (fail‑stop failure) — такой аварийный отказ, который виден остальным частям системы.

Также отказы можно поделить на последовательные и непоследовательные. Первые проявляются одинаково для всех частей системы. Вторые могут проявляться по‑разному для разных наблюдателей. Например, могут представлять правильные результаты частям, которые следят за ошибками, и неправильные — для остальных частей.

Покрытие (coverage) — условная вероятность, что система восстановится после ошибки автоматически в заданный отрезок времени. Надёжные (reliable) и доступные (available) системы стремятся к покрытию не меньше, чем 0.95.

Надёжность (reliability) — вероятность, что система будет работать без сбоев в течение заданного промежутка времени. Надёжность описывают:

• среднее время до отказа, MTTF (mean time to failure) — от старта до первого отказа;
• среднее время до восстановления, MTTR (mean time to repair) — с момента отказа до полного восстановления;
• среднее время между отказами, MTBF (mean time between failures) — сумма MTTF и MTTR.

Доступность (availability) — доля времени, в которое система способна выполнять свою функцию. Аптайм (uptime) — время, когда система доступна, даунтайм (downtime) — когда не доступна.

Отказоустойчивая система спроектирована так, чтобы эффективно справляться с нормальной рабочей нагрузкой и изящно (gracefully) справляться с перегрузками.

Глава 2. Отказоустойчивое мышление

Ключевой вопрос при разработке отказоустойчивых приложений — «Что может пойти не так?».

Отказоустойчивость (fault tolerance) — это способность системы нормально функционировать даже при наличии отказов. Также это способность ограничить вред от ошибки, возникшей в системе. Качество (quality) — насколько хорошо система может работать без отказов.

Стремление к отказоустойчивости может привести к технологическому и архитектурному оверхеду. Чрезмерное увеличение сложности для обнаружения и исправления ошибок с большой вероятностью приведёт к ещё большему количеству ошибок. Применяйте KISS.

Важные допущения, проверки и предположения:

• Не полагайтесь слепо на данные из хранилища, они могут содержать ошибки — проверяйте все данные перед использованием.
• Утечка памяти — частая и высоковероятная ошибка.
• Проектируйте структуры данных так, чтобы их можно было проверять и валидировать, а также, чтобы невалидные можно было откорректировать.

Для разработки системы полезно использовать N‑version programming. Это подход, при котором систему независимо проектируют несколько команд. Плюс в том, что команды, скорее всего, будут использовать разные алгоритмы, структуры и подходы. Это увеличит количество альтернатив, из которых можно выбрать содержащую минимальное количество неисправностей.

Тестирование и верификация — ключевые свойства отказоустойчивой системы. Они показывают, успешны ли предотвращение неисправностей и исправление ошибок. Тестирование внедрением ошибок (Fault Insertion Testing) — единственный способ определить покрытие (coverage).

Методология отказоустойчивого дизайна:

• определить, что может пойти не так;
• определить стратегии смягчения рисков, какие действия могут предотвратить появление потенциальных неисправностей;
• создать модель системы, выделяя ключевые точки системы и способы применения избыточности (modes of redundancy);
• внести ключевые архитектурные решения;
• внедрить в архитектуру способы уменьшения рисков;
• учесть необходимость в администрировании людьми всех систем, неважно, насколько они отказоустойчивы.

Глава 3. Введение в паттерны

Жизненный цикл отказа состоит из 4 фаз:

• обнаружение ошибки (error detection);
• восстановление (error recovery);
• уменьшение ошибок (error mitigation);
• обработка отказа (fault treatment).

Системы без внутреннего состояния (stateless) как правило содержат меньше ошибок, чем системы с внутренним состоянием (stateful). Если в системе есть операции, занимающие продолжительное время, её принято считать стейтфул‑системой. Когда стейтфул‑система теряет внутреннее состояние, она теряет способность продолжать функционировать.

Разработка отказоустойчивой системы — дорогая. Готовьтесь вложить больше ресурсов по сравнению с разработкой обычной системы.

Глава 4. Архитектурные паттерны

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

4.1 Блоки уменьшения риска (Units of mitigation)

При разработке вам хочется уменьшить риск полного отключения системы. Как сохранить систему работоспособной при наступлении отказа?

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

Блоки уменьшения риска…

• могут быть продублированы, чтобы обеспечить избыточность;
• это рантайм‑сущности, потому что выполняют работу во время выполнения программы;
• могут представлять собой сгруппированные модули;
• должны быть в состоянии проводить самоконтроль, когда есть подозрение на неправильную работу;
• обязаны быть непреодолимым барьером для ошибок.

4.2. Корректировочные аудиты (Correcting audits)

Ошибки в данных могут и будут возникать.

Данные должны восприниматься неразрывно от их контекста. (1984 может быть валидным годом, но не может быть валидным количеством лет пользователя.) Ошибки в данных приводят к тому, что:

• вычисления, опирающиеся на эти данные, будут неправильными;
• может возникнуть ошибка в данных, связанных с ними;
• может полностью отказать выполнение какой‑либо операции.

Аудиты позволяют выявить некорректные данные.

• Проверьте структурные свойства. Например, что связанные списки — действительно связанные.
• Проверьте известные соотношения. Например, температуру в градусах Фаренгейта можно перепроверить значением в градуах Цельсия.
• Проверьте, что данные не противоречат здравому смыслу. Вряд ли 1984 — валидное количество лет пользователя.
• Проверьте данные прямым сравнением. Если есть отдельная копия тех же данных, проверьте их на соответствие.

Для каждой структуры данных предусмотрите, что может пойти с ней не так. Когда появляется ошибка в данных, хорошим тоном считается:

• скорректировать их;
• записать в логи, что произошло;
• восстановить выполнение программы с того места, когда данные в последний раз были корректными.

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

4.3. Избыточность (Redundancy)

Как уменьшить время между обнаружением ошибки и возврату к нормальной работе после восстановления?

Всё время, пока система не восстановила нормальную работу после ошибки, она недоступна. Уменьшение этого периода времени увеличивает доступность. Один из способов ускорить процесс восстановления — выполнять только самое необходимое для обработки ошибки. Всё остальное — отложить на период после восстановления.

Избыточность (redundancy) бывает нескольких типов:

• пространственная;
• временнáя;
• информационная.

Избыточные элементы не обязательно имеют одинаковую функциональность, всё что нужно — чтобы избыточный элемент мог выполнить какую‑нибудь часть работы дублируемого элемента. Разнообразие — хороший инструмент в борьбе с распространением ошибок в системе.

Избыточность — не бесплатна.

Есть несколько способов обеспечить пространственную избыточность:

• метод «Active‑Active» — полное дублирование функциональности дублируемого элемента; скорейшее восстановление, большие издержки;
• метод «Active‑Standby» — то же, но дублирующий не выполняет полезную функцию сразу; чуть меньшее время восстановления, чуть меньшие издержки;
• «N+M» — есть М активных элементов, есть N избыточных, которые готовы заменить любой из M элементов при появлении отказа.

4.4. Блоки восстановления (Recovery blocks)

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

Программа с блоками восстановления (recovery blocks) состоит из частей с главным блоком и побочными. Если результат работы главного блока не проходит приёмочный тест, полезную работу проводят побочные блоки до тех пор, пока результат не пройдёт тест. Если тест всё равно не проходит, то ошибка регистрируется в Обработчике ошибок (Error Handler).

Общепринятая схема для построения побочных блоков — делать каждый последующий более простым, чем предыдущий. Будьте готовы, что информации может потеряться по пути, так как каждый последующий блок выполняет меньше действий, чем предыдущие.

Избегайте создания слишком большого количества побочных блоков. Используйте Ограничение повторов (Limit retries), чтобы не допустить зацикливания системы.

4.5. Минимизировать человеческое вмешательство (Minimize Human Intervention)

Люди — частая причина множества ошибок. Как оградить людей от выполнения неправильных действий, которые приводят к ошибкам?

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

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

4.6. Максимизировать человеческое участие (Maximize Human Participation)

Должна ли система игнорировать людей в принципе?

Для многих типов систем (например, авионика) возможность оператора перебить или изменить обработку ошибки — жизненно‑необходима. Такие системы могут входить в «безопасный режим» (safe mode) и перестать выполнять автоматические действия, ждя человеческого вмешательства.

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

4.7. Интерфейс тех. обслуживания (Maintenance Interface)

Должны ли сигналы приложения и сигналы тех. обслуживания быть смешаны?

Нет, они должны быть разделены. Сигналы обслуживания должны быть обработаны даже тогда, когда система перегружена. Кроме того, смешение сигналов может привести к дырам в безопасности.

4.8. Ответственный (Someone in charge)

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

Когда система знает, что она должна выполнять в конкретный момент времени, она более крепкая. Часть системы, которая может определить, что что‑то не работает, или работает не правильно, называется Наблюдатель отказов (Fault observer).

Для каждого отдельного действия, связанного с обработкой ошибок, должна быть одна чётко определённая сущность.

4.9. Эскалация (Escalation)

Что делать системе, если её попытки обработать ошибку не достигли желаемого результата?

Применять методы обработки со следующих уровней. Поднимать ошибку «наверх» в иерархии системы. Отдавать сигнал на «подъём» должен Ответственный (Someone in charge).

4.10. Наблюдатель отказов (Fault observer)

Система не падает после ошибки, а обрабатывает их автоматически. Как нам понять, какие ошибки и когда произошли?

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

Сообщайте обо всех ошибках Наблюдателю. Он позаботится о том, чтобы все заинтересованные стороны узнали об ошибках, которые произошли.

4.11. Обновление программы (Software update)

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

Внедряйте способность вносить изменения, патчи, обновления в архитектуру с первого релиза. Не надейтесь, что даже после этого обновление будет простой задачей в будущем.

Что дальше?

В следующей части проичтаем главы 5–8. Рассмотрим паттерны обнаружения ошибок, восстановления от них, снижения их вероятности и «замазывания брешей».

Ссылки

• Patterns for Fault Tolerant Software. Robert Hanmer
• KISS
• N‑version programming

Что я понял, благодаря неуспехам. Реджинальд Брейдвайт

Эта книга больше не о программировании, а скорее об отношении к работе и индустрии в целом. Что делать, чего не делать, почему так, и к чему приводят неправильные решения.

Онлайн‑версию в оригинале можно прочитать бесплатно. Она довольно короткая, я осилил за вечер.

Глава 1. Что я понял, благодаря неуспехам

Разработка проекта может провалиться, если хотя бы одна из составляющих хромает:

• компетентность разработчиков;
• адекватные ожидания от качества продукта;
• пригодность предлагаемых решений в разработке и управлении;
• компетентность проектного руководства и коммуникаций.

Люди

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

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

Внешние навязанные ограничения (государственные, например) как правило вредят.

Действие

Получать обратную связь надо быстро — fail fast! Чем раньше узнаете, что у вас проблемы, тем проще найти решение. Работает как в отношении кода, так и продукта в целом.

Детали

Детали и спорные решения в проекте должны быть всегда видны всем. Перестать следить за деталями — начать хоронить проект.

Расписание

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

Сила

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

История

Гипотеза, основанная на действиях из прошлого, может не сработать в будущем.

«Если бы мы больше времени уделили планированию, то спланировали бы лучше; так было в прошлом проекте» — вовсе не факт.

Уметь заканчивать

Уходить из проекта тоже иногда полезно. Игра в героя, который тащит на себе всё, может плохо сказаться как на здоровье «героя», так и на здоровье проекта. Иногда вам не обязательно заканчивать то, что начали вы. Иногда вам не обязательно заканчивать то, что начали другие.

Глава 2. Дизайн софта

Строить лучше

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

Лучшая архитектура

Архитектура тем лучше, чем точнее и детальнее описывает конкретно этот проект. Она должна быть компактной, но детально описывать особенности.

Глава 3. Теория, которая подтверждает наблюдения

Теория D, теория P, и почему они важны

Если мы верим в теорию D (deterministic — что процесс можно описать полностью, и если что‑то не сходится, то у нас просто не хватает данных), то мы верим, что проект можно спланировать заранее и полностью.

Если мы верим в теорию P (probabilistic — что предсказать полностью ничего нельзя, а только какие‑то части и только с какой‑то точностью), то мы верим, что планировать следует только какие‑то части проекта, и когда что‑то идёт не так, нам надо добавить в план новую информацию, чтобы скорректировать его.

Вера определяет поведение

Адепты теории D верят, что:

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

Адепты теории P верят, что:

• спланировать можно только какие‑то части проекта, но не проект целиком;
• при расчёте времени все, все, все лгут, зачастую — неосознанно;
• самое важное в разработке — обучение, зачастую — на ошибках;
• командная работа лучше одиночной;
• использовать фреймворки следует осторожно, сравнив, какие проблемы они позволят решить и какие принесут с собой.

Глава 5. Проект‑менеджмент как рынок с информацией

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

Проект похож на рынок, где какая‑то информация ценится там, где её не хватает. Задача менеджеров в том, чтобы уметь отделять ценную информацию (которая поможет предсказать исход проекта или его части) от неценной; уметь «покупать» её у разработчиков и «продавать» её руководству или инвесторам.

Глава 6. Кирпичи

Софт делается не из кирпичей

Аналогия с кирпичами опасна. Кирпичи — слишком простые. Если понятно, как работать с одним кирпичом, понятно, как работать с остальными. В софте не так. Мало того, что там не всегда понятно, как обращаться с «кирпичами», там ещё и непонятно, сколько их надо, чтобы собрать проект.

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

Разработку трудно параллелить

«Кирпичи» из которых состоит софт, связаны друг с другом в каком‑либо виде. Чтобы разрабатывать их параллельно, требуется изначально продумать, как они должны взаимодействовать — что не всегда получается хорошо.

Если добавлять людей в проект, чтобы распараллелить разработку на поздних стадиях (когда какая‑то часть уже написана), то продуктивность даже упадёт.

Вторая беда с аналогией про кирпичи в том, что она позволяет думать, будто можно оценить прогресс по количеству использованных кирпичей. Но софт — трансфинитивен (простите, я не смог перевести иначе).

Важную роль также играет и «куда положить какой кирпич» и «как его соединить с другими». Одна ошибка может откатить отметку прогресса сильно назад.

Третье отличие от кирпичей: с развитием проекта меняются клиентские требования, поэтому прогресс придётся пересчитывать постоянно.

Глава 7. Цикл «попытка‑провал»

Весь смысл этого цикла в том, чтобы создать план, но заранее понимать, что план не выдержит столкновения с реальностью. Поэтому лучше напороться на проблемы раньше (fail fast!).

Обратная связь

Есть ошибка, при которой софт разрабатывается инкрементами вместо итераций.

Инкремент — часть софта, которая сама по себе закончена, но не несёт ценности для бизнеса. Итерация — законченная часть, которая несёт ценность бизнесу.

Чтобы обратная связь работала, это должна быть обратная связь от настоящих пользователей. Единственный способ получать такую обратную связь и получать её быстро — итеративная разработка.

Глава 8. Облысение софта

Технический долг приводит к нерабочему продукту.

Глава 9. Мышиная ловушка

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

Глава 10. Утиное программирование

Это менеджерский антипаттерн; мнение, что всё, что не связано с программистами, языками программирования или инструментами — программированием не является.

Глава 11. Не получается найти хороших продажников

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

Эту книгу дополнят

Некоторые другие книги о программировании:

• Чистый код. Роберт Мартин
• Чистая архитектура. Роберт Мартин
• Читаемый код или программирование как искусство. Б. Дастин, Ф. Трэвор

И вообще:

• Антихрупкость. Нассим Талеб
• Чёрный лебедь. Нассим Талеб
• Взлом маркетинга. Фил Барден

Чистая архитектура. Часть 3

В прошлый раз мы говорили о связанности и сочетаемости компонентов систем, а также обсудили подробнее цели хорошей архитектуры. Сегодня подробнее рассмотрим бизнес‑правила, уровни архитектуры, немного поговорим о шаблонах и тестах.

Глава 20. Бизнес‑правила

Коротко:

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

Бизнес‑правила — это правила или процедуры, которые приносят или сохраняют бизнесу деньги, при этом неважно, выполнены эти процедуры на компьютере или вручную. Такие правила называют критичными правилами, а данные, с которыми работают эти правила — критичными данными.

Сущность — это контейнер, который содержит набор критичных правил и данных для их работы.

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

Юзкейсы зависят от входных данных и производят выходные данные, но при этом не зависят от формы, в которой эти данные передаются.

Глава 21. Говорящая архитектура

Коротко:

• Архитектура — это не про фреймворки.
• Хорошая архитектура рассказывает, какую систему она описывает, а не на чём построена.

Фреймворки — это инструмент, а не материал. Архитектура должна основываться на юзкейсах, а не на фреймворках. Хорошая архитектура позволяет откладывать решения о выборе фреймворка и менять их, если придётся.

Веб — это механизм ввода‑вывода.

Хорошая архитектура рассказывает, какую систему она описывает, а не на чём построена.

Глава 22. Чистая архитектура

Коротко, чистая архитектура:

• не зависит от фреймворков;
• легко тестируется;
• не зависит от пользовательского интерфейса;
• не зависит от базы данных;
• не зависит от каких‑либо внешних агентов.

Внешние слои могут зависеть от внутренних, но не наоборот: 

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

Главы 23–25

Коротко:

• Сделать систему тестируемой помогает шаблон простого объекта.
• Скрыть сложную логику можно за фасадами.
• Стоит почаще задаваться вопросом «а понадобится ли мне это?».

Глава 26. Корневой компонент

Коротко:

• Корневой компонент — тот, который создаёт, управляет и контролирует все остальные.
• Корневой компонент должен быть снаружи архитектуры системы.

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

Глава 27. Сервисы

Коротко:

• Сервисы слабо‑связаны, но так бывает не всегда.
• Сервисы помогают достичь независимого деплоя, но так тоже бывает не всегда ¯\_(ツ)_/¯
• Архитектура определяется не сервисами как таковыми, а границами между значимыми компонентами системы.

Глава 28. Тесты

Коротко:

• Тесты — часть системы.
• Если тесты сильно связаны с компонентами, то небольшое изменение может уронить сотни тестов.

Что дальше

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

Вместе с этой книгой советую прочитать пару других:

• Р. Мартин. Чистый код
• Д. Босуэлл, Т. Фаучер. Читаемый код или программирование как искусство

Предыдущие части:

• Первая
• Вторая

И ссылки из конспекта:

• SOLID
• Простой объект
• Фасад

Чистая архитектура. Часть 2

В первой части мы рассмотрели понятие архитектуры, парадигмы программирования и принципы SOLID. Сегодня поговорим о связанности и сочетаемости компонентов систем, а также обсудим подробнее цели хорошей архитектуры.

Глава 12. Компоненты

Коротко:

• Компонент — наименьшая сущность, которую можно задеплоить, как часть системы.
• Компоненты, DLL — плагины к бизнес‑правилам.

Глава 13. Связность компонентов

Коротко — чтобы определить, к какому компоненту относится тот или иной класс, следует пользоваться 3 принципами:

• принцип эквивалентности переиспользования и перевыпуска;
• принцип общей причины для изменения;
• принцип совместного переиспользования.

Принцип эквивалентности переиспользования

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

Принцип общей причины для изменения

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

Принцип совместного переиспользования

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

Глава 14. Сочетаемость компонентов

Коротко — чтобы определить отношения между компонентами, следует пользоваться 3 принципами:

• принцип ацикличности зависимостей;
• принцип стабильных зависимостей;
• принцип стабильности абстракций.

Принцип ацикличности зависимостей

Не допускайте зацикленности в графе зависимостей компонента. Если в зависимостях есть цикл, его можно разорвать одним из 2 способов:

• применить принцип инверсии зависимостей;
• создать новый компонент, от которого будут зависеть компоненты, вызывающие цикличность.

Принцип стабильных зависимостей

Зависимости должны быть направлены в сторону устойчивости. Некоторые компоненты должны быть более изменяемыми, чтобы удовлетворять изменения в бизнес‑требованиях. И такие менее стабильные компоненты должны зависеть от более стабильных.

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

Нестабильность = Кол‑во выходных / (Кол‑во входных + Кол‑во выходных)

Принцип стабильности абстракций

Компонент должен быть настолько же абстрактным, насколько он стабилен.

Абстрактность = Кол‑во абстрактных классов и интерфейсов в компоненте / Общее количество классов в компоненте

По оси Х — нестабильность, по оси Y — абстрактность. Следует придерживаться линии main sequence и избегать зон по углам:

Глава 15. Что такое архитектура

Коротко:

• Цель хорошей архитектуры — облегчить разработку, деплой и поддержку системы.
• Хорошая архитектура выделяет бизнес‑логику и считает её важнейшим элементом системы.
• Хорошая архитектура пытается построить систему так, будто количество непринятых решений относительно деталей — максимально.

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

Каждая система может быть разбита на две части: бизнес‑логика и детали реализации. Детали говорят, как пользователи, компоненты и т. д. общаются с бизнес‑логикой. Хорошая архитектура выделяет бизнес‑логику и считает её важнейшим элементом системы, делая её независимой от деталей реализации.

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

Это позволяет абстрагироваться от деталей реализации и отсрочивать решения относительно них. Хорошая архитектура пытается построить систему так, будто количество непринятых решений относительно деталей — максимально.

Глава 16. Независимость

Коротко — архитектура должна поддерживать:

• юзкейсы;
• поддерживаемость;
• разработку;
• лёгкий деплой системы.

Мы не знаем заранее всех юзкейсов, организацию команды разработки, требования к деплою и т. д. А даже если бы и знали, то они всё равно бы менялись во время жизни системы. Хорошая архитектура позволяет вносить изменения дешевле.

Следует делить систему на слои. Например:

• независимые бизнес‑правила;
• бизнес‑правила под конкретно это приложение;
• пользовательский интерфейс;
• база данных и др.

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

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

Разделять систему можно по‑разному:

• на уровне исходников;
• уровне развёртывания;
• и сервисном уровне.

Какой способ подходит, зависит от самого проекта, стадии, на которой он находится и других параметров.

Глава 17. Границы

Коротко:

• знание одного компонента системы о других должно быть ограничено;
• границы должны отделять сущности, которые имеют значение (для бизнес‑логики) от тех, которые не имеют значения;
• основа — бизнес‑логика.

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

Границы должны отделять сущности, которые имеют значение (для бизнес‑логики) от тех, которые не имеют значения. Например, бизнес‑логика не должна зависеть ни от схемы БД, ни от языка запросов.

В хорошей архитектуре бизнес‑логика — это основа, а всё остальное: устройства ввода‑вывода, БД и т. д. — плагины к ней:

Что дальше?

В третьей части подробнее обсудим бизнес‑правила, уровни архитектуры, немного поговорим о шаблонах и тестах.

Чистая архитектура. Роберт Мартин

Это первая из 3 частей конспекта. В ней мы затронем понятие архитектуры, обзор парадигм программирования и объяснение принципов SOLID.

Предисловие и введение

Коротко:

• Правила построения архитектуры одинаковы для любых программных систем.
• Трудности в поддержке возникают из‑за плохой архитектуры.

Железо меняется радикально и быстро, софт — не меняется. Он состоит из условий, присвоений и циклов. Есть разные парадигмы и приёмы, но в конечном счёте всё преобразовывается в условия, присвоения и циклы. И именно поэтому правила построения архитектуры универсальны.

Заставить код работать не трудно. Его трудно развивать и поддерживать. Если софт сделан правильно, то вносить изменения или дополнять функциональность не больно и быстро. И наоборот, если софт построен неправильно, то количество усилий для работы вырастает в разы.

Глава 1. Что такое дизайн и архитектура

Коротко:

• Цель хорошей архитектуры — минифицировать потребные ресурсы для поддержки и улучшения софта.
• Говнокод тормозит разработку не только в будущем, но и прямо сейчас.

Разницы между дизайном и архитектурой софта нет. На примере архитектора (не программного): он продумывает технические аспекты здания, но также описывает то, как здание выглядит.

Цель хорошей архитектуры — минифицировать потребные ресурсы для поддержки и улучшения софта.

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

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

Глава 2. Сказка о двух ценностях

Коротко:

• Разработчики отвечают за два аспекта софта: его поведение и структуру.
• Хорошая архитектура не зависит ни от какой модели системы, придуманной разработчиками.
• Поддерживаемость в будущем важнее соответствия требованиям прямо сейчас.

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

В термине software есть часть soft, которая значит, что система должна быть «мягкой», легкоизменяемой. Если каждое изменение противоречит предыдущим, не вписывается в уже созданную модель, то вносить именения в будущем будет сложнее. Хорошая архитектура не зависит ни от какой модели и не отдаёт предпочтений ни одной из них.

Что важнее? На примерах:

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

Разработчикам придётся доказывать пользу от рефакторинга и улучшения архитектуры.

Глава 3. Обзор парадигм

Коротко: и структурное, и объектно‑ориентированное, и функциональное программирование — все парадигмы что‑то запрещают. Парадигмы точно знают и говорят нам, чего не стоит делать.

Глава 4. Структурное программирование

Коротко:

• Понимать программу полностью сложно, её надо разбивать.
• Необдуманный прямой контроль (goto) — плохо.
• Тесты помогают найти и доказать, что баг есть. Они не доказывают, что багов нет.

Дейкстра заметил, что понимать программу полностью — сложно, а goto мешают разбивать её на более мелкие части. При этом простые управляющие конструкции — if/else, do/while — наоборот, облегчали работу. Из таких элементарных управляющих конструкций может быть построена любая программа.

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

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

Глава 5. Объектно‑ориентированное программирование

Коротко:

• ООП: инкапсуляция, полиморфизм, наследование?
• Делайте важное ядром, а всё остальное плагинами к нему.

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

Наследование по сути просто переобъявление каких‑то полей или методов. Есть не только в ОО языках, хотя в них наследование работает удобнее.

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

Плагинная архитектура значит, что интерфейс и база данных должны зависеть от бизнес‑правил, а не наоборот. Интерфейс и БД — это плагины, дополнения к бизнес‑правилам и зависят от них. Это значит, что код бизнес‑правил ничего не знает ни об интерфейсе, ни о базе данных — он вообще никак с ними не связан.

Код бизнес‑правил может меняться и выкатываться в прод независимо от чего‑либо ещё.

Глава 6. Функциональное программирование

Коротко: иммутабельность данных — хорошо.

ФП учит иммутабельности данных. Но есть несколько компромиссов. Например, наличие в приложении как чистых компонентов, так и компонентов с сайд‑эффектами.

ФП предлагает идею event sourcing (над переводом не уверен, поэтому пусть остаётся ивент‑сорсинг, прим. автора статьи) — когда мы не храним состояние, а храним транзакции (переходы между состояниями). Чтобы получить стейт в какой‑то момент времени, надо применить к начальному стейту все транзакции, которые произошли к нужному моменту времени.

Глава 7. Принцип единой ответственности

Коротко: функция должна решать только одну задачу.

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

Делить сущности стоит как можно дотошнее, чтобы они были минимальными. Для объединения сложной логики в один метод можно использовать фасады.

Глава 8. Принцип открытости для расширения и закрытости для модификации

Коротко:

• Поведение сущности должно быть расширяемым без необходимости менять саму сущность.
• Если компонент А должен быть защищён от изменений в компоненте Б, то компонент Б должен зависеть от компонента А.

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

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

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

Глава 9. Принцип подстановки Барбары Лисков

Коротко: функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.

Типичный пример нарушения принципа: допустим есть класс Rectangle, от него наследуется класс Square. Это не совсем верно, так как у прямоугольника стороны могут меняться независимо, а у квадрата они должны меняться вместе. Узнать снаружи о том, экземпляром какого класса является объект, можно только, если напрямую спросить об этом.

Глава 10. Принцип разделения интерфейса

Коротко: зависимость от чего‑то, что вы на самом деле не используете, может вызвать проблемы, которых вы не предвидите.

Если представить ситуацию, где User1 зависит только от op1, то первая архитектура первой диаграммы может привести к лишним перекомпиляциям:

Архитектура на второй диаграмме эту проблему решает:

Глава 11. Принцип инверсии зависимостей

Коротко:

• Модули должны зависеть от абстракций, а не от деталей реализации.
• Абстракции не должны зависеть от деталей реализации.

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

Что дальше?

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

В третьей обсудим бизнес‑правила, уровни архитектуры, немного поговорим о шаблонах и тестах.