The New Economics for Industry, Government, Education — W. E. Deming

https://www.audible.com/pd/The-New-Economics-Third-Edition-Audiobook/B07L5ZCZ6V

Книга не новая, первое издание вышло еще в 1993 году (в том же году умер автор), но так как Дёминг считается одним из классиков теории менеджмента — было весьма интересно прослушать. Что интересно — книга вполне актуальна, и не знай я, что она написана в 1993 году мог бы подумать, что она современна, Дёминг как будто спорит со многими статьями в интернете и обсуждениями в телеграм-чатах 🙂

В первую очередь и затем многократно на всём протяжении книги Дёминг говорит о вреде конкуренции (внезапно 🙂

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

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

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

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

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

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

Для иллюстрации этой идеи Дёминг описывает эксперимент с красными бусами — он весьма показателен — так что я нашёл ссылку именно на его описание 🙂
https://advanced-quality-tools.ru/deming-redbeadexperiment.html

Отдельно отмечу некоторый минус конкретно этого издания книги — где-то четверть если не больше — это не сама книга и мысли Дёминга — а предисловие и послесловие о том, как Дёминг велик, как он крут и как все должны к нему прислушаться 🙂 Оно весьма вероятно так — но меня бы больше устроило, если бы этот контент занимал процентов 5 🙂

Fundamentals of Software Architecture: An Engineering Approach — Neal Ford, Mark Richards

https://www.audible.com/pd/Fundamentals-of-Software-Architecture-Audiobook/B08X917VLR

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

Первой полезной главной внезапно оказалась глава о модульности. Казалось бы, ну что ещё можно сказать о модулях, связности и т.п. думал я — но оказалось, что учиться и узнавать новое никогда не поздно 🙂 После рассказа про то, что такое модульность, авторы переходят в характеристикам определяющим степень связности внутри ПО. Начинают с coupling (тут было все знакомо), но затем переходят к непроизносимым (и с неугадываемым на слух написанием) cohesion и сonnascence.

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

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

Дальше авторы переходят к рассуждениям о том какие бывают архитектурные характеристики и о fitness functions для них. Материал сильно совпадает с книгой Building evolutionary architectures. Из нового (или упущенного мной при чтении той книги) — мысль о роли фитнес функций как инструмента управления (governance), когда архитектор непосредственно не пишет и не ревьюит код, но обеспечивает нужные характеристики через фитнес функции.

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

Следующей очень интересной главой была глава про компоненты, проектирование системы исходя из них. Не сказать, что что-то новое, но наводящее порядок в голове. Авторы пишут, что есть два основных подхода к выделению компонентов. Первый — исходя из технических характеристик (слоеная архитектура, mvc) — компонент работы с базой, компоненты бизнес логики, компоненты представления. Второй — исходя из бизнес-доменов, по заветам DDD. Оба имеют свои плюсы и минусы и какой выберете вы во многом должно зависеть от закона Конвея — как организованы люди у вас в компании. Если у вас отдельные отделы дба, бэкенда и фронтенда — вам ближе первый способ. Если же кроссфункциональные команды, отвечающие за отдельные части продукта — второй. Но верно и обратное, можно воспользоваться обратным законом Конвея и, если вы по каким-то причинам предпочитаете какой-то из этих подходов — надо переорганизовать команды, чтобы они соответствовали выбранной архитектуре.

Во второй части книги начинается описание архитектурных стилей. И начинается он просто огненно — упомянув, что базовым водоразделом между разными стилями является какая архитектура — монолитная или распределённая используется — авторы рассказывают о заблуждениях (fallacies), которые часто бывают при построении распределенных систем. Я просто перечислю их тут, а в книге к каждому заблуждению приводятся примеры и объяснения:

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

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

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

Далее авторы рассматривают

Рipeline architecture — интересный подход, тоже монолитный, но несколько снижающий сложность и повышающий независимость отдельных компонентов (если только вы не наворотите сложную сеть этих фильтров)

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

Service based architecture — первая распределённая архитектура. Авторы предлагают ее называть далее макросервисной — сервисы большие, продукт состоит из 6-20 сервисов. Чаще всего при этом используется одна БД. При использовании одной БД важное тут, чтобы сервисы не были связаны друг с другом структурой БД.

Event driven architecture — архитектура на основе обработки потока событий. Описывается два варианта топологии — broker и mediator. В первом случае есть только общая инфраструктура для передачи сообщений, логика определяется самими обработчиками событий, можно легко добавить новые обработчики, не предусмотренные ранее. Но очень сложно обрабатывать ошибки, очень сложно понять завершилась ли операция и успешно ли. Второй — с центральным медиатором, который управляет процессом и контролирует ошибки, завершение процесса и т.п.
Также в этой главе описываются вопросы асинхронной обработки сообщений без потери данных, организации запроса-ответа в эту архитектуре, но подробнее эта тема рассматривается в недавно прочитанной Enterprise Integration Patterns. У нас события активно используются и в этой главе ничего особо нового для меня не было.

Space based architecture — очень интересная архитектура, в которой центральная БД заменяется распределенным реплицированным кешем, таким как hazelcast или apache ignite. Или если данных много или они очень часто обновляются — общим распределенным кешем. Плюс — высокая скорость работы, высокая доступность (в случае реплицированного кеша). Минус — высокая сложность, ограниченная применимость (далеко не все данные можно полностью поместить в оперативную память, ещё и дублируя ее на многих нодах). Но интересно.

Затем авторы проходятся по orchestration driven service based architecture — как примеру того, что осталось в прошлом, хотя было нацелено на казалось бы благородную цель — максимальный reuse кода и компонентов. В итоге это на практике выливалось в очень сильную связность и сложность внесения изменений, так как от одних компонентов зависит множество других.

И наконец приходят, как к ее противоположности, к микросервисной архитектуре. Честно говоря в главе про нее ничего особо нового не говорится — мысли те же, про связанность ее с идеями DDD и bounded contexts. Важный момент про необходимость избегать распределенных транзакций и что их наличие в большинстве случаев говорит о том, что сервисы выделены неверно — или слишком мелко или не по тем границам — всё требующее транзакции, за очень редкими исключениями, должно быть внутри одного сервиса.

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

Последняя часть книги посвящена не архитектуре самой по себе, но работе архитектора:

  • как документировать и описывать архитектуру — тут описывается идея ADR. Мне показалось что оно должно быть хорошо применимо для больших команд, хотя возможно что какие-то важные моменты было бы неплохо так документировать и у нас (где только время на это взять)
  • анализ рисков, предлагается оценивать риски по метрике, характеризующей расположение риска на шкалах критичности и вероятности. Важная мысль — любая новая, неизвестная технология — это всегда high risk
  • насколько архитектор должен быть включен в работу команд, как найти правильный баланс на шкале control freak — armchair architect
  • базовые техники переговоров — основная мысль тут, что архитектурные решения надо не спускать сверху, а продавать разработчикам, объясняя зачем они приняты и по возможности давая разработчикам достаточно информации, чтобы они сами пришли к тому решению, которое считает правильным архитектор

Technology Strategy Patterns — Eben Hewitt

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

В первой части автор рассматривает паттерны для анализа, на которые по его словам опираются все остальные. MECE lists, logic tree, hypothesis. Собственно интересное из этого только первое, да и то больше из-за названия, которое раньше не слышал — речь про списки непересекающихся сущностей, покрывающих при этом всё пространство возможных вариантов. В остальном в этой части много хороших рассуждений, но уж совсем базовых. В частности советы о договориться о терминах, но после Эванса оно воспринимается как — ну а как иначе-то.

Далее автор описывает паттерны анализа контекста окружающего мира, влияющего на вашу стратегию. Начинает с PESTEL — опять незнакомое мне ранее слово — суть, что надо посмотреть на влияющие на вас текущие изменения в области политики, экономики, общества (society), технологий, окружающей среды (environment) и законодательства (legal)

И далее, опираясь уже на них, делать сначала scenario planning — набрасывая вероятные сценарии, затем futures funnel, классифицируя различные вероятные сценарии будущего, выделяя среди них с одной стороны более вероятные, а с другой более желательные нам. Ну и далее применять backcasting, рассуждая какие предыдущие шаги необходимы чтобы попасть именно в желаемое нами будущее.

Следующими идут паттерны для анализа industry context

SWOT pattern

Porter’s Five Forces

Ansoff Growth Matrix

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

Глава про Corporate context показалась не сильно интересной, потому что относится именно к работе в большой корпорации — все эти выясните стейкхолдеров, выясните откуда деньги, спланируйте запросы бюджета на проект весной, чтобы к следующему году этот бюджет получить… Ну и опять квадранты и квадранты.

Principles, practices, tools — идея из следующей главы про department context. Суть в том, что чтобы быть уверенным что компания движется в правильном направлении, мы обозначаем набор принципов, которым мы следуем как компания, но не останавливаемся на этом — а для каждого принципа перечисляем набор используемых практик и инструментов, поддерживающих эту практику. Предполагается выражать это например с помощью диаграмм https://sankeymatic.com/
Идея очень перекликается с идеями из курса системного мышления Левенчука, что мы меняем состояние альф, используя практики, поддержанные технологией. И принципы в таком случае должны отражать характеристики тех изменений в реальном мире, которые мы хотим получить в ходе деятельности нашей команды.

Другая идея из этой главы — application portfolio management (APM) — идея, что все разрабатываемые приложения оцениваются с одной стороны по степени их полезности для бизнеса, а с другой — по стоимости их поддержки — на основе этого принимаются решения от каких стоит отказаться, на какие направить лучшие силы и т.п. Опять предлагается рисовать квадранты 🙂

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

Потом автор рассказывает, как организовать Scalable business machine — но выходит весьма краткое и неполное перечисление элементов системной схемы проекта из курса системного мышления Левенчука (которая в свою очередь основана на OMG Essence). Прямо вот это всё — что делаем в физическом мире, кто делает, какие роли есть в проекте, для кого делаем, с помощью каких практик, при помощи каких технологий — другими словами и по верхам, но о том же.

И в завершение показывает шаблоны которые использовать для презентации своих идей. Такие как One-slider — выражаем наше видение и как мы планируем реализовать его на практике кратко в одном слайде подобной структуры

А также Use Case Map, Priority Map, Technology Radar, Ghost desk, Ask desk и другие

Мне пока эта часть показалась не сильно полезной, наверно потому что работаю не в корпорации, где все это бы пригодилось 🙂

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

The Phoenix Project

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

Что могу сказать — авторы явно очень вдохновлялись Целью Голдратта 🙂 Настолько, что даже явно упоминают ее неоднократно в книге. Так что если вы читали Цель — то это она, но про нашу индустрию.

Как и Цель — это производственный роман, описывающий идею — так что главное тут не персонажи, они весьма шаблонные, а идеи трансформации в работе IT.
Книга состоит из трёх частей — в первой описывается как было, во второй как из этого выбрались, ну и в третьей — движение к новым вершинам ) И честно говоря самой увлекательной была первая. Все эти проблемы, происходящие одновременно и необходимость и выбираться из них и как-то менять работу к лучшему… Честно говоря, такое начало породило у меня завышенные ожидания — я думал, что авторы покажут, как в таком режиме герои смогут осуществить трансформацию процессов работы, ещё и без поддержки начальства. Но увы — в конце первой главы главный герой кладёт заявление на стол и дальше появляется deus ex machina — влиятельный наставник и член совета директоров внезапно влияет на СЕО, да так, что тот внезапно прозревает (с чего бы?), заявляет, что был не прав и даёт главному герою полный карт-бланш на изменения, одновременно ещё и устраивая какой-то сеанс психотерапии с рассказом о своих слабостях и проблемах (что это вообще было?..). Увы-увы. На этом какая-то интрига и накал спадают (лишь изредка делается попытка создать хоть видимость интриги с нависающими сроками и интригами от главы маркетинга, метящей в СЕО — но слабенькая). И дальше книга превращается сначала в иллюстрацию того, как понять что ИТ должно делать для бизнеса. Тут все прямо как в Technology strategy patterns, которую я как раз читаю параллельно — составить список стейкхолдеров, составить список их KPI, составить список какие действия или бездействия IT больше всего влияют на них, определить какие меры могут дать максимальное влияние на показатели составляющие KPI руководства — привязать и показать прямую связь действий ИТ команды с конкретными бизнес показателями.
А затем следует иллюстрированный примерами перечень идей по девопс трансформации — тут на сегодняшний день тоже никаких откровений — автоматизация деплоя и тестирования, уменьшение батч сайза релизов, частые и автоматические релизы, определение и устранение узких мест, плотная работа с бизнес-заказчиками. С учётом того, что внедряется оно в книге в режиме «придумали — без проблем внедрили, получили огромный профит» — не увлекает, внедрение контроля над изменениями в первой части было увлекательнее 🙂

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

