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

Най-вероятно вашите предложения никога няма да бъдат приложени, защото:

  1. Това предизвиква фундаменталната предпоставка, върху която са изградили кода, и ще отнеме неплатими времеемки усилия, за да го рефакторизира според вашите правила.
  2. Екипът не е в настроение да се съгласи с вас, защото интелектът им е бил предизвикан.

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

Преглед на кода се извършва само когато кодът отговаря на определено условие за годност за преглед на кода. Без това първоначално условие прегледът на кода изисква големи промени в структурата на кода и се превръща в отнемаща време работа. Ако не можете да прегледате кода в 1/20 от времето, в което разработчикът го е написал, тогава това се превръща в церемония, която няма място в проекта.

Имам много просто правило: След като погледна кода само за 30 секунди, ако не разбирам бизнес намерението на кода, не го преглеждам, освен ако кодът не е пренаписан на изяснете намерението.

Това, от което се нуждаете, не са сложни стандарти за кодиране, а Споразумение за ниво на качество на кода.

Споразумение за ниво на качество на кода (CQLA)

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

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

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

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

Предимства на споразумението за качество на кода

Задава летва, която може да бъде повдигната

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

Екипите ще спрат да мислят от гледна точка на технологията и повече за организацията на кода.

Прави процеса анти-чуплив

Грешка, която допускаме, е да мислим, че правилата, които създаваме за екип или проект, ще работят и за други екипи и проекти. CQLA прави процеса на преглед на кода адаптивен. Учи се от грешките и динамиката на отбора. Става по-силен с всеки цикъл.

Придава смисъл на прегледите на код

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

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

Намалява времето, необходимо за прегледи

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

Ако кодът не може да бъде прегледан в 1/20 от времето, в което е написан, тогава той се превръща в церемония, която няма място в проекта.

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

Вие растете като рецензент с екипа и проекта

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

Добавките на CQLA дават усещане за участие в екипа. Кара ги да се чувстват партньори в изграждането на процеса.

Насоки на CQLA: Очаквайте те да бъдат пренебрегнати

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

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

Растеж чрез отхвърляне

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

Заключение

Прегледите на кода трябва да бъдат проектирани с дългосрочна цел за растеж. Трябва да гледаме на прегледа на кода не като на застояла дейност, а като на нещо, което ще помогне да се повишат способностите за кодиране и преглед на екипа с течение на времето.Прегледите на кода трябва да улеснят екипа да разбере, че кодът е написан за хора, а не за компютри. С всяко вдигане на лентата на стойността на Code-Review, по-новите неща, които се нуждаят от внимание, ще изплуват и върху тях може да се съсредоточи вниманието.