Przed refaktoryzacją

Oryginalny tytuł: Before You Refactor

Autor: Rajith Attapattu

W pewnym momencie, każdy programista będzie odczuwał potrzebę refaktoryzacji istniejącego kodu. Ale przed rozpoczęciem, proszę, pomyśl o następujących rzeczach, ponieważ mogą one zaoszczędzić Ci sporo czasu (i bólu):

• Najlepszym sposobem na rozpoczęcie restrukturyzacji jest ocena istniejącego kodu oraz testów do niego napisanych. To pomoże Ci zrozumieć słabe oraz dobre strony kodu na daną chwilę, abyś mógł upewnić się, iż zachowasz atuty, a usuniesz błędy. Wszyscy myślimy, że można zrobić coś lepiej, niż jest to aktualnie zrobione... dopóki nie skończymy z czymś nie lepszym - a nawet gorszym - niż poprzednie wcielenie, ponieważ nie nauczyliśmy się na błędach istniejącego systemu.
• Unikaj pokusy przepisania wszystkiego. Najlepiej jest ponownie użyć największej możliwej ilości kodu. Niezależnie od tego jak brzydki ten kod jest, został on już przetestowany, przejrzany, itd. Wyrzucenie starego kodu - a szczególnie jeśli był on wdrożony produkcyjnie - oznacza wyrzucenie miesięcy (bądź lat) przetestowanego, zahartowanego w boju kodu, który może posiadać pewne obejścia oraz poprawki, których nie jesteś świadomy. Jeśli nie weźmiesz tego pod uwagę, nowy kod może zawierać te same tajemnicze błędy, które zostały naprawione w poprzedniej wersji. Zmarnujesz mnóstwo czasu, zachodu i wiedzy zdobytej przez lata.
• Wiele przyrostowych zmian jest lepszych niż jedna olbrzymia zmiana. Zmiany przyrostowe pozwolą Ci określić wpływ na system w łatwiejszy sposób poprzez informacje zwrotne pochodzące na przykład z testów. Niefajnie jest widzieć setki nieprzechodzących testów po wprowadzeniu zmiany. To może prowadzić do frustracji oraz nacisku, które z kolei mogą przełożyć się na złe decyzje. Kilka nieprzechodzących testów w danej chwili jest łatwiejsze do ogarnięcia, co z kolei prowadzi do bardziej uporządkowanego podejścia.
• Ważnym jest, aby po każdej iteracji upewnić się, że wszystkie istniejące testy przechodzą. Dodaj nowe testy, jeśli istniejące niewystarczająco pokrywają zmiany, których dokonałeś. Nie wyrzucaj testów do starego kodu bez stosownego rozważenia. Na pierwszy rzut oka niektóre testy mogą wydawać się niepotrzebne w kontekście Twojego nowego kodu, ale warto poświęcić trochę czasu na dowiedzenie się, dlaczego dany test został kiedyś dodany.
• Osobiste preferencje oraz ego nie powinny wchodzić w drogę. Jeśli coś nie jest zepsute, to po co naprawiać? To, że styl bądź struktura kodu Ci nie odpowiadają, nie jest wystarczającym powodem do restrukturyzacji. Świadomość tego, iż mógłbyś zrobić to lepiej niż poprzedni programista, również nie jest dobrym powodem.
• Nowa technologia nie jest wystarczającym powodem do refaktoryzacji. Jednym z najgorszych powodów do refaktoryzacji jest to, że obecny kod jest daleko za wszystkimi super technologiami, które są obecnie dostępne i uważamy, iż nowy język bądź framework potrafi poradzić sobie z niektórymi rzeczami w bardziej elegancki sposób. O ile analiza zysku nie wykaże, iż nowy język czy framework przyniesie zyski w funkcjonalnościach, łatwości konserwacji, czy produktywności, najlepiej jest zostawić to, takim jakie jest.
• Pamiętaj o tym, iż ludzie popełniają błędy. Restrukturyzacja nigdy nie zagwarantuje tego, że nowy kod będzie lepszy niż - albo nawet tak dobry jak - poprzednie podejście. Sam widziałem i byłem częścią kilku podejść do restrukturyzacji zakończonych porażką. Nie było to piękne, ale za to ludzkie.

Artykuł został opublikowany na licencji Creative Commons Uznanie Autorstwa 3.0.

Tłumaczenie: rafek

Komentarze (5)

kilas pisze:

20-07-2010 00:35:49

Właśnie niedługo zamierzam rozbudowywać istnieją już stronę internetową, która jak na razie sprawdza się całkiem dobrze. Jednak kod pisany ponad rok temu jest dość prymitywny i myślałem nad refaktoringiem lub ponownym przepisaniem części aplikacji. Niniejszy artykuł sprawił, że będę musiał jeszcze przemyśleć kilka decyzji - te porady dają do myślenia ;)

michal pisze:

20-07-2010 22:15:29

kilas, zauważ, że w tekście jest mowa o kodzie, który posiada napisane testy, jest obiektowy, był wdrożony produkcyjnie. Wg mnie oznacza to, że tego kodu było dużo i nie przepiszesz go w jeden dzień. To zupełnie co innego niż stronka pisana rok temu w strukturalnym php na bazie kilku tutoriali,a przy rozbudowie takiego projektu wychodzą później takie potworki jak masa darmowych cmsów.

Dezyderat pisze:

20-07-2010 23:25:26

Michale. W tekscie nie ma nic o tym, czy kod jest obiektowy, czy nie. I słusznie, bo obiektowoś nie jest wartością samą w sobie, a ścisłe trzymanie się obiektowości w wielu przypadkach powoduje bardzo kiepski kod. Nie wiem dlaczego to podejście jest aż tak często polecane. Zachęcam dla równowagi przeczytać sobie inne spojrzenie na obiektowość w dostępnej w internecie książce "The art of UNIX programming", podrozdział "Unix and Object-Oriented Languages".

michal pisze:

21-07-2010 10:19:04

Wykreśl z mojego komentarza "jest obiektowy", a i tak główny sens zostanie zachowany ;). Faktem tylko jest, że znacząca większość produkowanego obecnie kodu jest obiektowa i jestem w 99% pewny, że taki kod miał na myśli autor.

kilas pisze:

23-07-2010 18:02:44

@Michał: to fakt, strona po części nadaje się do ponownego przepisania, po części jednak mogę wykorzystać istniejącą strukturę. Strona co prawda pisana w PHP, jednak rok temu już była obiektówka w tym języku, więc spokojnie ;) Jednodniówka to też nie jest - pierwsza wersja była budowana ponad miesiąc. Artykuł dobry, ponieważ daje do myślenia i powstrzymuje przed bezmyślnym przepisywaniem wszystkiego od nowa - skoro większość rozwiązań sprawdza się dotychczas, wszelkie zgłoszone błędy były na bieżąco naprawiane i większych problemów z wydajnością też nie ma, to najgorzej nie jest i warto pomyśleć nad refaktoryzacją istniejącego już kodu i adaptacją go z nowymi klasami. Co do testów jednostkowych nie jestem przekonany - w tak średniej wielkości witrynach to chyba byłby przerost formy nad treścią ;) Aplikacja biznesowa, ok, strona hobbystyczna? Raczej nie.

Dodaj komentarz