Файл: Роберт мартин.pdf

Глава 4. Методы взаимодействия внутри команды
160
Шел 1995 год . На следующий день была запланирована к выходу из печати моя первая книга, и мне кровь из носу нужно было пред- ставить корректуру . Было 6 утра, у меня уже все было на руках .
Надо было просто залить файл на FTP-сервер издателя .
Но потом я волей случая наткнулся на способ вдвое увеличить разрешение сотен графиков в книге . Джим и Дженнифер помогали мне с подготовкой корректуры, и мы уже были готовы запустить
FTP-клиент . И тут я показываю им пример графика с увеличенным разрешением .
Мы посмотрели друг на друга и тяжело вздохнули . Джим сказал:
«Нужно все переделывать» . Это был не вопрос . Это была конста- тация факта . Все трое посмотрели друг на друга, потом на часы .
Потом снова друг на друга . А потом пошли горбатиться .
Но когда мы все сделали, посиделки закончились . Мы отправили книгу . И пошли спать .
Сон
В жизни программиста достаточный сон ценится на вес золота .
Мне хватает семи часов . Могу выдержать день-два, если спать по шесть часов . Если сна немного меньше, то производительность резко падает . Определите, сколько часов вам нужно, чтобы физи- чески выспаться, и выставьте этому времени наибольший прио- ритет . Поспать в эти часы оправданно более чем полностью . По своему опыту могу сказать, что один час недосыпа стоит мне двух часов рабочего времени днем . Если не поспал еще час, то смело вычеркивайте еще четыре часа полезной работы . И, разумеется, если недосып составит три часа, то можно забыть о какой-либо плодотворной работе вообще .

Коллективное владение
161
КОЛЛЕКТИВНОЕ ВЛАДЕНИЕ
В проекте, где применяется Agile, у кода нет владельца . Код — это коллективное владение команды как единого целого . Любой член команды в любое время имеет право проверить и усовершенство- вать любой модуль проекта . Команда коллективно располагает всем кодом .
Я усвоил этот метод еще в начале своей карьеры, когда работал в Teradyne . Мы работали над большой системой, состоявшей из пятидесяти тысяч строк кода, разделенного на несколько сотен мо- дулей . Но никто из команды не владел ни одним из этих модулей .
Мы все стремились учиться и совершенствовать эти модули . Да, некоторые из нас лучше знали некоторые части кода, нежели осталь- ные, но мы старались поделиться знаниями, а не копить их в себе .
Эта система стала одной из первейших распределенных сетей . Она состояла из центрального компьютера, который сообщался с не- сколькими десятками периферийных по всей стране . Компьютеры соединялись по модему с пропускной способностью более 300 бод .
Программисты не делились на тех, кто работал над ПО для цен- трального, а кто — для периферийных компьютеров . Все работали над программным обеспечением для тех и других .
У центрального компьютера и периферийных были совершенно разные архитектуры . Один был такой же, как PDP-8, только его слово составляло 18 бит . У него было 256 килобайт оперативной памяти, а данные загружались с кассеты с магнитной лентой . Дру- гой имел 8-битный микропроцессор 8085 с 32 килобайтами опера- тивной памяти и 32 килобайтами постоянной памяти .
Мы писали программы на ассемблере . Ассемблер для каждой из двух машин значительно отличался, среды разработки также были

Глава 4. Методы взаимодействия внутри команды
162
очень разными . Мы все работали над обеими машинами в равных условиях .
Коллективное владение не означает того, что у вас не может быть специализации . Поскольку системы становятся все сложнее, от специализации никуда не уйти . Существуют системы, которые просто нельзя понять как полностью, так и в мелочах .
Однако даже если вы специализируетесь в чем-то, нужно уметь обобщать . Разделите работу между вашей специализацией и дру- гими областями кода . Поддерживайте умение работать не только в рамках специализации .
Когда в команде применяется метод коллективного владения, зна- ния распространяются среди всех участников команды . Все члены команды начинают лучше понимать границы между модулями и принципы работы системы в целом . Это существенно повышает способность команды взаимодействовать и принимать решения .
За свой достаточно долгий карьерный путь я видел, как некото- рые компании делали наоборот . У каждого программиста были свои модули, и никто больше не имел права к ним прикасаться .
Такие команды были чрезвычайно разлажены, в них царило непо- нимание, и все сваливали вину друг на друга . Работа над модулем прекращалась, когда автор был не в офисе . Никто даже и не думал браться за чужой участок работы .
Секретные материалы
Компания X, производившая принтеры высокого класса, была од- ним из таких печальных случаев . В 1990-х компания переходила от преимущественно аппаратных решений к интеграции аппаратных

