Extract Method i Composed Method

Nie ma znaczenia czy idziemy do sklepu coś kupić, czy zamawiamy potrzebną nam usługę – wszyscy oczekujemy że finalny produkt będzie wysokiej jakości. Nie ważne czy jest to para nowych butów, czy posiłek w restauracji. Jako programiści, my także powinniśmy troszczyć się o określone standardy, gdy wytwarzamy swoje dzieła – aplikacje.

Kod dobrej jakości jest tani w utrzymaniu, i nic tego nie zmieni. Zawsze powinniśmy stosować dobre praktyki, nawet jeśli projekt jest malutki i utworzenie go wydaje się być kwestią kilku dni. Można wtedy usłyszeć, że dbałość o szczegóły i tworzenie małych metod to strata czasu.

Nie ma większego kłamstwa.

Pamiętam jak dwa lata temu trafił mi się taki 3-dniowy projekcik, do którego miałem potem nie wrócić. Pomyślałem – po co mam się starać utrzymać wysoką jakość, skoro mogę go odwalić na szybko, byle działało.

Nagle okazało się, że używają go pracownicy we wszystkich oddziałach w kraju i wymaga ‚kilku ulepszeń’. I tak każdego następnego miesiąca – ‚ostatnia’ iteracja (na pewno!), zwiększała rozmiar moich klas i powodowała że debugowanie było koszmarem. Projekt jest rozwijany do dzisiaj.

Nigdy więcej.

Extract Method

Zasada jest dość prosta:

Jeśli masz fragment kodu, który może być logicznie zgrupowany – zrób z niego funkcję.

Jedną z najlepszych praktyk jest ciągłe rozbijanie naszych metod, aby były najkrótsze jak to tylko możliwe. Oczywiście ktoś może powiedzieć, że jeśli mamy czytelny kod, to nie ma sensu wyciągać takich 10-linijkowców na zewnątrz. Nie zgodzę się z tym, ponieważ używając tej techniki otrzymujemy krótkie funkcje, których nazwy – bez dłuższej analizy – poinformują nas czego możemy się po nich spodziewać.

Pomoże to także ograniczyć ilość komentarzy w kodzie do minimum.

Refaktoryzacja nie zawsze oznacza zmniejszenie ilości naszego kodu. Chodzi także o uczynienie go bardziej czytelnym. W nowoczesnych środowiskach programistycznych powinniśmy definiować nazwy jasno określające cel metod i zmiennych – nawet jeśli są długie. IDE po wpisaniu paru znaków i tak podpowie nam ich zakończenie.

Composed Method

Ta praktyka pomoże nam uniknąć tzw. ‚Arrow Code’ (zagnieżdzone if if if…, które przypominają grot strzały). Wymaga ona utworzenia głównej funkcji, która wywołuje po kolei krótkie metody, jedną po drugiej. Każda powinna mieć tylko jeden, jasno zdefiniowany cel.

Musimy tutaj operować na tym samym poziomie abstrakcji. Nie możemy używać pętli w głównej metodzie. Tylko krótka seria mniejszych, czasem jakiś if, ale pod warunkiem że nie będzie zagnieżdzony.

To także doskonała okazja do utworzenia uniwersalnych funkcji, które usuną nam duplikaty w kodzie.

Demo

Karol napisał pewnego pięknego dnia, taką metodę:

Wygląda normalnie, ale mogłaby wyglądać tak:

Przykład może mało ambitny, ale ukazujący podstawowe założenie.

Podsumowując

  1. Metody powinny być krótkie, czytelne, wykonywać jedno zadanie i mieć dobrze dopasowaną nazwę (mówiącą nam o ich przeznaczeniu). Dzięki temu zaoszczędzą nasz czas i nerwy. Czasami nawet nie będziemy musieli ich debugować, aby wyłapać błędy.
  2. Bardzo prawdopodbnym jest, że jeśli utworzymy krótkie i uniwersalne metody, wywołamy je więcej niż raz. Pozorne zwiększenie ilości kodu, tak naprawdę pomoże nam go zredukować (jeśli wyłapiemy duplikaty).
  3. Wspomniane techniki mogą być stosowane w dowolnym momencie cyklu rozwoju aplikacji, w nowych i istniejących już projektach. Prawdopodobnie pomogą także przy TDD.
  4. Jak we wszystkim w życiu – tu także musimy znać umiar. Rozbijanie 10-linjkowej funkcji do 10 1-liniowych raczej nie uczyni naszego kodu bardziej czytelnym.

Sprawdź też