Ръководство на бивш технологичен ръководител за създаване на здравословна култура за преглед на код, която ви помага да изпращате кода си по-бързо.

TL;DR

  • 🏎 Научете как да ускорите процеса на преглед на кода, за да увеличите максимално продуктивността си
  • 🔬 Научете най-добрите практики, които срещнах за рецензенти на кодове
  • ✏️ Научете най-добрите практики, на които се натъкнах за автори на заявки за изтегляне

Представете си това.

Току-що внедрихте функция и написахте всички тестови случаи. Почувствахте се страхотно за кода, така че отворихте заявка за изтегляне и уведомихте колегите си. След като изминаха дни, вашата заявка за изтегляне изглеждаше точно както преди. Привидно недокоснат. Без коментар. Няма заявка за промяна. Помолихте колегите си отново за преглед на кода и те се съгласиха. Мина още една седмица и нищо не се случи. Попитахте отново и те ви казаха, че им трябва повече време, защото не беше малък PR и имаше много неща, които трябва да се вземат предвид.

Накрая видяхте известие за заявка за промяна и веднага се захванахте с него. След разрешаване на конфликти при сливане и коригиране на крайните случаи, вие поискахте преглед отново и изчакахте. След няколко дни се появяват други заявки за промяна и вие повтаряте процеса отново. Получихте одобрение след друга ревизия и PR най-накрая беше обединен в багажника.

След 4 седмици от отварянето на PR.

Ако можете да се свържете с него, не сте сами. Много екипи са имали такъв бавен процес на преглед на кода. Всъщност това е „един от основните блокери“ в цикъла на разработка. Затова искам да споделя с вас най-добрите практики за преглед на кода, които научих, за да ускоря разработката и да ви помогна да изпращате код по-бързо.

Да тръгваме.

За автори на заявки за изтегляне

Нещото номер едно, което научих, за да повиша производителността на прегледа на кода, е да бъда внимателен като автор. Освен създаването на чист код, има много малки неща, които можете да направите, за да помогнете на рецензентите ви да разберат проактивно вашите заявки за изтегляне.

Бъдете Шофьорът

Ти, авторе, си двигател на темпото. Знаейки, че разчитате на вашите колеги по време на процеса на преглед на кода, можете ясно да съобщите кога и какво предварително, за да изравните очакванията.

Кога е най-важно да съобщите, защото казва на рецензентите ви колко е спешно. Рецензентите могат да планират работата си съответно. Това е чудесен начин да зададете „времева рамка“ за процеса на преглед и също така е чудесен начин да покажете уважение към времето на вашите колеги.

За да съобщите какво, уверете се, че сте включили PR описание, което се фокусира върху това да помогне на рецензентите ви да разберат целта и дизайна на кода на вашите промени. Вместо да изброявате функционалности, започнете с начален абзац, обясняващ предисторията и защо е необходим този PR, който помага на рецензентите да изградят своите „умствени модели“. Други описания, които намирам за много полезни, са:

  • Диаграми на дизайн на код: „екранна снимка на вашата структура на код от високо ниво“ помага на рецензентите да „прегледат цялостния дизайн“ и да реагират бързо на вашата заявка за изтегляне.
  • Критерии за приемане: списък с прости изречения като „Имейл с потвърждение се изпраща на потребителя след изпращане на формуляра.» помага на прегледите да търсят липсващи функции и тестови случаи.

Бъдете кратки

Малките, лазерно фокусирани заявки за изтегляне са най-лесни за четене. Колко малко? Инженерните практики на Google казват „„не мога да го направя достатъчно малък““. „Проучване“ показа, че качеството на прегледа на кода намалява с увеличаване на промяната на кода. Колкото по-дълго преглеждат вашите рецензенти наведнъж, толкова по-малко дефекти улавят. Затова е важно заявката ви за изтегляне да бъде малка и да се съсредоточите върху едно нещо. Ако функцията, която разработвате, е твърде голяма, можете да обмислите да я разделите на множество заявки за изтегляне, като използвате техниката „подредена заявка за изтегляне“.

Той замества голяма заявка за изтегляне с поредица от малки заявки за изтегляне. Помага на рецензентите да се съсредоточат върху едно нещо в дадения момент и се съгласува брилянтно с принципа на „непрекъсната интеграция и непрекъсната доставка“.

За рецензенти на кодове

Внимавайте с пристрастията

„Проучване, публикувано от Google през 2022 г.“ установи, че авторите на заявки за изтегляне са изправени пред различни нива на отблъскване, които варират в зависимост от демографските данни на авторите. Според данните, те са "намерили" това

