«Боб сломал сборку».
Мы ввели простое правило в отношении тех, кто ломал сборку. В тот несчастный день, когда вас угораздило сломать сборку, вы должны надеть футболку с надписью «Я сломал сборку». Которую никто никогда не стирал.
С тех пор было создано много других средств непрерывной сборки. К ним относятся инструменты наподобие Jenkins (или Hudson?), Bamboo и TeamCity. С помощью этих инструментов можно в наибольшей степени сократить время между слияниями. «Пара часов», о которой изначально говорил Кент Бек, превратилась в «несколько минут». «Непрерывная интеграция» стала «непрерывной отметкой».
Дисциплина при непрерывной сборке
При непрерывной сборке ничего не должно ломаться. Потому что программист, который не хочет надевать грязную футболку, как в случае с Майком Ту, проводит приемочное и модульное тестирование до того, как отметить изменения в коде. Если сборка сломалась (как так можно?), значит, случилось что-то очень странное.
Майк Ту рассматривал в своей лекции и этот вопрос. Он рассказал о календаре, висевшем на видном месте на стене помещения, где работала команда. Календарь выбирали большой, чтобы каждый день в году располагался в своей ячейке.
Если сборка не удавалась хоть раз, то этот день отмечали красной точкой. Если сборка проходила успешно, этот день отмечали зеленой точкой. Такой простой визуализации было достаточно, чтобы в течение месяца или двух превратить календарь, состоящий в основном из красных точек, в календарь, состоящий в основном из зеленых.
Внимание!
Напомню: при непрерывной сборке ничего не должно ломаться. Сломанная сборка — это событие, означающее, что нужно максимальное внимание. Я хочу, чтобы заорали сирены. Я хочу видеть мерцание красного прожектора в кабинете исполнительного директора. Сломанная сборка — это полный трындец. Я хочу, чтобы все программисты бросили свои дела и сплотились вокруг сборки, и та снова прошла успешно. Фраза «при сборке ничего не ломается» должна стоять на повторе в голове каждого члена команды.
Стоимость обмана
Бывали случаи, когда команда, игнорируя неисправности, под давлением дедлайна продолжала непрерывную сборку. Это попытка самоубийства. В результате все устают от шквала писем о нарушениях, приходящих от сервера непрерывной сборки. Поэтому разработчики просто убирают тесты, которые не получается пройти, обещая вернуться к проблемам позже и решить их.
Кто бы сомневался: теперь сервер непрерывной сборки снова сообщает, что сборка прошла успешно. Все расслабляются. Сборка проходит тесты. И все благополучно забывают о куче непройденных тестов, которые убрали в сторонку, пообещав решить проблемы «позже». В итоге происходит развертывание сломанной системы.
Стендап-митинг
На протяжении многих лет было много путаницы в понятиях ежедневный скрам и стендап-митинг. Позвольте мне разъяснить.
Вот вам правда о стендап-митингах:
• Такие встречи не обязательны. Многие команды прекрасно обходятся без них.
• Они могут проводиться реже, чем раз в день. Подберите график, который считаете подходящим.
• Они должны занимать примерно 10 минут даже у больших команд.
• Встреча проводится по простому сценарию.
Смысл этого мероприятия в том, что каждый член команды встает[50] в круг и отвечает на три вопроса:
1. Что я делал после прошлой встречи?
2. Что я буду делать до следующей встречи?
3. Что мне нужно сделать?
И все. Никаких обсуждений. Никакого позерства. Никаких пространных объяснений. Никаких грустей и печалей. Никаких жалоб и обвинений кого угодно на свете.
У каждого есть полминуты на то, чтобы ответить на три вопроса. Потом встреча заканчивается, и все идут работать дальше. Все, аллес. Финита. Ферштейн?
Наверное, еще лучше стендап-митинги описаны на «вики» Уорда: http://wiki.c2.com/?StandUpMeeting.
Курицы и свиньи?
Если готовить омлет с ветчиной, то степень участия в нем двух животных будет разной. Курица для омлета просто снесет яйцо, а вот свинье придется пожертвовать собой для ветчины полностью. Суть в том, что только разработчикам разрешается говорить на стендап-митинге. Руководство и иже с ними могут послушать, но никак не вмешиваться.
Как по мне, без разницы, кто говорит, главное, чтобы встреча проводилась в формате трех вопросов, а собрание длилось около 10 минут.
Красавчик
Мне понравилось одно изменение — это добавить дополнительный четвертый вопрос.
• Кто у нас сегодня красавчик?
Это быстрое выражение признательности за помощь вам или за то, что этот человек, по вашему мнению, заслуживает похвалы за свой вклад.
Заключение
Agile — это набор принципов, методов и дисциплин, которые помогают небольшим командам разработчиков выполнять небольшие проекты. В этой главе приведены методы, которые помогают небольшим коллективам взаимодействовать как настоящие команды. Они помогают командам найти общий язык для взаимодействия, а также дают понимание того, чего ожидать членам команды от других в отношении друг друга и выполняемого проекта.
Глава 5. Технические методы
Методы этой главы предлагают полный отход от тех, что господствовали среди большинства программистов на протяжении 1970-х годов. Раньше предлагался набор осмысленных ритуалов, проводимых периодично — ежеминутно и ежесекундно, которые большинство программистов изначально считают чушью. Поэтому многие программисты пробовали применять Agile, исключив эти методы. Однако у них ничего не получилось, потому что эти методы как раз лежат в основе Agile. Без разработки через тестирование, рефакторинга, простой структуры проекта и, да-да, даже парного программирования Agile становится бесполезным жалким подобием того, чем должен быть.
Разработка через тестирование
Разработка через тестирование — это сложная и глубокая тема для обсуждения, и чтобы ее как следует раскрыть, понадобится целая книга. В этой главе приведен лишь общий обзор, который больше сосредоточен на обосновании и объяснении, чем на глубоких технических сторонах метода. В частности, в этой главе вы не найдете никакого кода.
Профессия программиста уникальна. Мы создаем огромные документы, написанные загадочными техническими символами. Каждый символ такого документа должен быть правильным, иначе может произойти что-то действительно страшное. Один неверный символ повлечет за собой потери больших средств или жизни. Разве есть другие такие профессии?
Бухгалтерский учет. Бухгалтеры также создают огромные документы, исписанные загадочными техническими символами. Каждый символ такого документа должен быть правильным, в противном случае это может стоить потери больших средств или жизни. Как бухгалтеры проверяют, чтобы каждый символ был правильным?
Двойная запись
У бухгалтеров есть инструмент, который появился еще тысячу лет назад. Это двойная запись[51]. Каждая операция, которую они проводят, заносится в книгу дважды: один раз как кредит в активном счете и еще раз, в дополнение, как дебет в пассивном счете. Затем эти счета сводят в единый документ, балансовый отчет, где из суммы финансовых активов вычитается сумма долговых обязательств и долей собственников. Бухгалтер должен выйти в ноль. Если в итоге получается не ноль, значит, где-то допущена ошибка[52].
Бухгалтеров учат вносить операции по одной за раз и каждый раз формировать баланс после проведения операции. Такой способ позволяет им быстро выявлять ошибки. Они не делают проводок между сверкой баланса, поскольку так будет тяжелее найти ошибки. Этот метод, который называется методом двойной записи, настолько важен для правильного учета денежных средств, что стал мировым стандартом.
Разработка через тестирование по сути то же самое, только для программистов. Каждое необходимое изменение проходит двойную проверку. Сначала под такое изменение пишут тест, затем пишут готовый код, который позволяет пройти этот тест. Обе проверки дополняют друг друга, как активные и пассивные счета в бухгалтерском учете. После прохождения двойной проверки получается нулевой результат — ноль тестов провалено.
Программисты, изучающие разработку через тестирование, учатся вносить запись дважды — когда код не проходит специально написанный тест и еще раз, когда готовый код проходит тест. Такой способ позволяет им быстро выявлять ошибки. Их учат избегать написания большого количества готового кода и запуска партии тестов, поскольку так тяжело найти ошибки.
Эти две дисциплины, двойная запись в бухгалтерском учете и разработка через тестирование, схожи.
И то и другое служит одной цели — предотвращать ошибки в критически важных документах, где каждый символ должен быть правильным. Хотя программирование и стало неотъемлемой частью нашего общества, мы до сих пор не обязали проводить разработку через тестирование на законодательном уровне. Но учитывая то, скольких жизней и средств стоило плохо написанное ПО, может, такой закон не за горами?
Три правила разработки через тестирование
Разработку через тестирование можно описать тремя простыми правилами.
• Не пишите готовый код до того, как напишете тест, который не получится пройти из-за нехватки этого кода.
• Не пишите тестов больше, чем это необходимо для неудачи, — сбой при компиляции также считается неудачей.
• Не пишите готового кода больше, чем достаточно для прохождения теста, который был провален до этого.
Программист с опытом чуть больше нескольких месяцев наверняка посчитает эти правила странноватыми, если не сказать прямо, глупыми. Эти правила подразумевают, что цикл программирования длится пять секунд. Программист начинает с написания тестового кода для готового кода, который пока что не написал. Тест не удается скомпилировать почти сразу, потому что есть упоминание частей готового кода, которые еще не существуют. Программист должен перестать писать тест и начать писать готовый код. Но после нескольких нажатий на клавиши тест, который не получалось скомпилировать, теперь компилируется должным образом. Это заставляет программиста вернуться к тесту и дописывать к нему новый код.