Pracujesz w scrumie? Częścią tego procesu jest planowanie. Czy w nie wierzysz? A zawsze wierzyłeś? Jestem pewnien, że byłeś w projekcie, gdzie niezależnie od wyniku planowania, nie dowoziliście wszystkiego. Dlaczego tak się dzieje? To może być wina niedbania o kod źródłowy. Jak to? Tak to! Zapraszam :).

Ciężka analiza

Estymowałeś zadanie na trzy godziny. Po czterech jesteś w połowie… analizy kodu, gdzie planujesz zmiany. Czytasz, myślisz, dumasz. Czacha Ci paruje, a rozwiązania wciąż niema. Na usta się ciśnie, by powiedzieć „Kto to panu tak …”. Znasz to? Na pewno. Każdy zna.

Tak wygląda sytuacja, gdy mamy do czynienia z obrzydliwie napisanym kodem. Każda linijka domaga się dogłębnego przeanalizowania, a co trzecia wytrąca Cię z kontekstu. Jak więc się dziwić, że nawet malutka zmiana, może ciągnąć się tygodniami.

Rozmyta odpowiedzialność

Zaczyna się niewinnie. Mała zmiana na poziomie UI. Dwie godzinki i pozamiatane? Prawda? Wprost przeciwnie!

Gdy wchodzisz w kod, sytuacja się komplikuje. Przedzierasz się przez kolejne warstwy serwisów, repozytoriów, commonów, helperów, fasad, dali i kontrolerów. Są one do siebie podobne, technicznie jednolite. Tak jak opisywałem poście o tęczowej brei.

Odpowiedzialności poszczególnych tworów są tak rozmyte, że biedny programista musi się długo zastanawiać, gdzie dodać nowy kod. Która warstwa jest właściwa. Jak to przetestować?

Sztywne zależności

Dlaczego nie mogę spuścić wody? Bo sąsiad ogląda telewizor! W budowlance jest to abstrakcja. W świecie oprogramowania niestety się zdarza.

Zmiana w jednym miejscu wymusza modyfikację w innym, a ta w innym, co implikuje jeszcze więcej zmian. W takich przypadkach czas dewelopmentu rośnie bez umiaru.

Pół biedy, gdy kod jest w jednym repozytorium. W przeciwnym wypadku kompilator nie poinformuje o błędach kompilacji. Jak to zaplanować? Być może to nie w planowaniu jest problem, jak zatem do tego podejść?

A jak naprawić?

Cóż. Mając zły kod, planowania nie naprawisz, ale możesz zająć się przyczyną. Powolutku, ale systematycznie. Możesz wybrać jedną z poniższych dróg lub poszukaj własnej.

• Metoda małych kroczków. Za każdym razem, gdy dotykasz lub analizujesz kod, wprowadzaj małe zmiany. Nie rób rewolucji. Skoro ten kod działa i zarabia pieniądze to szkoda, by go zniszczyć. Ważne, byś zachował tendencję wzrostową.
• Zostaw go w spokoju. Nie dotykaj, jeżeli nie musisz. Stwórz obok nowy projekt. Z testami, z ładną architekturą, a wszystkie nowe funkcjonalności dodawaj właśnie tu, a tamtego nie ruszaj. Niech zarabia.
• Połącz obie drogi. Stwórz nowy projekt na nowy kod i nowe funkcjonalności. Równolegle usprawniaj ten brzydki.

To wszystko?

Na dzisiaj tak. Miej na uwadze, że brudny kod to tylko jeden z potencjalnych powodów niewiarygodnego planowania. Może się na to skłaniać brak lub kiepskie wymagania, małe doświadczenie zespołu, czy zły dobór procesów lub narzędzi.

A co Ty uważasz na ten temat? Masz może coś do dodania? Będę niezmiernie szczęśliwy, jeżeli się tym podzielisz. Tu, poniżej :).