Building Evolutionary Architectures

https://learning.oreilly.com/library/view/building-evolutionary-architectures/9781491986356/

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

В первых главах автор (их несколько, но думаю кто-то из них 🙂 ) рассуждает о том, что в современном мире программные системы не статичны — возможность развития и изменения в соответствии с меняющимися условиям бизнеса является важным требованием сама по себе. При этом любая архитектура программной системы должна удовлетворять своему списку -bilitys (например scalability / high availability / security / … ). Пусть мы определили, какие требования к архитектуре нашей системы и наш программный продукт удовлетворяет им в текущий момент, но если мы говорим о поддержке изменений и развития необходимо отслеживать, что все эти -bilitys продолжают соблюдаться. Для этой цели вводятся fitness functions — измеримые показатели соответствия каждому из -bilitys. Это могут быть время отклика веб страницы, время доставки товара, количество инцидентов, степень покрытия тестами и т.п. Мы встраиваем измерение этих характеристик или просто в наш мониторинг или если речь про характеристики кода — прямо в пайплайн, не позволяя им снижаться.

Далее он рассуждает о разных архитектурах и насколько легко они поддаются эволюции. Несколько легко для них отслеживать связи и зависимости, определять фитнес функции, писать функциональные тесты. Начинает с big ball of mud и через монолит, систему с интеграционной шиной, сервисную архитектуру доходит до микросервисной. В процессе часто упоминается DDD и присущие ему идеи, такие как bounded contexts.

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

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

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

