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

Практический пример

Замена неэффективного рецензирования кода парным программированием в организации Pivotal Labs (2011 г.)

Элизабет Хендриксон, технический директор организации Pivotal Software, Inc. и автор книги Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing, много раз говорила, что каждая команда должна нести ответственность за качество своего труда, вместо того чтобы возлагать ответственность на отделы. Она утверждает, что такой подход не только повышает качество результата, но также увеличивает количество изменений.

В своей презентации на конференции DevOps Enterprise Summit в 2015 г. она рассказала, что в 2011 г. в Pivotal было два метода оценки кода: парное программирование (каждая строчка кода проверялась двумя людьми) и рецензирование кода с помощью программного обеспечения Gerrit (каждая фиксация кода должна была получить «+1» от двух человек, прежде чем отправиться в основной код проекта).

Элизабет заметила, что с Gerrit есть одна проблема: иногда программисты ждали рецензии целую неделю. Что хуже, у опытных программистов «появлялось раздражение и опускались руки оттого, что они не могли внести в код простейшие изменения, потому что мы непреднамеренно создали невыносимые заторы в работе».

Она пожаловалась: «Старшие инженеры единственные способны ставить “+1” правкам кода, но у них много других обязанностей, им часто все равно, над какими проблемами бьются младшие разработчики и какая у них производительность. Получилась ужасная ситуация: пока ты ждешь рецензии на изменения, другие разработчики отправляют код в систему. Целую неделю приходилось загружать внесенные другими изменения на свой ноутбук, еще раз прогонять все тесты, чтобы убедиться, что все удачно, и иногда отправлять код на рецензию заново!»

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

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

Оценка эффективности pull request процессов[139]