devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
6 minut

Refactoring sprint? Plażo, please…


15.11.2016

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?

Akcja: BLOGvember! Post nr 11.
W listopadzie w każdy roboczy poranek na devstyle.pl znajdziesz nowy, świeżutki tekst. W sam raz do porannej kawy na dobry początek dnia.
Miłej lektury i do przeczytania jutro! :)

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.

W tekście “3 sprawdzone sposoby na wprowadzanie testów do istniejącego kodu” liznąłem 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ą“.

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit
Notify of
Darek
Darek

W tym temacie można polecić świetną książkę: “Working Effectively with Legacy Code” Michael’a Feathers’a

Rafał
Rafał

Continuous Refactoring, niby oczywiste, najlepsze rozwiązanie, praktycznie bez wad, oprócz odrobiny więcej czasu dodanego do wyceny zadania, a jednak rzadko stosowany w projektach w których dotychczas miałem okazje pracować. Chyba zacznę ‘przemycać’ trochę czasu przy każdym zadaniu na taki refaktor. Sam wpis świetny jak zawsze :)

Mateusz Pustelak

Wedlug mnie najlepszym sposobem na pisanie dobrego kodu i wspomnianego CR jest code review. Nic bardziej nie zmusi programisty do przemyslenia tego, co i jak chce napisac niz pozniejszy wglad w jego kod przez innych, najlepiej bardziej doswiadczonych (i nie mowie tutaj o X latach klepania kodu) kolegach. Jezeli taka osoba bedzie pisala slabo, ktos powinien na to zwrocic uwage i przedstawic standardy jakie powinny sie pojawic. W firmie, w ktorej obecnie pracuje mamy pewne standardy co do klepania, glownie utrzymywania kodu. Przed rozpoczeciem pracy nad zadaniem zastanawiamy sie, czy mozna w tym fragmencie cos poprawic i jak mozna to… Read more »

Kos

Stosujemy w zespole CR, ale nie zawsze wystarcza. Uwzględnianie refaktoru w planie implementacji ficzerów to w zasadzie bardzo logiczna rzecz i aż dziwne, że kogoś to zaskakuje. Dostałaś nowe wymagania – masz wybór: albo dostosowujesz do nich architekturę systemu, albo na szybko doklejasz nowy kod do reszty taśmą klejącą. Bardzo o tym było ładnie napisane tutaj: http://ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog/ Mimo tego są pewne zmiany, które są po prostu zbyt duże, by wprowadzać je w ten sposób. Np odważnie wybrałeś do projektu frontendowy framework X, a pół roku później okazuje się że hype na X minął i bardziej przeszkadza niż pomaga, podczas gdy… Read more »

devamator
devamator

Za czasów studiów wbijali mi do głowy, że wszystko można zrobić dokładniej, dopieszczać w nieskończoność, ale dobry inżynier to taki, który potrafi określić kiedy jest “good enough”.
Podkreślę jeden ważny aspekt, który poruszyłeś, a często nie zwracamy na niego uwagi. Nie ma co za wcześnie refaktoryzować kodu, który jest na styku kilku zadań i będzie modyfikowany przy każdym z nich. Szkoda czasu i wysiłku.

trackback

[…] “na refactoring” póki co odłożymy na bok. Zajmiemy się tym innym razem (EDIT: tutaj pojawił się post na ten temat). Póki co: założymy, że zespoły są skłonne negocjować godziny, dni czy nawet […]

Szymon Kulec 'Scooletz'

Moim ulubionym pojęciem jest “hardening sprint”, co tłumaczy się zazwyczaj na polski jako “sprint utwardzający”. Trochę szersze pojęcie, trochę inne od “Refactoring sprint” ale pokazuje tą samą denną mentalność. Lepmy z piachu a potem się utwardzi na beton.
Bardzo dobry post!

Namek

U nas w trudnościach z komunikacją zastosowaliśmy taktykę, że jak trzeba refactor, to trudno, sprzątamy, ale jak trzeba “ficzer na czwartek” to mówiliśmy – OK, zrobimy to teraz tak, żeby było, ale zaraz po tym musimy zrobić to dobrze, aby nie mieć w przyszłości długu. Czyli zamiast informować daleko PO to informowaliśmy PRZED. Taki trochę środek antycośtam.

Moja książka

Facebook

Zobacz również