RSS

Nowy pomysł na przeglądy kodu

Liczba odsłon: 143

po­przed­nim wpi­sie blo­ga opi­sy­wa­łem me­cha­nizm prze­glą­dów ko­du i tłu­ma­czy­łem, że oprócz funk­cji pre­wen­cyj­nej peł­ni on też funk­cję edu­ka­cyj­ną. Stosowa­nie prze­glą­dów ko­du pro­wa­dzi też do po­pra­wy ja­koś­ci opro­gra­mo­wa­nia, do­raź­nie i dłu­go­fa­lo­wo. Niestety, ty­po­wo sto­so­wa­ny spo­sób wska­zy­wa­nia błę­dów w ko­dzie spraw­dza się pod wzglę­dem edu­ka­cyj­nym, ale nie wy­ko­rzys­tu­je peł­ni moż­li­woś­ci po­pra­wy ja­koś­ci pro­duk­tu.

Typowy pro­ces prze­glą­du ko­du za­czy­na się od ser­we­ra ciąg­łej in­te­grac­ji, któ­ry kom­pi­lu­je pro­jekt z pro­po­no­wa­ny­mi zmia­na­mi i uru­cha­mia wszyst­kie te­sty jed­nost­ko­we. Jeżeli dzia­ła­nia te za­koń­czą się po­myśl­nie, zmia­na tra­fia do wska­za­nej gru­py osób upraw­nio­nych do prze­pro­wa­dza­nia prze­glą­dów. Każda z nich ma pra­wo uzu­peł­nić treść zmia­ny o włas­ne ko­men­ta­rze i za­pro­po­no­wać przy­ję­cie lub od­rzu­ce­nie zmia­ny, przy czym de­cy­du­ją­cy głos ma wą­ska gru­pa naj­bar­dziej do­świad­czo­nych pro­gra­mis­tów z pra­wem za­we­to­wa­nia lub za­ak­cep­to­wa­nia po­praw­ki.

Jeżeli za­tem któ­raś z osób prze­glą­da­ją­cych kod na­tra­fi na po­tenc­jal­ny błąd, je­dy­nym moż­li­wym dzia­ła­niem jest wpi­sa­nie ko­men­ta­rza i za­koń­cze­nie prze­glą­du klik­nię­ciem przy­ci­sku „Głosuj prze­ciw­ko”. Osoba zgła­sza­ją­ca po­praw­kę mu­si w ta­kim przy­pad­ku spraw­dzić, czy błąd fak­tycz­nie wy­stę­pu­je i al­bo po­pra­wić kod i od­po­wie­dzieć na ko­men­tarz, al­bo uza­sad­nić zig­no­ro­wa­nie prob­le­mu.

Komenta­rze w sys­te­mie prze­glą­du ko­du nie pod­no­szą ja­koś­ci pro­duk­tu; te­sty jed­nost­ko­we — tak. Wyobraź­my so­bie za­tem in­ne po­dejś­cie. Osoba prze­glą­da­ją­ca kod tra­fia na po­tenc­jal­ny błąd. Jednym klik­nię­ciem przy­ci­sku prze­łą­cza swo­je lo­kal­ne re­po­zy­to­rium pro­jek­tu na ga­łąź za­wie­ra­ją­cą gło­so­wa­ną po­praw­kę i do­pi­su­je kod te­stu jed­nost­ko­we­go stwier­dza­ją­ce­go ist­nie­nie błę­du wraz z ko­men­ta­rzem wy­jaś­nia­ją­cym na czym po­le­ga­ła po­tenc­jal­na uster­ka. Kod no­we­go te­stu tra­fia do tym­cza­so­wej ga­łę­zi re­po­zy­to­rium, któ­ra jest na­tych­miast po­now­nie kom­pi­lo­wa­na i we­ry­fi­ko­wa­na. Jeżeli no­wy test prze­szedł po­praw­nie, re­cen­zent mo­że odetch­nąć z po­czu­ciem do­brze speł­nio­ne­go obo­wiąz­ku i przejść do prze­glą­da­nia dal­szych frag­men­tów; je­że­li jed­nak za­koń­czył się błę­dem, zmia­na od ra­zu wra­ca do auto­ra, któ­ry ma za za­da­nie al­bo po­pra­wić uster­kę, al­bo udo­wod­nić, że test jest błęd­ny.

Różnica jest sub­tel­na, ale za­sad­ni­cza. Z ko­men­ta­rzem łat­wo jest dy­sku­to­wać, a prze­py­chan­ki słow­ne mo­gą trwać ca­ły­mi dnia­mi. Z ko­dem się nie dy­sku­tu­je: al­bo jest po­praw­ny, al­bo błęd­ny. O ile test nie zo­stał zbu­do­wa­ny w opar­ciu o cał­ko­wi­cie błęd­ne za­ło­że­nia, po­wi­nien być wy­ko­na­ny po­praw­nie, za­tem je­że­li koń­czy się błę­dem, to pro­po­no­wa­na zmia­na naj­praw­do­po­dob­niej jed­nak też jest błęd­na.

Takie po­dejś­cie do prze­glą­du ko­du ma za­tem spo­ro za­let:

Niestety, ma rów­nież po­waż­ne wa­dy:

Wątpię za­tem, by te­go ty­pu roz­wią­za­nie zy­ska­ło po­wszech­ną ak­cep­tac­ję i po­ja­wi­ło się w po­pu­lar­nych sys­te­mach prze­glą­du ko­du. Podobny me­cha­nizm moż­na jed­nak wdro­żyć w po­sta­ci we­wnętrz­nej po­li­ty­ki przed­się­bior­stwa: wy­star­czy, by zgła­sza­ne wąt­pli­wo­ści by­ły roz­wie­wa­ne nie od­po­wie­dzia­mi w ko­men­ta­rzu, lecz te­sta­mi jed­nost­ko­wy­mi do­da­wa­ny­mi przez auto­ra zmia­ny. Boję się jed­nak, że zbyt częs­to pro­gra­miś­ci szli by na łat­wiz­nę i roz­wie­wa­li wąt­pli­wo­ści nie ko­dem, lecz ję­zy­kiem.