Као млађи софтвер инжењер, увек сам проучавао коментаре прегледа кода које сам добио како бих научио како да постанем бољи кодер. Али када је дошло време да покушам прво прегледавање кода, схватио сам да ме искуство није припремило да будем на другој страни.
Развио сам тежак случај синдрома импозтера, спирално напуштен са питањима: Да ли треба да коментаришем ову линију кода или то не вреди? Да ли треба да пронађем чланке који ће подржати сваки коментар? Хоћу ли оборити локацију одобрењем ове странице? Хоће ли ме мрзити? Ок, признајем да се спирала прилично брзо. Али након разговора с неким колегама, знао сам да нисам сам у бризи.
Млађи софтверски инжењери могу бити убачени у преглед кода уз претпоставку аналогну "да знате како читати књигу па знате како написати књигу, што није тачно", каже Јессица Руддер, инжењерка искуства у ГитХуб-у.
Постоје очекивања која долазе са прегледом кода и процес може бити нервозан. Тако сам интервјуисао седам других софтверских инжењера да прикупим савете о томе како да изградите мишљење о прегледу.
1. Размислите о укупном утицају
Опћенито, добар захтјев за повлачење (ПР) требао би утјецати само на ограничени дио базе података. Међутим, ограничени опсег не треба да вас спречи да размишљате о промени кода у контексту веће базе података.
Најџел Муноз, бивши инжењер с пуним набојем компаније Тхе Мусе и тренутни фрееланце софтверски инжењер, охрабрује рецензената да размисли о томе „како ова промена утиче на већу и мању слику“. то се понавља, немодуларно или се не придржава најновијих стандардних конвенција - као и анализа модификација архитектуре базе података кодова.
Сам Донов, главни програмер у Худсон Ривер Традингу, верује да "не постоји ништа превише или превише мало да би се то могло коментарисати. Сугестије за мала побољшања могу довести до већих побољшања у више делова базе података. “
Можете користити ПР коментар на ГитХуб да пружите позитивне повратне информације као и да истакнете где се код може разликовати од стандардних конвенција оквира Реацт.
На пример, током једне од мојих рецензија кодова, примио сам коментар да су одређена својства компоненте Реацт збуњујућа, што је покренуло шире питање о томе како се компонента користи. На крају сам уклонио својства из оригиналне компоненте и створио засебну компоненту да разјасним понашање сваког од њих и осигурам да се обе могу користити на више места.
2. Размотрите сигурност
Не заборавите да би неке промене могле утицати на више од само базе података. Руддер препоручује процену да ли корисник „могао да користи ову функцију да би некога узнемиравао или да би могао злоупотребити систем.“ На пример, ако нова функција захтева за повлачење укључује улазак корисника, потражите СКЛ убризгавање, приступ подацима, скрипту на веб локацији и друге сигурносне рањивости.
3. Фокусирајте се на грешке
Ваши сарадници кодова - без обзира колико роботски они изгледали - су људи, а људи могу сломити или заборавити функције. Зато будите сигурни да "прегледате тестове са истим значајем као и остатак кода", саветује Абхисхек Пиллаи, технолошки водећи у компанији Теацхерс Паи Теацхерс. „Они ће спречити нове грешке и послужиће као облик документације за све остале који буду радили на томе у будућности.“
Читање тестова може вам помоћи да разумете функционалност нове функције и видите различите случајеве које ће она увести, док анализа тестова може вам помоћи да укажете на случајеве који недостају и нађете функције које нису садржане у овом ПР-у. Ако у промени кода нису укључени тестови и они изгледају релевантно, примерено је да их затражите у оквиру прегледа.
Али тестови нису све. „Немојте превише веровати у систем“, упозорава Донов. "Само зато што су вршени тестови не значи да нема грешака."
Такође бисте желели „покренути апликацију локално како бисте је функционално тестирали и увјерили се да ради. Ако то не успије, онда нема смисла у даљњем прегледу ", каже Риан Вернер, програмер софтвера у компанији 8тх Лигхт. Иако неки рецензенти не мисле да би ручно тестирање требало да буде део поступка прегледавања кода - делом и због времена које је потребно - Вернер верује да је то брз начин да се утврди да ли треба да уложите више времена у преиспитивање, као и стратегију за помоћ смањењу раст заостатака грешака.
4. Будите тимски играч
Клишеј поприма ново значење када је у питању преглед кода. „Одвојите време за преглед јер је свачија шифра базе“, каже Вернер, који се залаже за осећај „колективног власништва“. Ви, као рецензент, требало би да радите на заштити броја заосталих грешака од пораста, а све у циљу да свој тим мање ради на линији.
Пиллаи користи гифс да прослави одобрене ПР и своје спремне за спајање ПР-а.
У исто време, Цхарлес Луктон, технолошки водећи директор Тхе Мусе-а, подстиче рецензенте да разумеју и памте приоритете тима. Уз брзо приближавање рокова и несугласица која обилују, понекад стварајући обавезу за заостатак који обезбеђује побољшања у будућности, а у међувремену ставите коментар на дотични код је Банд-Аид који вам је потребан да бисте нека ваш тим буде срећан.
И на крају, питање да ли би код имао смисла за некога ко се тек придружио тиму и прочитао га у првих неколико недеља помоћи ће да ваш код буде читљив и разумљив.
5. Користите Процес за учење и дељење знања
Процес прегледа свима који су укључени нуди мјесто за бољи увид у шифру, језике, оквире и најбоље праксе.
Матт Јеффери, технолошки водећи директор Тхе Мусе-а, савјетује рецензенту да "архитектонски схвати промјене. Један од начина је читање имена датотека јер оне помажу у контексту. На примјер, ако гледате на промјену слоја приступа подацима знате да се не бавите пословном логиком или корисничким сучељем. "
Можете користити ПР коментар на ГитХуб за дељење документације.
Када учите од промена кода, такође имате прилику да делите знање. „Најбоље је објаснити своје мишљење и подупријети га документацијом“, каже Луктон. Везе које пружате у прилог доказима и поузданим чланцима не само што помажу рецензенту и писцу кода да истраже различите приступе приликом доношења коначне одлуке, већ и јачају њихово знање о програмирању.
Иако имате на уму ове савете, имајте на уму и то да је преглед време да вежбате своје вештине. „Дајте људима користи сумње да су размишљали о свом приступу и укажите на различите могућности док покушавају да одагнају одбрамббу“, каже Руддер. „Коментар остављам у целости и завршни коментар - ево шта је сјајно, ево шта се може побољшати, ево шта треба променити пре спајања.“
Оваквим приступом не само да ћете заштитити базу код од техничког дуга, безбедносних претњи и пропуста, већ ћете и градити свој тим.
