Концептуальное чтиво. Отзыв на "Liquid Software" и "Чистая архитектура"

Всем привет!

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

Liquid Software: How to Achieve Trusted Continuous Updates in the Devops World

Есть такие люди в нашей отрасли, за выступлениями которых я стараюсь следить. Один из них - Барух Садогурский. Я узнал о нём на конференциях JugRu. В последние годы он активно продвигает в массы тему DevOps, выступая с интересными докладами по этой теме. На одном из них он упомянул, что вместе с  коллегами из JFrog, они написали книгу "Liquid Software", не особо вдаваясь в подробности о чём она. Лейтмотивом выступления была проблема отсутствия доверия клиентов к новому ПО, которая часто тормозит желания вендоров улучшать продукты. И это не удивительно: даже люди из нашей индустрии часто скептически относится к предложениям об установке очередных обновлений по различным причинам. 

В подтверждение тому - сложившаяся ситуация с Java: архитекторы Java решили перейти на 6-и месячный релизный цикл дабы как можно активнее развивать язык и рантайм (хотя ранее мажорны версии языка выходили раз в несколько лет), но постоянные опросы на профильных конференциях "Какая у вас Java на проде?" показывают, что подавляющее большинство компаний всё сидят на Java 8, которая вышла в 2014 году несмотря на то, что в новых релизах нет регрессий!

Наверняка каждый айтишник прошёл в бородатом прошлом через ситуацию, когда он пожалел, что обновил какую-то часть системы и после этого что-то сломалось. Эти раны, полученные в давние дикие времена, когда вопросам QA уделяли совсем мало внимания, или получаемые даже сегодня в экосистемах, в которых разработчики ещё не поняли цену совместимости ПО, не дают шанса вендорам активно обновлять софт у клиентов. Единственный для них способ эффективно развивать свои продукты - это неотключаемые обновления, но их используют, как правило, только интернет-сервисы. Оно и понятно - мало кто хочет разозлить своих клиентов и тем самым даёт возможность клиентам самостоятельно решать - будут они обновляться или нет. Но правильный ли это подход для ситуаций, когда не обновление клиентских инсталляций создаёт угрозу безопасности/корректности/целостности данных систем у клиентов? Нужен ли клиентам корректный и безопасный софт или же только неизменяемый?

То, что сегодня прошло все этапы тестирования и отлично работает у заказчика не принесёт ли ему завтра многомиллионные убытки из-за найденной уязвимости в какой-то из open source библиотек, к которой вы даже не имеете отношения, и как скоро вы сможете это устранить, пока нанесенный ущерб не станет фатальным для вашего клиента или для вашей компании?

Эта книга - описание визионерского направления развития практики Continuous Deployment - Continuous Updates, когда софт автоматически валидируется, доставляется небольшими кусками, и без даунтайма обновляется на инсталляциях клиентов. Все предложенные подходы в этой книге пытаются совместить лучшее из двух миров - стабильность работы клиентских инсталляций и постоянное обновление ПО, о необходимости которого я писал выше. Большая часть книги посвещена проблематике этого вопроса: какие практики обновления ПО мы имеем сейчас, почему так случилось и какие проблемы они создают, что делать с данными при обновлениях, как подстелить себе соломку при обновлении. 

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

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

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

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

Тем временем мы продолжаем быть свидетелями постоянных фэйлов Microsoft с неотключаемыми обновлениями Windows 10, которые, правда, неделю назад они сами выключили из-за очередных массовых проблем, с которыми столкнулись клиенты после обновлений. Ирония.

Чистая архитектура. Искусство разработки программного обеспечения

Это уже третья книга всем известного Роберта "Uncle Bob" Мартина.

Лучше всего об этой книге рассказывает её описание в начале русского перевода:

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

Вот серьёзно, прочитав эту книгу, нечего ни добавить, не убавить. 

Если вы не читали "Идеальный программист" и "Чистый код" - лучше прочитать сперва их, тогда вам будет более понятна аргументация автора в начале книги: почему правильная архитектура не должна оставаться вне зоны внимания разработчиков и архитекторов.

В начале книге даётся описание, что такое архитектура и зачем она нужна. Что более важно - правильная работа системы или простота её изменения? Всё это - обычно очень холиварные темы, но Роберт находит очень веские причины, чтобы сместить чашу весов в одну из сторон и с ним очень сложно не согласиться :) 

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

В начале, для разогрева, он в интересном свете представляет всем известные парадигмы программирования, пытаясь обосновать для чего их вводили и что они давали, по ходу доказывая, что согласно общеупотребимым признакам Си - это вполне себе ООП язык :) 

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

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

Также затрагиваются классические вопросы про связность и сочетаемость компонентов.

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

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

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

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