Отзывы на книги автора «Шэйн Уорден»

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

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

Ваш код сплоченный (cohesive), когда физически находится близко друг к другу в исходных файлах. Например, если бы функция преобразования валюты в строку находилась в классе Currency вместе с основным типом данных, то они были бы высокосплоченными. Если бы функция была в модуле утилиты в совершенно другом каталоге, то они бы имели низкую сплоченность. (Глава 14, страница 519)

Это ошибка. Код сплочен (cohesive) тогда, когда имеет общую ответственность, занимается общей задачей. Если сплоченный код физически находится далеко друг от друга, например в разных модулях, то между этими модулями возникает сильная связанность (coupling). Задача хорошего дизайна уменьшить связанность между модулями, размещая сплоченный код близко друг к другу. Так что, если код физически близко друг к другу, то его сплоченность является лишь следствием хорошего дизайна. Возвращаясь к примеру автора, если бы функция преобразования валюты была бы в одном классе, а сама валюта была бы описана в другом классе, то эти классы имели бы высокую связанность (coupling), и задачей хорошего дизайна было бы её уменьшение.

Зависимости от времени (time dependencies) возникают, когда методы класса должны вызываться в определенном порядке. Полусырые объекты (half-baked objects) — особый случай зависимости от времени: сначала они должны быть созданы, потом инициализированы вызовом метода, потом использованы. (Глава 14, страница 532)

Это ошибка. То, что описал автор, называется зависимостью от порядка, а не от времени. Согласно определению Пейдж-Джонса зависимость от порядка вызова методов называется коннасценцией исполнения (Connascence of Execution), а зависимость от времени называется коннасценцией синхронности (Connascence of Timing). Зависимость от времени возникает, например, при состоянии гонки, когда два и более программных потока, выполняющихся одновременно, оказывают влияние на результат совместной операции.

У меня есть друг, который работает в большой широко известной компании. Благодаря архитектуре обмена данными «сверху вниз» его команда из трех программистов поддерживает 21 отдельный сервис — по одному для каждого элемента, которые они контролируют. Двадцать один! Мы потратили некоторое время на то, чтобы подумать, как можно упростить код его команды. Изначально от его команды требовали, чтобы они держали каждый сервис в отдельном репозитории git. Команда получила разрешение объединить сервисы в монорепозиторий. Это позволило команде устранить дублирования кода сериализации/десериализации и значительно облегчить рефакторинги. До этого одно изменение могло приводить к 16 отдельным подтверждениям (коммитам) в 16 репозиториях. Теперь требуется только одно. (Глава 15, страница 565)

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

Заказчики в команде (члены команды, обладающие навыками, позволяющими представлять интересы покупателей, пользователей и бизнес-стейкхолдеров) должны отвечать на вопросы команды о требованиях. Они выступают в качестве «изменяемого документа с требованиями». Они общаются с остальными членами команды с помощью разговоров, примеров и рисунков на доске. Это более быстрый и менее подверженный ошибкам способ, чем поддержание документа в актуальном состоянии, особенно для сложных тем. Когда разработчикам нужно понять требование, они просто спрашивают. (Глава 8, страница 246)

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

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

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

Чтобы уменьшить количество документации, вам необходимо сначала заменить ее другими формами общения. Именно поэтому Agile-команды имеют заказчиков в команде — они заменяют документы с требованиями. (Глава 8, страница 251)

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

Лучшие модульные тесты (повторюсь: по моему мнению) — узкие коммуникативные. Они узкие потому, что тест проверяет только тестируемый класс или модуль. Они коммуникативные потому, что тестируемый код все еще вызывает свои реальные зависимости. (Глава 13, страница 481)

Если тестируемый код все еще вызывает свои реальные зависимости, то это уже не модульный тест, а интеграционный.

Не допускайте использования null как параметра, если он не имеет явно определенной семантики. Не возвращайте null в качестве указателя ошибки, лучше выдайте исключение. Когда вы получаете null там, где не ожидаете, выдайте исключение. (Глава 14, страница 532)

Я полностью согласен с этими правилами, однако сам автор умудряется их нарушать.

Я хотел, чтобы моя новая конечная точка входа в систему имела коммуникативные тесты. Чтобы это произошло, класс Auth0Client должен был допускать значение null, а для этого мне было нужно, чтобы данное значение допускал класс HttpsRestClient. (Глава 14, страница 528)

Команды Agile работают наилучшим образом, когда состоят из специалистов широкого профиля... Agile-командам нужны такие специалисты, чтобы предотвращать образование узких мест в рабочем процессе. (Глава 7, страница 117)

Представьте команду с двумя фронтенд- и двумя бэкенд-разработчиками. Иногда бывает больше работы по фронтенду, и тогда разработчики бэкенда бездельничают... Команды, в составе которых есть специалисты широкого профиля, избегают этого. Когда много работы по фронтенду, соответствующие специалисты берут инициативу в свои руки, а бэкенд-разработчики им помогают. (Глава 7, страница 118)

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

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

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

Выходных?

Когда вы узнаете о баге, исправляйте его сразу, а потом разбирайтесь, как предотвратить появление этого типа багов в будущем. Вам не удастся прийти к этому за одну ночь. (Глава 16, страница 578)

Ночь?

Мы коллективно решаем, достаточно ли у нас резерва времени, чтобы исправить баг и при этом исполнить остальные наши обязательства. Если достаточно, то мы создаем задачи для бага, добавляем их в свой план, и люди добровольно берутся решать эти задачи, как обычно. (Глава 16, страница 576)

Добровольно?

А вам не кажется странным, что автор употребил слово "добровольно"? Люди добровольно берутся решать эти задачи. Почему люди не просто берутся решать эти задачи, а именно добровольно? Это похоже на оговорку по Фрейду, случайное употребление слова, которое неожиданно раскрывает истинные, но скрытые или подавленные мысли человека. Видимо, люди не очень то добровольно желают ночами заниматься исправлением багов, и брать двухнедельный отпуск, чтобы выполнить рефакторинг дизайна.