Jakie błędy i nie doskonałości znalazłem w moim kodzie. Co powoduje, że jest on legacy i potrzebna jest refaktoryzacja.

Zacznijmy od początku kiedy uważam, że należy przystąpić do refaktoryzacji mojego kodu, dobre pytanie na pierwszym miejscu postawił bym rozbudowę kodu, modyfikacje, rozszerzenie, wprowadzanie nowych funkcjonalności. Jest jeszcze zasada skautów (harcerzy), która mówi żebyśmy zostawiali kod lepszym niż go zastaliśmy (Robert C. Martin). Kolejną kwestią jest narzucona jakość kodu oraz code review. Na ostatnim miejscu postawił bym chęć nauki, rozbudowa umiejętności poprawy kodu (kto się lubi bawić takimi rzeczami?;-).

Krótki wstęp do mojej aplikacji

Jest ona napisana w oparciu o wzorzec MVC nie będę go tu opisywał, poświecę mu osobny post który będzie moimi przemyśleniami na temat tego wzorca. Baza stoi na MS SQL-u, dodatkowo zastosowany jest ORM Entity Framework w podejściu Base First (rzadko kto stosuje).

Błędy jakie dostrzegam po rozpoczęciu procesu refaktoryzacji będę pisał w punktach ale kolejność nie oznacza że coś jest ważniejsze od innego:

  1. Wszystko jest w jednym projekcie,
  2. Kontroler jest sprowadzony do roli głównego elementu programu,
  3. Ścisłe powiązanie pomiędzy kontrolerami i innymi klasami,
  4. Powtarzanie kodu,
  5. Nadmiar instrukcji warunkowych i ich zbyt duże zagnieżdżenie,
  6. Zbyt duża ilość Viebag-ów,
  7. Brak testów.

1.Po napisaniu kilku projektów w MVC, obejrzeniu kilku turoriali o dobrym kodzie zauważyłem że właściwym podejściem do tworzenia struktury aplikacji jest jej rozbijanie na moduły pełniące różne funkcje, przykładem jest aplikacja do obsługi maratonu.

2.Dla mnie kontroler jest pomostem między widokiem (zaprezentowaniem danych) a logiką, ostatnimi czasy przyświeca mi cel tworzenia jak najprostszych akcji kontrolera a tym samym lekkich kontrolerów. W przypadku  tego projektu akcje kontrolera brały za dużą odpowiedzialność a kontroler stawał się „god” klasą. Na początku mojej przygody z MVC myślałem że wszystko musi się mieścić w jednym projekcie przecież mam tam utworzone katalogi Model, Controler, View. Z czasem doszedłem do wniosku że te katalogi stworzone są dla początkujących żeby mieli świadomość na czym polega praca z tym wzorcem, a nic nie stoi na przeszkodzie żeby model i logikę trzymać w osobnych projektach spięte w jedną solucje.

3.W moim dążeniu do pisania „dobrego” kodu staram się wdrażać dobre praktyki jedną z nich jest SOLID, nie udało mi się wdrożyć wszystkich zasad w jednej aplikacji ale staram się trzymać kilku z nich, a najważniejszą stało się Dependency Inversion. W ten sposób poprawiam tak kod aby ostatecznie otrzymać luźne powiązania pomiędzy kontrolerem a obiektami (metodami obiektów) które są w nim wykorzystywane.

4.Najłatwiej (zauważyłem u mnie) jest zrobić kopiuj w klei w kodzie, tu się przyda, tam się przyda i zostawić, a poprawię jutro (jutro czyli nigdy). Problem z powtórzonym kodem jest taki że jeżeli zmienimy coś w nim to musimy zmienić we wszystkich miejscach aplikacji. Tu z pomocą przychodzą metody. Co do samej zasady DRY (don`t repeat yourself) ostatnio zostałem oświecony gdyż nie do końca ją zrozumiałem. Owszem nie powinniśmy powtarzać kodu ale ważniejsze od tego jest by nie powtarzać logiki.

5.O instrukcjach napisałem osobnego posta, wydaje mi się że w kodzie znajdę jeszcze wiele takich smaczków znacznie ciekawszych od zaprezentowanych w poście ale tak jak wspominałem należy używać warunków z głową nie przesadzać.

6.Viewbag to prosty sposób na przesłanie czegoś na widok z kontrolera , używanie na pewno nie jest zabronione ale nadużywanie owszem. Czym można zastąpić? w części przypadków poprzez rozszerzenie modelu.

7.Unit testy, refaktoryazja bez nich jest trudna ale możliwa. O wiele łatwiej było by z nimi .

Błędów w architekturze kodu jest więcej, ja dostrzegłem tylko te, rozwiązania też nie są jedyne słuszne, wiele problemów można rozwiązać na wiele sposobów to tylko od nas zależy jaki wybierzemy. Każdy wybór niesie ze sobą jakieś konsekwencje i następstwa, należy o tym pamiętać.

Na koniec w książce „Pragmatyczny programista” znalazłem fragment w którym autor napisał że kod idealny nie istnieje (czysty), dla tego też słowo dobry kod zapakowałem w cudzysłów. Definicja dobrego kodu dla każdego może być różna.

Poniżej kilka przydatnych linków.

P.S. Przeczytałem gdzieś, że refaktoring to „szkoła życia”.