Преглед кода - Крајњи водич

Крајњи водич за изградњу процеса прегледа кода вашег тима

Након што сам спровео стотине прегледа кода, водио истраживачке и развојне тимове и гурао неколико ненамерних грешака, одлучио сам да поделим своје закључке за изградњу коначног поступка прегледа кода за ваш тим.

Овај чланак претпоставља да знате шта је преглед кода. Па ако не, кликните овде за сјајан увод.

Наведимо брзо неке непосредне разлоге зашто треба да вршите прегледе кода:

  1. Може вам помоћи да смањите грешке у коду.
  2. Потврдите да су испуњени сви захтеви за кодирање.
  3. Ефикасан начин за учење од вршњака и упознавање са базом кода.
  4. Помаже у одржавању стила кода у тиму.
  5. Кохезија тима - подстакните програмере да међусобно разговарају о најбољим праксама и стандардима кодирања.
  6. Побољшава укупан квалитет кода због притиска вршњака.

Међутим, прегледи кода могу бити један од најтежих и дуготрајних делова процеса развоја софтвера.

Сви смо били тамо. Можда сте чекали дане док се ваш код не прегледа. Једном када сте га прегледали, покренули сте пинг понг са рецензентом како бисте поново послали захтев за повлачење. Одједном проводите недеље у назад и назад. Пребацујете контекст између нових карактеристика и старих урезивања која још увек требају полирање.

Ако поступак прегледа кода није планиран како треба, могао би имати више трошкова него вредности.

Због тога је изузетно важно структурирати и изградити добро дефинисан поступак за прегледе кода унутар вашег инжењерског тима.

Генерално, мораћете да имате добро дефинисане смернице и за рецензента и за рецензента, пре него што направите захтев за повлачење и док се он прегледава. Конкретно:

Дефинишите предуслове за креирање захтева за повлачење.

Открио сам да следеће знатно смањује трење:

  1. Уверите се да се код успешно компајлира.
  2. Прочитајте и забележите свој код.
  3. Направите и покрените тестове који потврђују опсег вашег кода.
  4. Треба тестирати сав код у кодној бази.
  5. Повежите релевантне карте / ставке у вашем алату за управљање задацима (на пример ЈИРА) са захтевом за повлачење.
  6. Не додељујте рецензента док не завршите горе наведено.

Дефинишите одговорности рецензената

Иако је рецензент последњи у ланцу обједињавања вашег ПР-а, што га бољи прималац предаје, то ће на вас налетети на мање ризика. Ево неколико смерница које могу у великој мери помоћи:

  1. Комуницирајте са рецензентом - Дајте рецензентима позадину о задатку. Будући да су већина нас аутори захтева за повлачење већ били рецензенти, једноставно се ставите на место рецензента и питајте: „Како ми ово може бити лакше?“
  2. Упућујте мање захтеве за повлачење - Упућивање мањих захтева за повлачење је најбољи начин да убрзате време прегледа. Нека ваши захтеви за повлачење буду мали како бисте могли брже и тачније да понављате. Генерално, мање промене кода је такође лакше тестирати и верификовати као стабилне. Када је захтев за повлачење мали, рецензентима је лакше да разумеју контекст и разлог са логиком.
  3. Избегавајте промене током прегледа кода - Главне промене у средини прегледа кода у основи ресетују цео процес прегледа. Ако требате да направите велике промене након подношења рецензије, можда ћете желети да своју постојећу рецензију и наставак пошаљете са додатним променама. Ако требате да направите велике промене након покретања поступка прегледа кода, обавестите ово о томе што је могуће раније у процесу.
  4. Одговорите на све повратне информације о преиспитивању кода - чак и ако не примените њихове повратне информације, одговорите на њих и објасните своје образложење. Ако нешто не разумете, постављајте питања унутар или изван прегледа кода.
  5. Прегледи кода су дискусије, а не диктирање - Већину повратних информација о прегледу кода можете сматрати предлогом више од налога. У реду је што се не слажете са повратним информацијама рецензента, али морате да објасните зашто и да им дате прилику да одговоре.

Дефинисати одговорности рецензената

Будући да је рецензент последњи у ланцу пре спајања кода, велики део одговорности је на њему због смањења грешака. Рецензент треба да:

  1. Будите свесни описа задатка и захтева.
  2. Обавезно потпуно разумејте код.
  3. Процените све компромисе у архитектури.
  4. Поделите своје коментаре у 3 категорије: критични, необавезни и позитивни. Први су коментари које програмер мора прихватити да би их променио, а други су коментари који програмеру дају до знања да цените лепе делове кода.

Такође, избегавајте много коментара и уместо тога користите Гитхуб преглед (погледајте пример испод).

Када имате неколико коментара, требало би да користите опцију прегледа у Гитхуб-у, уместо да коментаришете сваки од њих посебно, и обавестите програмера (власника ПР-а) када завршите.

Коначно, открио сам да је постављање следећих питања одличан алат за свеукупни бољи и лакши поступак прегледа:

  • Имам ли потешкоћа у разумевању овог кода?
  • Постоји ли сложеност у коду која би се могла смањити рефакторингом?
  • Да ли је код добро организован у структури пакета која има смисла?
  • Да ли су називи разреда интуитивни и да ли је очигледно шта раде?
  • Постоје ли неки часови који су изузетно велики?
  • Постоје ли неке нарочито дуге методе?
  • Да ли се сва имена метода чине јасним и интуитивним?
  • Да ли је код добро документован?
  • Да ли је код добро тестиран?
  • Постоје ли начини на које би овај код могао бити ефикаснији?
  • Да ли код испуњава стандарде за обликовање наших тимова?

Постоје разне ефикасне и различите праксе прегледа кода које се разликују у зависности од потреба тима. Дакле, претпоставите да је ово моје лично мишљење и да постоје и други начини који би могли радити за ваш тим. На крају, изградња тако осетљивог процеса треба да буде субјективна циљевима ваших компанија, култури тима и целокупној структури истраживања и развоја.

Ако имате питања или повратне информације за побољшање ових смерница, слободно додајте коментар испод!