Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

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

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

Парное программирование — ситуация, когда два программиста вместе работают на одном рабочем месте. Этот метод был популяризован в ранних 2000-х гг. в таких направлениях, как экстремальное программирование (Extreme Programming) и гибкая методология разработки (Agile). Как и рецензирование кода, этот способ появился в разработке, но он также применим и к деятельности любого инженера в потоке создания ценности. Далее термины парная работа и парное программирование будут использоваться как синонимы, чтобы подчеркнуть, что этот метод подходит не только разработчикам.

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

Еще один подход к парному программированию воплощает принципы основанной на тестировании разработки (test-driven development, TDD): один инженер пишет автоматизированные тесты, а второй — собственно приложение. Джефф Этвуд, один из основателей сайта Stack Exchange, пишет: «Я все время думаю о том, что парное программирование — всего лишь рецензирование кода на стероидах… Преимущество парного программирования — в его захватывающей непосредственности: невозможно игнорировать рецензента, если он сидит рядом с тобой».

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

В 2001 г. Лори Уильямс провела исследование, где показала, что «программисты в паре работают на 15 % медленнее, а объем кода без ошибок увеличивается с 70 до 85 %. Поскольку тестирование и отладка часто во много раз дороже, чем создание первоначального кода, эти результаты впечатляют. Пары обычно рассматривают больше альтернатив, чем программисты-одиночки, и в результате их решения проще и поддерживать их легче. Они также раньше замечают ошибки проектирования». Лори Уильямс также отмечает, что 96 % ее респондентов сообщили, что работа в паре понравилась им больше, чем работа в одиночку[138].

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