Nie ma kodu idealnego. Jest kod “wystarczająco dobry”. Ale oczywiście… większość tego, co widzimy na co dzień, nie wpada w tę definicję. Zwykle mamy do czynienia z kodem niedostatecznie dobrym lub wręcz wzorowo złym. Ale smutas ze mnie, nie? Czy po prostu: realista?
[blogvember2016 no=”11″]
Oczywiście prawie z każdego bagna da się wydostać. Potrzeba jedynie wystarczająco dużo czasu, determinacji i… umiejętności.
Co zatem robimy?
Refaktorujemy!!! Or Die Trying
Skoro kod jest ohydny, to trzeba go “uładnić”. Często drobne, kosmetyczne zmiany, nie wystarczą. Nałóż szminkę na świnię, a pod spodem dalej będziesz miał parszuka. Trzeba ten spód właśnie zamienić na coś innego, żeby szminki nie potrzebowało.
Znane jest Ci pewnie zagadnienie dość popularnego podejścia do poprawy jakości kodu. Czyli: “refactoring sprint“. Jak to wygląda?
Mówimy biznesowi/klientowi: potrzebujemy X dni/tygodni na usprawnienie naszej pracy. W tym czasie nie będziemy dostarczać nowych rzeczy ani poprawiać błędów, ale za to POTEM RUSZYMY Z KOPYTA! Teraz mamy “dług technologiczny”, stare biblioteki, średni design, ale jak to ponaprawiamy to zobaczysz jacy będziemy błyskawiczni!
Ci mniej doświadczeni może się na to nabiorą. Pozostali sparsują sobie taką przemowę. Usłyszą: narobiliśmy pod siebie tak bardzo, że grzęźniemy. Nie mieliśmy odpowiednich kompetencji, by zrobić dobrze za pierwszym razem, więc chcemy drugą szansę. Zaufaj, że się nauczyliśmy na własnych błędach. Płać za to, że skalamy się sprzątaniem swojego syfu. Jak myślisz: zgodzi się?
Często się nie zgodzi. A programiści będą narzekać, że “klient chce mieć brzydki kod, to będzie go miał!”. Co najważniejsze: to biznes ma w tym przypadku rację. Prawdopodobnie widział to nieraz. Zresztą sami to widzieliśmy, a nadal naiwnie wierzymy, że “tym razem się uda”.
Tak często narzekamy na stronę “biznesową” programowania, ale to naprawdę nie są głupi ludzie. Posłuchaj zresztą “DevTalk#42 – O sprzedaży w IT z Michałem Wójcikiem” i przekonaj się na własne uszy.
Ale załóżmy, że wysłaliśmy bardzo przekonującą delegację do “rozmów z krawaciarzami”. I udało się: mamy cały sprint dla siebie! Jaki jest tego efekt? Bez odpowiedniego, dokładnie przemyślanego planu, zmarnujemy ten czas. Tutaj poprawimy literówki, tam dodamy komentarze, gdzieś indziej sformatujemy rozjechany kod. Pousuwamy konkatenacje stringów i wrzucimy w ich miejsce StringBuildera, żeby zwiększyć wydajność (LOL). Pozamieniamy taby na spacje, bo przecież kod w systemie ma być spójny, co nie?
Wreszcie pod koniec, gdy uporamy się z takimi oczywistościami, zabieramy się za faktyczne problemy w designie. I trafiamy na ścianę. Bo… co faktycznie chcemy osiągnąć? Z tym kodem ciężko się pracuje, ale bez konkretnego zadania nie mamy odpowiedniej perspektywy. Robimy wszystko “na zapas”, bez wyraźnej potrzeby podyktowanej ficzerem. Więc… dłubiemy, dłubiemy, dorzucamy wzorczyk jeden czy drugi, wychodzi kod może i ładniejszy, ale… znowu zły.
Może to już nie jest ta świnia wymazana szminką. Może efekt naszej pracy faktycznie łatwiej będzie utrzymać, ale NIE WIEMY jak się sprawdzi w praktyce. Dowiemy się dopiero, gdy przyjdzie odpowiedni task i znowu będziemy musieli ów kod dotknąć. Zmodyfikować. To po to spaliliśmy teraz dwa tygodnie, żeby zaraz znowu dany fragment zmieniać? To tak jak pomalować pokój, a potem powiesić niepasujące firanki. Firanek ruszyć nie możemy – bo to ficzer. Więc ponownie przemalowujemy pokój. Jest prościej, bo ściany już wygładzone, podkład położony, ręce rozruszane, wałki kupione, ale… gdzie tu sens?
Jak inaczej? CR – Continuous Refactoring
Jakość kodu to nie jest wartość, którą da się zbudować dzikim dwutygodniowym refaktoringiem raz do roku. System świątecznych porządków się nie sprawdzi. W domu sprzątam, żeby nie było syfu – to jest cel. W kodzie… niekoniecznie. Syf mi nie przeszkadza, dopóki robi swoje i nie muszę go tykać.
Jedyny sposób na zapewnienie sobie utrzymywalnego, sprawiającego frajdę kodu, to ciągłe dbanie o jego jakość. To zastanawianie się przy każdym zadaniu: jakie będzie najlepsze rozwiązanie tego problemu? I jakie drobne zmiany muszę wprowadzić w już napisanym kodzie, żeby je zastosować? Przy takim podejściu nie trzeba rozpiżdżać wszystkiego w drobny mak i przepisywać tysięcy linii kodu. Ewolucja, a nie rewolucja jest kluczem do sukcesu.
Oczywiście, zadania będą wykonane nieco dłużej. NIECO, a nie kilkukrotnie dłużej. Ale porządna robota potrzebuje czasu, o czym zresztą wszyscy doskonale wiemy obserwując remonty NOWYCH autostrad w naszym pięknym kraju. Co ważne: ten czas dodany do realizacji tasków w profesjonalny sposób jest inwestycją, a nie czasem spalonym. To się zwraca. Te inwestycje się potęgują, wspierają wzajemnie.
Postanowienie poprawy
Następnym razem nie bądź tępym generatorem kodu. Nie doklejaj bezmyślnie kolejnych warstw kupy na śmierdzący kopiec. Nie masz tego dość?
Zamiast tego: PRZED napisaniem kodu zastanów się, jak możesz zrobić swoją robotę prawdziwie profesjonalnie. I co Cię przed tym powstrzymuje. A następnie: zwalcz te przeszkody. Da się! I na dłuższą metę wszyscy będą zadowoleni.
Pro tip: gapienie się w monitor przez 30 sekund nie podpada pod definicję “zastanów się”.
Pro tip 2: przesłuchaj “DevTalk#41 – O legacy code z Jarosławem Pałką“.
