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

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

 

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

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

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

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

 


 Мы наблюдаем совершенно обыкновенную картину, где с переходом к новой версии (1 — 8) увеличивается число сотрудников участвующих в разработке и обслуживании системы. Теперь взглянем на график продуктивности сотрудников



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

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

В следующих разделах книги идет разговор о парадигмах программирования. Автор делает обзор на три из них:

• структурное 

• объектно-ориентированное 

• функциональное

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

Фактически последние полвека мы учились тому, как не надо делать

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

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

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

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

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

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

После обсуждения принципов SOLID книга набирает обороты в стороны абстракции, и я не могу сказать, что вынес пользу из прочтения “средних” глав книги — видимо снова проблема в опыте. Такой информационный перегруз мне еще не по зубам.

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

Это такие мелочи, которые пока нас не заботят. Мы решим этот вопрос позже

 

 

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

 

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