В целом, повторюсь — потраченного на книгу времени не пожалел 🙂 Идея с фитнес-функциями вроде как лежит на поверхности, но тщательно проговоренная и подкрепленная примерами — особенно хороша.

Isaac Asimov — Foundation’s Edge

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

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

Татьяна Мужицкая — Теория невероятности

Автора посоветовали в каком-то из выпусков подкаста разговоры СТО, ну и решил попробовать послушать.

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

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

Роберт Сапольски — Кто мы такие? Гены, наше тело, общество

Книга американского нейроэндокринолога. Не знаю зачем в переводе в корне поменяли название — оригинальное гораздо лучше передает суть книги — Monkeyluv: And Other Essays on Our Lives as Animals. Сборник эссе, с обсуждением различных тем, слабо связанных между собой (разве что юмором автора).

Что важнее — гены или воспитание и среда? Действительно внешние признаки (рога у оленей, павлиньи хвосты и т.п.) говорят о лучших генах у их носителя или это просто трата кучи энергии в никуда? Почему во сне всё как во сне — и как отвечая на одни вопросы о работе нашего организма мы в итоге остаемся только со следующим уровнем вопросов? Почему так притягательны азартные игры — рассуждения на примере наблюдавшейся автором френдзоны у обезьян. Почему для нас так важны тела погибших? Как тело влияет на мозг и почему нам так трудно успокоиться после ссоры, когда мы уже завелись? Что ещё можно влиять на мозг — например мозговые паразиты, бррр (пример с токсоплазмой, заставляющей грызунов не бояться кошек впечатляет). Известно, что чтобы жить долго и не болеть — лучше быть богатым 🙂 но иногда это не так и некоторые болезни показывают обратную зависимость — но всегда ли это правда и существуют болезни богатых, или просто у бедных их не диагностируют? Как отличаются культуры пустынь и влажных лесов и как так вышло, что доминирующими культурами на планете стали именно культуры пустынь?

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