- Жените са изправени пред 21% по-високи шансове за отблъскване от мъжете

- Black+ разработчиците са изправени пред 54% по-високи шансове от White+ разработчиците

- Разработчиците на Latinx+ са изправени пред 15% по-високи шансове от разработчиците на White+

- Азиатските+ разработчици се сблъскаха с 42% по-високи коефициенти от белите+ разработчици

- По-старите разработчици са изправени пред по-големи шансове за отблъскване, отколкото по-младите разработчици

Трябва да внимаваме повече за неволните пристрастия, особено на разнообразно работно място. Като сме наясно с това, можем да избегнем ненужно отблъскване при прегледите на кода и да помогнем за ускоряване на процеса.

Това е чудесно място за учене, а не за сноб

Независимо от вашето ниво на опит, работата като разработчик е свързана с постоянно учене. Заявката за изтегляне е безценен „пазар“ за разработчиците за комуникация и обмен на обратна връзка. Затова се уверете, че това е място за уважение и винаги се „стремете към споделяне на знания“.

За мен винаги е бил невероятен повод да науча повече за знанията в областта. Вземете моя PR в Airbnb JavaScript Style Guide, научих толкова много за ECMAScript Language Specification от член на Ecma TC39. Ако той отхвърли молбата ми „без конструктивна обратна връзка“, моментът на преподаване никога нямаше да съществува.

Бездействието е лошо

Прочетох за публикация в блог, озаглавена „Агресивен преглед на кода“ от технически лидер в Instagram преди година. Той твърди, че ефективният преглед на кода се състои от

  • решителни действия възможно най-скоро
  • с цел намаляване на цената на грешките
  • изискващи малка заявка за изтегляне и бързо движение

Това, което намерих за освежаващо в подхода му, е, че да не се действа по заявка за изтегляне не е опция. Минимизира времето за преглед и беше много полезно за мен и моя екип. Ние можем да доставяме бързо, защото предприемаме проактивни действия за преглед на кода. Ние не позволяваме чакащите заявки за изтегляне да се задържат и да ги преглеждаме, като имаме предвид бизнес случая.

Последни мисли

За да обобщим най-добрите практики за заявка за изтегляне и преглед на кода, за да ускорите своя цикъл на разработка

  • установете ясна комуникация за това кога и кога и кога е заявка за изтегляне
  • създайте малка и самостоятелна заявка за изтегляне, която се фокусира върху едно нещо
  • внимавайте за пристрастията
  • бъдете уважителни към автора и колегите рецензенти
  • предприемете решителни действия за преглед възможно най-скоро

Препратки

  • „Отблъскващият ефект на расата, етническата принадлежност, пола и възрастта в прегледа на кода“ – Емерсън Мърфи-Хил, Сиера Джаспан, Каролин Егелман, Лан Ченг
  • „Използване на изследвания, за да направим прегледа на кода по-справедлив“ — Емерсън Мърфи-Хил, изследовател, Централно включване на продукти, справедливост и достъпност
  • Най-добри практики за преглед на код — SMARTBEAR
  • Малки CL — Google
  • „Натрупани заявки за изтегляне: направете прегледите на кодове по-бързи, по-лесни и по-ефективни“ – д-р Михаела Грейлер
  • „Прегледите на кода стават блокер“ — Reddit
  • „Тясно място при преглед на код“ — Reddit
  • Timeboxing — Уикипедия
  • „Ментални модели: Научете как да мислите по-добре и да придобиете умствено предимство“ – Джеймс Клиър
  • „Разширение AppLand за VSCode“ — GitHub
  • „Какво да търсите при преглед на кода“ — Google
  • https://www.boost.co.nz/blog/2010/09/acceptance-criteria — Нейтън Доналдсън
  • „Ръководство на бившия главен инженер за дизайнерско мислене и непрекъсната доставка“ — Daw-Chih Liou
  • Добавяне на частен идентификатор на клас — GitHub
  • Езикова спецификация ECMAScript® 2023 — Ecma International
  • Ecma TC39 — GitHub
  • „Да бъдем разкъсани при прегледи на кодове, това нормално ли е?“ — Reddit
  • Агресивен преглед на код — Боби
  • „Модерен преглед на код: Казус от Google“ — Кейтлин Садовски, Ема Содерберг, Люк Чърч, Михал Сипко. Google, Inc.
Want to Connect? This article was originally posted on Daw-Chih’s website.