Коллективное владение
163
и программных средств . Им пришло осознание, что можно значи- тельно сократить расходы на производство, если для управления оборудованием внутри компании применять программное обе- спечение .
Однако привычка производить аппаратное обеспечение укорени- лась слишком глубоко, поэтому разделение труда при разработке
ПО осуществили с таким же подходом . При разработке аппарат- ного обеспечения каждая команда занималась своим устройством: податчик, принтер, стопоукладчик, сшиватель и так далее . ПО для устройств писали те же, кто занимался их производством . Одна ко- манда писала программы для податчиков, другая — для сшивателя, и так же и для других устройств .
В компании X политический вес работника зависел от устрой- ства, над которым он работал . Поскольку X была компанией, выпускающей принтеры, работа над ними была самой почетной .
Чтобы работать над принтерами, инженерам приходилось про- двигаться по службе . С теми, кто занимался сшивателями, никак не считались .
Эта система политических рангов передалась командам, писавшим программное обеспечение . Разработчики, писавшие код для стопо- укладчиков, были политически бессильны, но когда на собрании начинал говорить разработчик, работавший над принтером, все внимательно его слушали . Из-за такого политического разделе- ния никто не делился кодом . Ключом к политическому влиянию команды, занимавшейся принтерами, был код . Поэтому код, напи- санный для принтеров, находился за семью замками . Никто, кроме членов команды, не мог даже на него взглянуть .
Проблем от этого было море . Во взаимодействии возникают оче- видные трудности, если невозможно проверить используемый

Глава 4. Методы взаимодействия внутри команды
164
код . В таком случае неизбежно перекладывание ответственности и подставы .
Но хуже всего было несусветное и смехотворное дублирование .
Оказывается, что ПО для податчика, принтера, стопоукладчика и сшивателя не особо-то и отличается . У всех этих устройств есть моторчики, реле, соленоиды и муфты, расположенные на внешних входах и внутренних датчиках . В основном внутреннее строение этих модулей было одинаковым . А из-за всей этой борьбы за по- литическое влияние каждой команде приходилось изобретать свое собственное колесо .
Что еще важнее, само намерение разделить команды разработчи- ков программного обеспечения по устройствам противоречило здравому смыслу . Нет смысла разрабатывать ПО для контроллера податчика независимо от контроллера принтера .
Напрасная трата трудовых ресурсов, не говоря уже о страхе, враж- дебности и конкуренции, вели к очень нездоровой атмосфере .
Я считаю, что атмосфера была причиной, по крайней мере отчасти, последующего крушения этой компании .
НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ
В первые дни существования Agile метод «непрерывная инте- грация» означал, что разработчики отмечали изменения в своем исходном коде и объединяли их с основной веткой каждые «пару часов»
1
. Все модульные и приемочные тесты проходили успешно .
Не оставалось веток, которые бы не были объединены . Все не-
1
Beck K . Extreme Programming Explained: Embrace Change . Boston,
Massachusetts: Addison-Wesley, 2000 . P . 97 .

Непрерывная интеграция
165
нужные при развертывании изменения отключались с помощью тумблера .
В 2000 году на одном из уроков на курсах XP Immersion один студент угодил в классическую ловушку . Эти уроки были очень насыщенны . Мы сократили циклы так, что итерации составляли всего один день . Цикл непрерывной интеграции составлял лишь от четверти до получаса .
Один студент работал в команде из шести разработчиков, пятеро из которых отмечали изменения чаще, чем он . Непонятно почему, он был без пары . И вышло так, что он не выполнял слияние кода более часа .
Когда он наконец решил отметить изменения и выполнить сли- яние кода, он увидел, что накопилось столько изменений, вне- сенных другими студентами, что ему пришлось хорошенько по- возиться, чтобы объединить код . Пока он копался и выполнял слияние, остальные программисты продолжали отмечать из- менения каждые 15 минут . И когда он наконец разобрался и по- пробовал отметить изменения в своем коде, то увидел, что снова попал впросак .
Он так расстроился, что встал посреди кабинета и громко про- возгласил: «Ваше экстремальное программирование — полная ерунда!» После этого он вылетел из класса и направился в бар гостиницы .
И тут случилось невероятное . Программист, с которым он отка- зался работать в паре, пошел вслед, чтобы побеседовать с ним . Две пары других программистов перераспределили свою работу, завер- шили слияние и вернули проект в колею . Через полчаса студент притих, вернулся в кабинет и, извинившись, продолжил работу,

Глава 4. Методы взаимодействия внутри команды
166
в том числе стал работать в паре . Впоследствии он стал ярым сто- ронником методологии гибкой разработки Agile .
Мораль: метод «непрерывная интеграция» работает только тогда, когда интеграция действительно непрерывна .
А вот и непрерывная сборка
В 2001-м Thought Works значительно изменили положение дел .
Они создали CruiseControl
1
, первое средство непрерывной сборки .
Я помню, как в 2001-м на XP Immersion Майк Ту
2
читал ночную лекцию об этом . Не сохранилось записи этой лекции, но история была примерно таковой:
CruiseControl позволяет сократить время отметки изменений
до нескольких минут. Даже самые мелкие изменения быстро
вносятся в основную линию. CruiseControl отслеживает ра-
боту систем управления версиями и создает сборку каждый
раз, когда отмечено какое-либо изменение. При создании сборки
CruiseControl запускает большинство автоматизированных те-
стов, а затем отправляет электронные письма с итогами всем
членам команды.
«Боб сломал сборку».
Мы ввели простое правило в отношении тех, кто ломал сборку.
В тот несчастный день, когда вас угораздило сломать сборку,
вы должны надеть футболку с надписью «Я сломал сборку».
Которую никто никогда не стирал.
1
https://ru.wikipedia.org/wiki/CruiseControl.
2
http://wiki.c2.com/?MikeTwo.

