RSS

Przeglądy kodu to nie egzamin

Liczba odsłon: 424

Poważne pro­jek­ty in­for­ma­tycz­ne po­win­ny wy­ko­rzys­ty­wać tech­ni­kę prze­glą­dów ko­du (ang. code re­view lub peer re­view). Pozwala ona unik­nąć wpro­wa­dza­nia do głów­nej ga­łę­zi re­po­zy­to­rium zmian, któ­re ma­ją nie­po­żą­da­ne skut­ki ubocz­ne. Przeglądy ko­du nie są jed­nak, jak się częs­to są­dzi, ba­tem do­świad­czo­nych pro­gra­mis­tów i archi­tek­tów na pro­gra­mis­tów-ju­nio­rów i choć fak­tycz­nie po­win­ny peł­nić i ta­ką funk­cję, ko­rzyś­ci z ich sto­so­wa­nia są du­żo szer­sze.

Pierwszym i pod­sta­wo­wym ce­lem sto­so­wa­nia prze­glą­dów ko­du jest za­po­bie­ga­nie wpro­wa­dza­niu błę­dów. Pierwszą li­nią opo­ru przed błę­da­mi po­wi­nien być pro­ces kom­pi­la­cji, uwzględ­nia­ją­cy uru­cho­mie­nie te­stów jed­nost­ko­wych. Jeżeli pro­ces kom­pi­la­cji ca­ło­ści pro­jek­tu al­bo któ­ry­kol­wiek z te­stów jed­nost­ko­wych nie koń­czą się po­praw­nie, nie ma o czym da­lej dy­sku­to­wać: zmia­na mu­si zo­stać od­rzu­co­na. Dopiero w dru­giej ko­lej­noś­ci zmia­nę po­wi­nien prze­gląd­nąć czło­wiek, szu­ka­jąc błę­dów, któ­re ujaw­nią się tyl­ko w spe­cy­ficz­nych przy­pad­kach lub dla kon­kret­nych da­nych.

Zazwyczaj do prze­glą­du tra­fia kod tak zwa­nych „młod­szych pro­gra­mis­tów”. Ma to sens: za­zwy­czaj nie ma­ją oni do­sta­tecz­ne­go do­świad­cze­nia ani w sa­mym pro­gra­mo­wa­niu i in­ży­nierii opro­gra­mo­wa­nia, ani w za­kre­sie archi­tek­tu­ry pro­jek­tu, któ­ry roz­wi­ja­ją. Nawet oso­ba, któ­ra świet­nie po­tra­fi pro­gra­mo­wać, mo­że nie­chcą­cy wpro­wa­dzić zmia­nę, któ­ra na sku­tek inter­akcji z za­sto­so­wa­ny­mi bi­blio­te­ka­mi lub nie­zbyt oczy­wi­stą archi­tek­tu­rą pro­gra­mu spo­wo­du­je błęd­ne dzia­ła­nie, na przy­kład w po­sta­ci wy­cie­ku za­so­bów.

Przeglądy po­win­ny jed­nak do­ty­czyć w ta­kim sa­mym sto­pniu do­świad­czo­nych pro­gra­mis­tów i archi­tek­tów. Każdy mo­że po­peł­nić błąd, choć­by w po­sta­ci prze­o­cze­nia. Inna oso­ba, spo­glą­da­ją­ca na zmia­nę z pew­ne­go dys­tan­su, mo­że być w sta­nie do­strzec go i za­le­cić po­pra­wie­nie bez ko­niecz­noś­ci wpro­wa­dza­nia póź­niej do re­po­zy­to­rium sek­wen­cji drob­nych po­pra­wek. Nie jest za­tem do­brą prak­ty­ką, je­że­li do­świad­czo­ny pro­gra­mis­ta sam za­twier­dza swo­je zmia­ny po ich po­myśl­nym przej­ściu przez kom­pi­la­cję i te­sty: w ze­spo­le po­win­na być choć jed­na oso­ba o po­dob­nym do­świad­cze­niu, by na­wza­jem mog­ły do­ko­ny­wać prze­glą­du swo­je­go ko­du. Oczywiś­cie, im więk­szy ze­spół tym ta­ka współ­pra­ca jest prost­sza i mniej po­dat­na na ro­ta­cję kad­ry oraz se­zo­ny ur­lo­po­we.

Celem prze­glą­dów nie jest też wy­łącz­nie wy­szu­ki­wa­nie błę­dów. Osoba reali­zu­ją­ca prze­gląd po­win­na rów­nie chęt­nie wska­zy­wać miej­sca, w któ­rych moż­na za­sto­so­wać bar­dziej czy­tel­ne kon­struk­cje i bar­dziej efek­tyw­ne algo­ryt­my oraz za­stą­pić włas­ne frag­men­ty ko­du go­to­wy­mi roz­wią­za­nia­mi bi­blio­tecz­ny­mi, a na­stęp­nie wy­ma­gać reali­zac­ji tych su­gestii zmian. W ten spo­sób oso­ba, któ­rej kod jest prze­glą­da­ny, uczy się pi­sać pro­gra­my o lep­szej archi­tek­tu­rze, a do re­po­zy­to­rium tra­fia kod bar­dziej do­pra­co­wa­ny, łat­wiej­szy w póź­niej­szym utrzy­ma­niu.

Tu rów­nież wza­jem­ne prze­glą­dy ko­du do­świad­czo­nych pro­gra­mis­tów są cen­ne, gdyż tak sa­mo słu­żą współ­dzie­le­niu wie­dzy i su­gestii mię­dzy oso­ba­mi któ­re wie­dzą du­żo, ale pew­nie nie wszyst­ko. Nawet naj­lep­szym zda­rza się cza­sem za­brnąć w śle­pą ulicz­kę i upar­cie pró­bo­wać roz­wią­zać ja­kiś prob­lem me­to­dą mo­że sku­tecz­ną, ale nie opty­mal­ną. W ta­kim przy­pad­ku nie­za­leż­ny prze­gląd ko­du po­mo­że pro­gra­mi­ście wsko­czyć znów na właś­ci­wy tor.

Wszyscy uczest­ni­czą­cy w pro­ce­sie roz­wo­ju opro­gra­mo­wa­nia wy­ko­rzy­stu­ją­cym ciąg­łą in­te­grac­ję oraz prze­glą­dy ko­du po­win­ni pa­mię­tać, że nad­rzęd­nym ce­lem jest ja­kość pro­duk­tu. Nie ma w nim miej­sca ani na znę­ca­nie się nad no­wy­mi pra­cow­ni­ka­mi, ani na ura­żo­ną du­mę ko­goś, kto uwa­ża, że je­go kod nie wy­ma­ga już żad­nych zmian. Właściwie pro­wa­dzo­ne prze­glą­dy ko­du są in­wes­tyc­ją nie tyl­ko w bie­żą­cy stan pro­jek­tu, ale też w je­go przy­szłość, zaś każ­dy ko­lej­ny prze­gląd po­wi­nien rza­dziej skut­ko­wać zwró­ce­niem zmia­ny do po­pra­wy.