O porządkach w kodzie

Z racji tego, że święta już niebawem, dziś będzie coś o sprzątaniu, tyle że w kodzie 😉 . Refaktoryzacja jest tematem dość kontrowersyjnym. Jedni jej unikają twierdząc, że to kompletna strata czasu, inni poświęcają na nią całe sprinty. Z punktu widzenia wydajności tworzenia oprogramowania, wydawać by się mogło, że nie ma czasu na refaktoryzację. Trzeba przecież klepać nowe ‚ficzery’, nawet jeżeli wymaga to przedzierania się przez kod niczym przez dżunglę z maczetą (dla programistów z Krakowa to zapewne nie problem 😀 ).  Pytanie tylko czy można efektywnie pracować dłubiąc w spaghetti.

Kiedy najlepiej robić refaktoryzację?

Poświęcanie całych sprintów na refaktoryzację moim zdaniem nie jest najlepszym pomysłem. Może to mieć sens, jeżeli naprawdę potrzebujemy zrobić grubszą zmianę w strukturze aplikacji. Jednak plan typu: od dziś wszyscy rzucamy się do refaktoryzacji i przez dwa tygodnie przeglądamy chaotycznie kod szukając miejsc, gdzie można coś upiększyć, jest kompletnie bez sensu i najprawdopodobniej będą to stracone dwa tygodnie. Że o czasie poświęconym na przekonywanie biznesu do takiego sprintu nie wspomnę.

Jak to zwykle bywa racja wydaje się leżeć gdzieś po środku. Zamiast refaktoryzować kod, do którego szansa, że ktoś kiedyś wróci jest dość nikła (chyba każdy system ma takie miejsca, które zostały raz zrobione i od tej pory nikt tam nie zagląda), refaktoryzuj kod, z którego będziesz korzystał na pewno, czyli kod, nad którym aktualnie pracujesz.

Skoro już i tak musisz poświęcić czas, energię i zdrowie psychiczne na zrozumienie metody, zajmującej trzy ekrany z kilkukrotnie zagnieżdżonymi if’ami, którą okrutny los właśnie postawił na Twojej drodze, to przynajmniej oszczędź tej wątpliwej przyjemności komuś, kto w przyszłości będzie musiał tu zajrzeć. Zamiast rozpisywać sobie logikę tej metody gdzieś na kartce, albo próbować zapamiętać w głowie, lepiej będzie rozkładać ją kawałek po kawałku na mniejsze fragmenty, umieszczane w osobnych, odpowiednio nazwanych metodach. Dzięki temu jak naglę ktoś wpadnie z mega pilną sprawą, wyrywając Cie na chwile z kontekstu, nie będziesz musiał później analizować tej metody od początku. Dodatkowo, analiza tego fragmentu pójdzie znacznie szybciej kolejnym osobom. Tego typu refaktoryzacja nie jest specjalnie kosztowna i czasochłonna, a w przyszłości ma szansę się zwrócić ze sporą nawiązką.

Warto, a nawet trzeba, refaktoryzować także swój kod przed każdym commitem. Niby oczywiste, ale ciągle natrafiam (i wy pewnie również) na fragmenty kodu, które wyglądają jakby ktoś je wbił bez cienia refleksji, uradowany tym, że wreszcie zaczęło działać i ma kolejnego taska z głowy. A wystarczy poświęcić raptem kilka, maksymalnie kilkanaście minut, aby raz jeszcze przeanalizować swój kod przed wbitką by żyło się lepiej… wszystkim.

A o refaktoryzacji od strony praktyczniej już w kolejnych wpisach 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *