Рецензии на книги издательства «Addison Wesley»

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

Новых методик появлялось много, какие-то умирали, какие-то путём проб и ошибок развивались и находили применение. Среди них и Scrum of Scrums, и LeSS, и SAFe, хотя существуют и многие другие. Нельзя сказать, какая из них очевидно лучшая, но SAFe в последнее время заполучил множество адептов, и по статистике вроде как опережает остальные на данный момент. В какой-то момент я не мог пройти мимо, потому что в любой методологии всегда есть множество плюсов. Даже если конкретно для тебя или твоей команды она не прижилась на 100%, всегда можно позаимствовать какие-то элементы, внедрить сначала их, затем следующие… и так далее, пока всё это действительно повышает качество, прозрачность и, разумеется, конечный результат.

SAFe расшифровывается как Scaled Agile Framework и изначально был создан Дином Леффингуелом (Dean Leffingwell) как база гибких пракик для использования agile-методологий в крупных командах (от 50 человек и выше, официально называют цифру в 20 тысяч сотрудников, но никто не запретит использовать эти подходы и при больших цифрах).

Собственно, именно как грамотно созданная база знаний фреймворк и существует на официальном сайте https://www.scaledagileframework.com/. Все статьи можно просто там и прочитать. Однако мне был интересен структурированный подход, как его видят авторы фреймворка, как они хотят донести его, «продать». Да и читать в виде книги мне всегда удобнее. Поэтому я своё плотное знакомство (а поверхностно разные куски я знал и ранее) решил начать именно с книги. Я взял «SAFe 4.0», но поскольку фрейворк активно развивается, уже успела появиться версия 4.5, а затем и 5.0 (с 2020 года). Но новые версии не вносят кардинальных изменений, а лишь уточняют, дорабатывают и улучшают уже имееющееся. Поэтому для общего понимания 4.0 не сильно уступает 4.5 и 5.0 (тем более, что детали всегда можно на сайте посмотреть, где всё актуально).

Описание SAFe — это не только описание подходов, но ещё и принципов, лежащих в его основе. И в книге этому уделено особое внимание, именно с этого начинается «подготовка» будущих евангелистов нового направления: каково мировоззрение Lean-Agile, что такое быть лидером этого направления, и каковы собственно принципы SAFe, на которых строятся все подходы.

Сам же фрейморк подразделяется на четыре типа. Основные подходы покрываются при помощи Essential SAFe, для более крупных проектов — Large Solution SAFe, для управления портфолио — Portfolio SAFe, ну и Full SAFe — чтобы rule them all. В книге шаг за шагом разбираются все элементы самого крупного Full Safe, но начиная от базовых из Essential и плавно двигаясь всё дальше в лес.

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

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

Сам же фреймворк я бы разделил на две части:

Инструменты
Организационные подходы

В рамках SAFe вводится ряд инструментов, которые не всегда придуманы именно под SAFe, но активно в нём применяются. И инструменты очень здравые и полезные, многие из которых прекрасно находят своё применение даже там, где SAFe не применяют. Например, одним из таких является подход оценки задач WSJF. Он прекрасно где может использоваться как в оригинальном виде, так и в адаптации под разные типы задач.

Организационные же подходы, на мой взгляд, во многом являются вполне логичным развитием иных Agile-практик именно в масштабировании. И тут никакой «магии» нет, до многого можно дойти своим умом, однако авторы SAFe сумели это грамотно собрать вместе и представить в виде расширенной методологии. И как и в Scrum, тут есть свои определённые роли. При этом зачастую это просто расширенные версии своих аналогов в более мелком Scrum: не Product Owner, а целый Product Management, не Scrum Master, а целый Release Train Engineer (RTE), и так далее.

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

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

А когда доходишь до последней части книги, которая вроде должна быть самой полезной и интересной — про внедрение в реальных условиях, становится даже более чем грустно, потому что для меня это выглядело как мутное словоблудие с очень обильной рекламой собтвенных платных сертификаций и лицензирования. Типа «ой, всё сложно, платите нам много штук баксов, и мы вам всё разжуём». Хорошая методология должна продавать себя, а тут — «купите наших тренеров и они вас будут долго и дорого учить, чтобы потом ты мог долго и дорого учить других» (как тут не вспомнить про пирамиды?)

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

Книга рассказывает как TDD помогает формировать архитектуру приложений; причем TDD с моками и end-to-end тестами (извне вовнутрь). Сначала авторы формируют базовые принципы тестирования и архитектуры, а затем на примере последовательно их внедряют. В качестве примера они создают GUI приложение на джаве (книга будет полезна не только джавистам, потому что принципы универсальны).

Эта книга часто упоминается в разговорах о гексагональной архитектуре. Однако в книге эта архитектура почти не упоминается; авторы не используют термины оттуда (да и "порты", почему-то, выносят из домена). И лишь говорят, что в их примере получилась архитектура, похожая на гексагональную (ну и в целом, гексагоналка соответствует их принципам). Причем авторы отмечают, что такая архитектура получилась почти автоматически, лишь последовательно применяя указанные ими принципы.

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

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

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

Что касается данной книги, то она скорее теоритическая - посвящает в концепцию М3.0.

Концепция включает в себя такие элементы:

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

Вообщем-то многие описанные вещи в духе модного нынче Agile. Есть мысли свежие. Есть мысли уже известные.

Книга на слуху, поэтому было интересно с ней ознакомиться.

P.S. Интересно, каким будет менеджмент 4.0 ? :)

Название «Poodr» в этом случае хорошо отражает суть книги.

В ней мало «воды» и много полезной информации. Несмотря на небольшой объём, даются достаточно подробные объяснения, и язык несложный. Должна подойти и новичкам (не совсем зелёным), и опытным разработчкам.

В начале книги рассказывается о том, что такое дизайн и зачем он нужен, как принимать решения по дизайну в постоянно изменяющемся мире и не сойти с ума.
(Спойлер: нужно проектировать так, чтобы легче и дешевле было вносить изменения в приложение, а не так, чтобы было «кравиво» и «как в книжках пишут»; особенно полезно об этом задуматься, когда нужно принять решение: выбросить всё и переписать с нуля или работать с тем, что есть.)

В последующих главах рассматриваются разные принципы ООП, в качестве примеров кода используется приложение для фирмы, занимающейся организацией велопоходов, постоянно переживающее изменения, дополнения и рефакторинг.
Вот некоторые примеры тем из книги:
- принцип единственной ответственности (Single Responsibility Principle)
- слабая связанность (Louse Coupling)
- изоляция зависимостей
- внедрение зависимости (Dependency Injection)
- утиная типизация (Duck Typing)
- закон Деметры (the Law of Demeter)
- разработка оптимальных интерфейсов, в т.ч. рассматривается то, как реализуются интерфейсы в других языках, что позволяет шире посмотреть на объектно-ориентированное программирование, не застревать в руби-мире (для таких, как я)
- наследование
- принцип подстановки Барбары Лисков (Liskov substitution principle)
- шаблонный метод (Template method pattern)
- композиция, агрегирование, выбор между композицией и наследованием

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

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

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

Новая книжка от автора STL, посвященная, внезапно, обобщенному программированию.

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

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

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

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

Прочитал я эту книгу, и не могу себе ответить на один вопрос -- для кого же она была написана? Такое ощущение, что автор решил задокументировать все, что знает про ООП, и как могут использоваться объекты. Первая половина книги будет казаться невероятно затянутой и излишне подробной тем, кому будет интересен конец книги. А те, кому хорошо подойдет начало, мало что поймут в конце. Буду советовать ее читать студентам, начинающим изучать ООП, выкинув главы этак с 10 по 14. Вообще от книги с таким названием я ожидал чего-то более фундаментального.

6/10

When I first opened this book I thought I’d never be able to manage it. More than 600 pages of technical English! Nevertheless, I had no difficulty reading it - the book has a very readable structure.

What

“Experiences of Test Automation” by Dorothy Graham & Mark Fewster is built of 28 case studies from different experts in test automation, with one case study per one chapter. It means once read, the reader will see how the process was set up in twenty eight projects, both successful and not. The book also contains some pretty text markup elements such as the highlighting of good points, lessons and tips. Each case study shows how the automation issues were solved in a variety of different ways. It’s a worthwhile thing to learn real-life experience of automation experts from all over the world.

Why

Reading the book you’ll learn:

* How the automation is set up on the 23-year old still breathing project
* How medical devices are tested
* What is the most common mistake made when choosing the wrong automation tool
* What popular applications are tested with 70,000 tests against 5,000 machines
* What it means to “eat your own dog food”
* How mission-critical systems for the U.S. Department of Defense are tested
* ... and dozens of useful lessons and tips from 28 projects

Who

I would recommend this book to all senior-level professionals involved in a software development process. The book seems to be most helpful for test automation engineers from a middle level of skill and higher.

Good luck with your automated tests!