Eric Evans — Domain-Driven Design: Tackling Complexity in the Heart of Software

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

Книга состоит из 4х больших частей.

В первой автор рассуждает о важности общей модели предметной области — общей и для программистов и для представителей бизнеса. Сама мысль изложена и в What is domain driven design, но тут она подается подробнее, с примерами из жизни. Интересная мысль, что целостность модели и ее общий язык — это не только то о чем мы договорились в начале. Если в процессе работы мы нашли более удачные слова, точнее описывающие нашу область и лучше понятные бизнесу, то необходимо отразить это в том числе в коде. Необходим рефакторинг кода, для того чтобы используемый в нем язык продолжал совпадать с языком модели, чтобы не происходило постепенного расхождения.

Во второй — автор переходит от общих рассуждений о моделецентричности при разработке к конкретным предложениями как проектировать ПО так, чтобы в итоге оно отражало модель предметной области. Для этого сначала вводятся понятия entity, value object, service описывающие различные составные части системы. Затем — aggregate, группирующий их в тесно связанные с точки зрения бизнеса блоки, factory — для создания сущностей и агрегатов, repository — для внешнего хранения сущностей и восстановления их из внешнего хранилища в память. В конце главы приводится пример проектирования системы управления перевозкой товаров на основе предлагаемых принципов из этих кирпичиков.
С одной стороны здесь не описывается ничего революционного, но с другой методично и с примерами показывается как может быть упрощена или наоборот усложнена система, если глубже вникнуть в бизнес требования и отразить их при проектировании. Как влияет на дизайн правильное понимание, что в бизнес области является entity, а что просто value, т.е. определяется только своими свойствами и не требует отслеживания уникальности. Как упрощает систему замена двунаправленных связей однонаправленным, где это возможно. Как грамотное использование репозиториев может решать проблемы с конкретными изменениями (опять таки если бизнес требования позволяют это)

