Ефективни практики за преглед на код и сливане

Запазете качеството на кодовата си база чрез проактивно участие

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

„Възприемането на навици за писане на чист код“ е важно, но без също така да дефинирате насоки за принос, кодовата ви база може да се развали.

1 - Дефиниция на Готово, за разработчици

Ще се изненадате, че само познаването на добрите практики не е достатъчно, за да предприемете действия по въпроса

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

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

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

Примерен контролен списък

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

Изискванията се прилагат без никакви продължителни незададени въпроси (опитайте се поне да имате известни неизвестни)
Ако се практикува BDD, сценариите се дефинират, за да се гарантира, че изискванията са проверими
Ако проектът е „междуплатформен“, всички платформи са тествани за надеждност
Единични тестове за нова или променена функционалност бяха добавени или актуализирани. Съществуващите модулни тестове не бяха повредени в процеса. Известни са вече повредени тестове и чакат някакъв вид действие
Трябваше ли да хакнете нещо, за да работи нещо? Ако не беше върнат, маркирахте ли хака с коментар за код за търсене?
За нови файлове е използван инструментът за форматиране на код (със споделени настройки на вашия екип)
Файловете с изображения бяха оптимизирани за най-малкото компресиране без загуби преди ангажиране
Големите двоични файлове се проверяват с помощта на разширение за контрол на източника, което не надува (напр. използване на git lfs, git fat или git-annex)
Непрекъсната интеграция: Задачите за изграждане се предават на CI машините. Единичните тестове преминават на CI машините, не само на вашата машина
Обратно интегриране от целевия клон (ако не сте пребазирани преди натискане), разрешаване на конфликти при сливане и повторно стартиране на CI, проверка за разумност, ако е необходимо

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

Това, което ме създава безпокойство, е мисълта за цял екип за разработка, който изпълнява код без такава дефиниция.

2 - Превантивна самооценка

Преди да назначите рецензент, не е лоша идея да прегледате сами промените си. Това ви дава възможност да направите следното:

Уловете потенциално неудобни грешки. напр. правописни грешки, наистина объркано изглеждащо празно пространство, код, който сте забравили да изтриете, коментари в кода, които сте забравили.
Напишете коментари за преглед на кода (ако не преглеждате заедно), за да обясните решения, които може да се нуждаят от малко контекст за прегледа, но не изисквайте коментар в кода.
„Последният шанс“ да проверите отново, ако сте забравили да регистрирате файл или сте проверили файл, който не трябва да имате. Няма значение колко умен или опитен сте, хората все още правят тази грешка, ако не са внимателни, а рецензентите също не винаги ги хващат.

Потенциално можете да спестите известно време за преглед на кода, като направите това основно веднъж.

3 - Преглед на двойки

Независимо дали споделяте екрана или имате друг програмист на бюрото си (вероятно първият през 2020 г.), прегледът в реално време и обсъждането на предложените промени показват малко повече внимание към това, което влагаме в кодовата база.

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

4 - Стратегия за разклоняване и сливане

Кодовата база с възможност за непрекъснато изпращане изисква да бъде в постоянно надеждно, здравословно състояние...

На вашата машина за разработка местните лични клонове са безплатни за всички – правете каквото искате, стига да не вредите на никого. Когато дойде време да се слеете в клонове, на които другите разчитат, трябва да сте сигурни, че те могат. Вашият екип трябва да има добре дефинирана стратегия за разклоняване.

Има различни видове разклонения, с различен живот и различни нива на стабилност. Като такива, към ангажирането и сливането трябва да се подходи по различен начин. В духа на добрата практика клоновете се използват за обезсърчаване на предаването на код директно към главния/главната линия/магистралния канал, който трябва да приема промени само чрез сливане.

Кодовата база с възможност за постоянно изпращане изисква самата тя да бъде в постоянно надеждно, здравословно състояние, поддържано чрез процес на постепенно разклоняване. Следното е само един пример за това как да постигнете това, но има различни стратегии за постигане на същия ефект. Имайте структуриран и ефективен план, към който вашият екип може да се придържа.

Клонове за коригиране на грешки: кратък живот

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

Характеристика на клонове: среден живот

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

Функционални клонове за сътрудничество: кратък до среден живот

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

Епични клонове: дълъг живот

Ако набор от функции е част от епос, чието внедряване може да отнеме месеци, може да е полезно да запазите епичен клон. Въпреки това, в много случаи, ако характеристиките в епоса са индивидуално смилаеми и достатъчно независими, за да работят един без друг, може би е по-добре да обедините клоновете на характеристиките в master, когато са завършени, вместо да имате епичен клон между двата .

Главният клон: постоянен

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

Никога не се ангажирайте директно с мастера (с изключение на разумни изключения)
Никога не обединявайте нищо за овладяване, което не се компилира на CI
Никога не обединявайте нищо, което прекъсва или блокира най-основната функционалност
Трябва да се положат разумни усилия за поддържане на преминаването на модулните тестове в master; неизправностите трябва да се разрешават бързо
Автоматизацията на потребителския интерфейс трябва да се стартира от това редовно, ако не и на CI
В идеалния случай без недовършена работа; обикновено трябва да се обединяват само функции, които достигат дефиницията на разработчика за Готово

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

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

Стабилният клон: постоянен

Това е по-зряла версия от master, следователно по-подходяща за неразработчици, като QA. Наличието на този буфер между главния и освобождаващия клонове трябва да позволява периоди на „замразяване на кода“, без да блокира прогреса в главния.

Може да имате някои критерии за преминаване на главния код в стабилен. Някои добри показатели за здрав стабилен клон са:

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

Stable може да премине към издание, когато всички тестове за следващото издание приключат.

Освобождаване на клонове: постоянно

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

Когато всички функции или поправки, предназначени за пускане, са завършени и са преминали QA и PO приемане (и/или UAT)
Когато стабилният е преминал пълно регресионно тестване от QA

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

Стратегия за именуване

Вашият екип също трябва да следва последователни модели за именуване на клонове. Обикновено с префикс или инициали на разработчици за лични клонове и/или номера за проследяване на грешки или функции.

Заключение

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