Непрерывная интеграция
167
С тех пор было создано много других средств непрерывной сборки .
К ним относятся инструменты наподобие Jenkins (или Hudson?),
Bamboo и TeamCity . С помощью этих инструментов можно в наи- большей степени сократить время между слияниями . «Пара часов», о которой изначально говорил Кент Бек, превратилась в «несколько минут» . «Непрерывная интеграция» стала «непрерывной отметкой» .
Дисциплина при непрерывной сборке
При непрерывной сборке ничего не должно ломаться . Потому что программист, который не хочет надевать грязную футболку, как в случае с Майком Ту, проводит приемочное и модульное тестиро- вание до того, как отметить изменения в коде . Если сборка слома- лась (как так можно?), значит, случилось что-то очень странное .
Майк Ту рассматривал в своей лекции и этот вопрос . Он рассказал о календаре, висевшем на видном месте на стене помещения, где работала команда . Календарь выбирали большой, чтобы каждый день в году располагался в своей ячейке .
Если сборка не удавалась хоть раз, то этот день отмечали крас- ной точкой . Если сборка проходила успешно, этот день отмечали зеленой точкой . Такой простой визуализации было достаточно, чтобы в течение месяца или двух превратить календарь, состоящий в основном из красных точек, в календарь, состоящий в основном из зеленых .
Внимание!
Напомню: при непрерывной сборке ничего не должно ломаться .
Сломанная сборка — это событие, означающее, что нужно макси- мальное внимание . Я хочу, чтобы заорали сирены . Я хочу видеть

Глава 4. Методы взаимодействия внутри команды
168
мерцание красного прожектора в кабинете исполнительного дирек- тора . Сломанная сборка — это полный трындец . Я хочу, чтобы все программисты бросили свои дела и сплотились вокруг сборки, и та снова прошла успешно . Фраза «при сборке ничего не ломается» должна стоять на повторе в голове каждого члена команды .
Стоимость обмана
Бывали случаи, когда команда, игнорируя неисправности, под дав- лением дедлайна продолжала непрерывную сборку . Это попытка самоубийства . В результате все устают от шквала писем о наруше- ниях, приходящих от сервера непрерывной сборки . Поэтому раз- работчики просто убирают тесты, которые не получается пройти, обещая вернуться к проблемам позже и решить их .
Кто бы сомневался: теперь сервер непрерывной сборки снова сооб- щает, что сборка прошла успешно . Все расслабляются . Сборка про- ходит тесты . И все благополучно забывают о куче непройденных тестов, которые убрали в сторонку, пообещав решить проблемы
«позже» . В итоге происходит развертывание сломанной системы .
СТЕНДАП-МИТИНГ
На протяжении многих лет было много путаницы в понятиях еже-
дневный скрам и стендап-митинг . Позвольте мне разъяснить .
Вот вам правда о стендап-митингах:
z
Такие встречи не обязательны . Многие команды прекрасно обходятся без них .
z
Они могут проводиться реже, чем раз в день . Подберите график, который считаете подходящим .

Стендап-митинг
169
z
Они должны занимать примерно 10 минут даже у больших команд .
z
Встреча проводится по простому сценарию .
Смысл этого мероприятия в том, что каждый член команды встает
1
в круг и отвечает на три вопроса:
1 . Что я делал после прошлой встречи?
2 . Что я буду делать до следующей встречи?
3 . Что мне нужно сделать?
И все . Никаких обсуждений . Никакого позерства . Никаких про- странных объяснений . Никаких грустей и печалей . Никаких жалоб и обвинений кого угодно на свете .
У каждого есть полминуты на то, чтобы ответить на три вопроса .
Потом встреча заканчивается, и все идут работать дальше . Все, аллес . Финита . Ферштейн?
Наверное, еще лучше стендап-митинги описаны на «вики» Уорда: http://wiki.c2.com/?StandUp
Meeting
Курицы и свиньи?
Если готовить омлет с ветчиной, то степень участия в нем двух животных будет разной . Курица для омлета просто снесет яйцо, а вот свинье придется пожертвовать собой для ветчины полностью .
Суть в том, что только разработчикам разрешается говорить на стендап-митинге . Руководство и иже с ними могут послушать, но никак не вмешиваться .
1
Потому они и называются стендап-митинги, то есть «стоя» .