Jakub Pilimon opowiada nam o refaktoryzacji kodu

By 27 October 2020 Bez kategorii

Jakub był jed­nym z prele­gen­tów pod­czas Infos­hare 2020 Online. Nam udało mu się zadać kil­ka pytań uzu­peł­ni­a­ją­cych jego wys­tąpi­e­nie. Zachę­camy do lektury.

W swo­jej prelekcji mówisz o refak­toringu kodu. W niek­tórych orga­ni­za­c­jach to część pro­gramowa­nia, która jest odkładana na potem. Jakie powin­ny być syg­nały dla pro­gramisty, że to ostat­ni moment by zami­ast dodawać nowe funkc­je, skupić się na refaktorze?

Każdy pro­dukt jest inny. Są przy­pad­ki, w których dokonu­je­my tzw. mechan­icznej refak­to­ryza­cji, czy jak ja to nazy­wam, polerowa­nia kodu. Takie czyn­noś­ci powin­ny być codzi­en­ną rutyną zespołu. Są też przy­pad­ki, kiedy zmieni­a­ją się reguły gry i nai­wny mod­el nie jest w stanie dalej wspier­ać nowych funkcji naszego przed­siębiorstwa. Przek­sz­tałce­nia typu “Extract Method” czy “Replace If with Object” nie pomogą, bo trze­ba wykon­ać refak­to­ryza­cję strate­giczną — to już wyma­ga zaplanowania.

Częs­to to biznes stop­u­je takie zmi­any. Jakich argu­men­tów może użyć zespół pro­gramistów, żeby go przekon­ać do refaktoru?

Wspom­i­nam o tym w prezen­tacji. Biznes nie roz­maw­ia językiem tech­nicznym, nie roz­maw­ia językiem rozwiąza­nia. Do ludzi biz­ne­su najlepiej mówić metryka­mi biz­ne­sowy­mi, które częs­to moż­na przetłu­maczyć na oszczęd­noś­ci. Jeśli moja zmi­ana tech­nicz­na przyspiesza przykład­owo tzw. “user jour­ney” i zwięk­sza kon­wer­sję klien­tów i jestem w stanie to zaprezen­tować liczba­mi, to dla biz­ne­su nie ma znaczenia czy osiągamy to nową wer­sją bib­liote­ki czy nowym frame­workiem na fron­tendzie. Oczy­wiś­cie, dopó­ki koszt wprowadzenia jest niższy niż zysk.

A drugiej strony, jak stwierdz­ić, że refak­tor to coś, co nie jest potrzeb­ne w danym momen­cie — a chęć przepisa­nia na tech­nologię X wyni­ka bardziej z np. oso­bistych przesłanek (zna tą tech­nologię dobrze, albo był na kon­fer­encji, zobaczył jed­ną prelekc­je i bard­zo chce jej spróbować) jed­nego z programistów.

Sam wpadałem w takie pułap­ki. Dobrze jak w zes­pole są bardziej doświad­c­zone oso­by, które mogą przystopować takie zmi­any. Z drugiej strony, jeśli nie są one inwazyjne i nie zaj­mu­ją dużo cza­su, to pamię­tamy, że jest z nich wartość dodana — morale zespołu się zwięk­sza. To częs­to dość istot­ny dri­ver architektoniczny.

Co zespół pro­gramisty­czny jest w stanie zro­bić, by pomóc sobie w refak­torze kodu?

Nieustan­na edukac­ja i wspólne zrozu­mie­nie kiedy i czy w ogóle musimy refak­to­ry­zować. Refak­to­ryza­c­ja to inwest­y­c­ja, dopó­ki nie ma z niej zysku, zespół musi zrozu­mieć, że być może lep­iej poświę­cić ten czas na coś innego.

Co w swo­jej pro­gramisty­cznej pra­cy każdego dnia może­my robić, by uniknąć “wielkiego przepisy­wa­nia sys­te­mu”, a każdego dnia po trochu go refaktorować?

Prowadzę z takiej tem­aty­ki 5‑dniowe szkole­nia. Wymienię tylko jed­ną, najważniejszą, rzecz. Odpowied­nie granice mod­ułów, obiek­tów, enkap­su­lac­ja i zdrowy cou­pling pozwala­ją zapewnić, że ewen­tu­alne “przepisanie” zamknie się w skońc­zonej licz­bie miejsc.

 

 

Infos­hare 2020 Online — wirtu­al­ny fes­ti­w­al społecznoś­ci napędzanej technologią!

Pon­ad 7,5 tysią­ca uczest­ników z 71 kra­jów, 250 tech­no­log­icznych star­tupów i kor­po­racji oraz blisko 200 ekspertów z całego świa­ta, którzy dzielili się wiedzą na 9 sce­nach Infos­hare. Tak wyglą­dał Infos­hare 2020 Online! Najwięk­sza tech­no­log­icz­na kon­fer­enc­ja w CEE odbyła się we wrześniu i trans­mi­towana była na cały świat z Gdańska.