С самого начала непрерывного развертывания люди задавались вопросом, как создать лучший процесс для слияния кода со стадией или производственной ветвью. Я представлю свою точку зрения на эту проблему, в чем смысл и в чем заключается самое большое преимущество предоставления кому-то права просматривать ваш код.
Во-первых, давайте поговорим о том, чего должен достичь обзор PR (Pull Request). С моей точки зрения, это должно проверить:
* Проверка кода, посмотреть, все ли работает и все ли сделано как положено;
* Распространение знаний, все должны иметь возможность просматривать код друг друга.
Проверка кода
Что касается первой и наиболее важной цели, проверки того, находятся ли изменения в состоянии готовности к развертыванию/совместному использованию, рецензент должен в первую очередь расставить приоритеты воздействия кода на продукт, гарантируя, что код обеспечивает ожидаемую ценность для бизнеса. После этого, если код был построен с правильным/предопределенным шаблоном проектирования или архитектурой. И последнее, что должно быть в списке, — это проверка именования переменных или стиля кодирования. Это почему? Если изменение не приносит ожидаемой ценности для бизнеса, нет необходимости исправлять шаблон проектирования и имена переменных, поскольку суть доставки в корне неверна. Но это не значит, что вы не можете также пересмотреть наименование вместе с бизнес-ожиданием, это просто означает, что в центре внимания должен быть тот факт, что код обеспечивает свою основную цель, ценность. Наличие этой структуры приоритетов в вашей голове во время просмотра поможет ускорить процесс без большого количества возвратов и возвратов. PR никогда не должны отклоняться на основании именования переменных без проверки других более важных шагов.
Распространение знаний
Последнее - не пустяк. Делиться кодом и позволять кому-то проверять его — это сигнал доверия. В первую очередь, как и в большинстве случаев человеческой интеграции, в этом случае обе стороны оказывают положительное влияние в конце. Автор кода получает ценную обратную связь, а рецензент расширяет свои знания об исходном коде. Это беспроигрышный сценарий, но он возможен только при наличии доверия.
Последний совет. Доверие является основой любого конструктивного человеческого взаимодействия. Если вашей команде не хватает доверия, постарайтесь исправить это и проявите инициативу, поскольку это может вызвать другие проблемы, помимо ухудшения процесса проверки. В качестве предложения по повышению доверия старайтесь чаще заниматься парным программированием, спрашивая мнения в команде по простым вопросам, просто для улучшения взаимодействия или, когда есть место для этого, поделитесь с командой непрофессиональной историей, поскольку это может открыть некоторые двери. другим, чтобы открыться и рассказать о своем опыте.
Обзоры PR могут быть очень точным процессом, но, тем не менее, это человеческий процесс. Чтобы понять код, нам не нужно знать, кто его написал, но чтобы сотрудничать с кодом, мы должны знать людей, которые за ним стоят.
