Книга: Руководство по DevOps
Замена неэффективного рецензирования кода парным программированием в организации Pivotal Labs (2011 г.)
Замена неэффективного рецензирования кода парным программированием в организации 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. Вместо него для внесения правок в систему нужно было использовать парное программирование. Благодаря этому программисты сократили время на оценку кода с недель до нескольких часов.
Элизабет Хендриксон тем не менее отмечает, что рецензирование кода отлично работает во многих организациях. Однако оно требует наличия культуры: анализ кода должен цениться так же высоко, как и его создание. Когда такой культуры еще нет, парное программирование может служить важным промежуточным шагом.
- Опасность процесса согласования изменений
- Потенциальные опасности чрезмерного контроля над изменениями
- Производительность в IT
- Рецензии коллег vs Получение разрешений
- Обеспечьте условия для координации и планирования изменений
- Введите практику рецензирования изменений
- Практический пример
- Потенциальные опасности тестирования преимущественно вручную и заморозки изменений
- Введите практику парного программирования, чтобы улучшить качество изменений
- Практический пример
- Замена неэффективного рецензирования кода парным программированием в организации Pivotal Labs (2011 г.)
- Оценка эффективности pull request процессов[139]
- Бесстрашно избавляйтесь от бюрократических процессов
- Заключение
- Заключение части IV
- Глава 5 Агрессивные формы кода и борьба с ними
- Yaffil Classic Server - замена InterBase Classic 4.0
- Стиль написания исходного кода
- 4.6. Техники организации знакомства участников на бизнес-тренинге
- 13.3.4. Поиск и замена текста
- Анализ CIL-кода
- Установка и замена модема
- Материнская плата имеет возможность организации RAID-массивов из двух SATA-дисков. Можно ли подключить к ней только один...
- 2.1. Принципы организации выставочного пространства
- Исправление ранее написанного кода
- Поиск и замена данных
- Оценка кредитоспособности организации-клиента