В третьей части автор обсуждает рефакторинг, как необходимый компонент поддержания соответствия кода модели, по мере ее изменения и усовершенствования. Начинает он с примера из жизни, когда вникнув глубже в доменную область, удалось создать более удачную её модель, что с одной стороны позволило упростить дальнейшую разработку, устранив недопонимания с бизнес-заказчиками, но с другой потребовало существенного переписывания системы под новую модель. После этого, ещё порассуждав о том, что модель постоянно улучшается и меняется — переходит к рассуждениям о гибком и в то же время понятном дизайне приложений. Сначала обсуждается, как лучше отражать бизнес-правила и ограничения в коде. Альтернативой вынесения сложной бизнес логики в уровень приложения предлагается создание классов-спецификаций, инкапсулирующих внутри себя проверку неких бизнес-правил, а возможно во взаимодействии с репозиториями и выборку объектов, удовлетворяющих спецификации.
Другими инструментами гибкого дизайна автор называет:
— интерфейсы, с понятными названиям как самих классов, так и методов, чтобы из самих их названий было понятно, что они делаютчистые функции
— операции над иммутабельными объектами
— операции над value objects, которые бы возвращали новые value objects

В четвертой части автор переходит к вопросам организации работы большой компании со сложным продуктом, над которым работает несколько команд. На примерах он показывает, какие проблемы могут возникнуть, когда команды работают в рамках своих моделей, но их границы четко не очерчены и одна команда может вносить изменения, нарушающие работу кода, поддерживаемого другой. Чтобы не допускать таких проблем предполагается концепция bounded contexts — четко очерченных границ моделей, с понятными местами их пересечения. Если это сделано — то, как минимум проблема обозначена и обозначены пересечения, по которым работа должна быть в какой-то степени совместной и надо принять решение как будет построена эта работа.
Автор рассматривает следующие способы взаимодействия команд, по степени уменьшения степени интеграции: continuous integration, shared kernel, upstream/downstream, anticorruption level, open host service, separate ways. Суть ясна из названий, разве что стоит пояснить что под anticorruption автор понимает набор фасадов/адаптеров, которые защищают нашу модель от «повреждения» неподходящей нам чужой моделью. Важная мысль при этом, что выбор модели взаимодействия — это чаще всего не техническое, а организационное решение и зависит прежде всего от размера команд, их взаимоотношений, их организационной подчинённости, общности их целей.

Но возвращаясь чуть назад, как разделить единую и ставшую слишком сложной и запутанной модель на отдельные bounded contexts, чтобы с одной стороны над ними могли работать независимые команды, а с другой — чтобы усилия наиболее сильных программистов (команд) были направлены на действительно важные вещи, а какие-то менее критичные могли бы быть сделаны силами джунов или вовсе отданы на аутсорс?
Для этого необходимо провести model distillation — анализ модели и выделение, что в ней является нашим core domain — тем, что мы на самом деле делаем, что составляет цель нашего продукта, чем он отличается от конкурентов. А что является generic / supporting domains — частями продукта, которые необходимы, но при этом могут быть такими же как у всех вокруг, решают задачи поддержки, не являются основными. Часто такими частями являются биллинг, поддержка, общие технические модели работы с сетью / датами и т.п.
Для упрощения основной модели полезно выделить generic subdomains в отдельные модули / команды, а возможно и отдать на аутсорс для ускорения разработки. Другим подходом может быть наоборот явное выделение в отдельный модуль / сервис в первую очередь core domain (автор называет этот подход segregated core), а уже потом распиливание остатка.

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

Team divisions that assume some developers are not smart enough to design are likely to fail because they underestimate the difficulty of application development. If those people are not smart enough to design, they shouldn’t be assigned to develop software. If they are smart enough, then the attempts to coddle them will only put up barriers between them and the tools they need

Оливер Сакс — Человек, который принял жену за шляпу

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

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

Но если эта история вызывает мысль «ничего себе как бывает», то последующие — ещё пронзительнее и сложнее:

Остаётся ли собой человек, потерявший из памяти 20 лет своей жизни и не помнящий больше последних нескольких часов?

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

Особенно впечатлила история пациента с синдромом Туретта

Что касается органической основы, синдром Туретта и «туреттизм» любого другого происхождения … можно сравнить с редкими, гиперкинетическими формами летаргического энцефалита, а также с перевозбужденными состояниями при приеме L-дофы. По-видимому, во всех этих случаях в мозгу возникает избыток стимулирующих трансмиттеров, в особенности дофамина. Отсюда следует, что, регулируя дофамин, можно влиять на показатели возбуждения. Например, для того чтобы снять апатию у пациентов с болезнью Паркинсона, уровень дофамина следует повысить (именно так, при помощи L-дофы, мне удалось «разбудить» постэнцефалитных пациентов, что описано в книге «Пробуждения»). Неистовые же туреттики нуждаются в понижении уровня дофамина, и для этого используются его нейтрализаторы, такие как галоперидол.

Нервная система работает не так, как в норме — но что есть норма? Может ли существовать человечество, в котором нормальной была бы именно такая работа нервной системы? И вообще, если говорить про то, как по разному может она работать — где грань на шкале от нормы к болезни — кофе, витамины, ноотропы и далее к картинке с Карлсоном ( https://www.meme-arsenal.com/memes/108742e654416037860620649b119726.jpg ).

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

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

и он в итоге даже жалеет о результатах лечения

В течение рабочей недели, принимая лекарство, Рэй остается, по его собственным словам, «солидным, трезвым дядей». Движения и мысли его неторопливы и обдуманны, без следа прежней порывистости, но и без каких-либо бурных импровизаций и блестящих идей. Даже сны его стали другими. «Сплошное исполнение желаний, – говорит он сам, – без всяких штучек и выкрутасов Туретта». Он не так колюч и находчив, из него не бьют больше ключом тикозные остроты и остроумные тики. В прошлом все его победы в настольном теннисе и в других играх, в прошлом и удовольствие от них. Рэй утратил инстинкт «побить и добить» соперника, а вместе с ним и склонность к соревнованию и игре. Исчезла внезапность «легкомысленных» ударов, всех застававших врасплох; пропали непристойности, грубая дерзость, вспыльчивость.