Blog
Blog HelionBlog HelionBlog HelionBlog Helion
  • Artykuły
  • Autorzy
  • Recenzje
  • Konkursy

Nie bój się refaktoryzacji!

    Blog.helion.pl Artykuły Nie bój się refaktoryzacji!
    NastępnyPoprzedni

    Nie bój się refaktoryzacji!

    By Jerzy Piechowiak | Artykuły, Programowanie | Brak komentarzy | 27 kwietnia, 2017 | 0

    Bardzo często w tytułach książek dla programistów można znaleźć określenia typu: „piękny kod”, „czysty kod”, „kod doskonały”, sugerujące, że możliwe jest napisanie programu, którego kod źródłowy jest po prostu idealny. Ale co właściwie znaczy to, że określony fragment, a być może nawet cała aplikacja, ma doskonały kod źródłowy?

    Czy to znaczy, że jest on szybki? Skalowalny? Łatwo rozszerzalny? Używa najnowszych funkcji języka? A może jest wciągający w czytaniu niczym powieści o Harrym Potterze? A może to po prostu rozwiązanie, z którego jesteśmy autentycznie zadowoleni. W końcu każdemu z nas chyba co jakiś czas zdarza się zrobić coś takiego, po czym możemy stwierdzić: „Kurczę, ale to jest dobre!”.

     

    Sam, po prawie dziewięciu latach doświadczenia komercyjnego, dochodzę do wniosku, że trudno jest napisać idealny kod. Przez pewien (początkowy) okres mojej pracy zawodowej zdarzyło mi się napisać fragmenty kodu, których dziś mógłbym się wstydzić:

    • Nagminnie łamałem zasady mnemonika SOLID, który jakiś czas temu opisywałem na tym blogu.
    • Tworzyłem klasy mające setki, a może nawet tysiące linii kodu.
    • Nie stosowałem interfejsów.
    • Nadużywałem dziedziczenia i niepoprawnie z niego korzystałem.
    • Nie stosowałem wzorców projektowych lub nadużywałem antywzorców, takich jak singleton.
    • Wprowadzałem zbyt dużo klas statycznych.

     

    W praktyce mój kod być może i działał całkiem dobrze, ale jakiekolwiek operacje związane z jego rozszerzaniem były bolesne. Oczywiście, gdy po kilku miesiącach wracałem do wcześniej napisanego dzieła, często łapałem się za głowę i zastanawiałem się, co autor miał na myśli. W początkowej fazie mało było takich fragmentów, o których po czasie mógłbym powiedzieć, że byłem z nich zadowolony, choć jest to naturalna kolej rzeczy wynikająca z braku odpowiedniego doświadczenia.

     

    Sytuacja zmieniła się rzecz jasna po jakimś czasie. Było coraz więcej fragmentów, z których, można powiedzieć, byłem dumny, a napisany kod był łatwy w czytaniu.

     

    Ciągłe doskonalenie zaczęło jednak rodzić pytania. Czy jest sens zmierzać w kierunku idealnego kodu? Czy taki kod w ogóle istnieje? Im więcej przeczytanych książek i artykułów, tym więcej pojawia się pytań i możliwości.

     

    Warto sobie czasem zadać pytanie, czy w tworzonej właśnie aplikacji jest sens wprowadzać nadmierne optymalizacje. Od jakiegoś czasu jestem zwolennikiem podejścia, w którym kod jest w miarę możliwości maksymalnie czytelny i skalowalny, ale przede wszystkim podatny na optymalizacje. Niekoniecznie np. będę od razu wprowadzać wzorzec strategii do kilkunastoliniowego switcha. Taka refaktoryzacja na wczesnym etapie doprowadziłaby prawdopodobnie do tego, że powstałoby kilka nowych klas, w których każda miałaby może kilka linijek konkretnego kodu.

    To tylko przykład, ale na początkowym etapie rozwoju aplikacji taka zmiana nie dałaby wymiernych rezultatów, a jedynie utrudniłaby odbiór pozornie prostego programu.

     

    Co zatem robić na co dzień?

    • Stosować stylistykę kodowania zatwierdzoną w firmie.
    • W miarę możliwości stosować reguły z mnemonika SOLID.
    • Unikać klas liczących setki linii kodu.
    • Unikać stosowania klas statycznych.
    • W miarę możliwości korzystać z kontenerów IoC (pisałem ostatnio m.in. o Autofacu oraz Ninject.
    • Tworzyć klasy oparte na interfejsach.

     

    Stosując się do powyższych reguł, z pewnością będziemy w stanie napisać dobry kod, który będzie podatny na modyfikacje.

    Wykorzystując kontener IoC, będziemy mogli usunąć singletona na rzecz klasy zwracanej per żądanie (i odwrotnie). Unikając klas statycznych, zmniejszymy powiązanie poszczególnych elementów. Dzięki temu łatwiej będzie nam wymienić pojedynczą klasę czy też później dopisać testy jednostkowe. Dzięki tworzeniu interfejsów łatwiej będzie nam później wprowadzić inne implementacje czy też zastosować popularne wzorce projektowe.

    Nie musimy więc zatem od razu stworzyć kodu „idealnego”, ale warto stosować się do kilku reguł, dzięki którym nigdy „nie obudzimy się z ręką w nocniku”, a ciągła refaktoryzacja pozwoli nam na uzyskanie docelowo maksymalnie dobrego efektu.

     

    Jerzy Piechowiak

    Altcontroldelete.pl

     


     

     Szukasz informacji o refaktoryzacji? Kliknij TU lub zerknij poniżej:

               

     

    czysty kod, Jerzy Piechowiak, programowanie, refaktoryzacja, SOLID, techniki programowania
    Avatar

    Jerzy Piechowiak

    Więcej postów od Jerzy Piechowiak

    Podobne posty

    • Refaktoryzacja – kiedy jest niezbędna?

      By Helion | Brak komentarzy

      Po co refaktoryzować?   Nie twierdzę, że refaktoryzacja jest lekarstwem na wszelkie programistyczne bolączki. Jednak z pewnością jest wartościowym narzędziem, parą kleszczy, które pozwalają trzymać kod w potrzasku i panować nad nim w pełni. Refaktoryzacja możeCzytaj więcej…

    • Wzorzec projektowy strategii

      By Jerzy Piechowiak | Brak komentarzy

      Programowanie, wbrew obiegowym opiniom, nie jest aż takie trudne. Wypuszczenie nawet prostych aplikacji mobilnych czy stron nie wymaga dzisiaj dużych nakładów sił. Największym problemem jest napisanie takiego kodu, który będzie łatwo rozszerzalny i będzie miałCzytaj więcej…

    • Wzorce projektowe — null object

      By Jerzy Piechowiak | Brak komentarzy

      „Object reference not set to an instance of an object” — taki, pojawiający się w najmniej oczekiwanym momencie komunikat to zmora każdego programisty C#. Przyczyna jest zawsze taka sama, a jest nią wyjątek NullReferenceException.

    • Mnemonik SOLID – D jak Dependency Inversion Principle

      By Jerzy Piechowiak | Brak komentarzy

      Przyszła pora na ostatnią literkę z mnemonika SOLID, ale to wcale nie oznacza, że jest ona najmniej ważna. D rozwijane jest jako Dependency Inversion Principle co tłumaczone jest jako Zasada Odwrócenia Zależności.

    • Mnemonik SOLID – I jak Interface segregation principle

      By Jerzy Piechowiak | 1 komentarz

      W poprzednich wpisach poświęconych SOLID, niejednokrotnie pojawiały się wzmianki o interfejsach. Osobiście jestem ich gorącym zwolennikiem, ale wszystkiego trzeba używać z głową. Tego nauczy Was życie.. i w tym przypadku właśnie czwarta zasada z mnemonikuCzytaj więcej…

    NastępnyPoprzedni

    Znajdź post

    Bądźmy w kontakcie

    Książka dnia

    Python. Wprowadzenie. Wydanie V

    Autor: Mark Lutz

    Cena: 118.30 zł 169.00 zł
    (Cena e-booka: zł zł)

    O 51zł taniej!

    kup teraz

    Najnowsze wpisy

    • Błyskawiczny kurs pisania skryptów powłoki
    • Przykładowa aplikacja webowa zaimplementowana w ASP .NET Core
    • Wprowadzenie do .NET Core: instalacja, konfiguracja, pierwsza aplikacja w systemie Linux
    • Grupa Helion zaprasza na szkolenia stacjonarne!
    • Hello World! Czym jest programowanie?

    Tagi

    .net agile altcontroldelete asp.net c# czysty kod debugowanie design patterns e-biznes emarketing Google Google Analytics hacking Jerzy Piechowiak kod kodowanie Krzysztof Marzec książka Maciej Dutko magazyn programista Magdalena Daniłoś marketing MVVM onepress organizacja czasu praca prograista programista programowanie prokrastynacja rafał kocisz reklama rozwój software craftsman SOLID startup techniki programowania testowanie video marketing visual studio WPF wzorce projektowe youtube zarządzanie czasem zarządzanie projektami

    Archiwum

    • Lipiec 2017
    • Czerwiec 2017
    • Maj 2017
    • Kwiecień 2017
    • Marzec 2017
    • Luty 2017
    • Styczeń 2017
    • Grudzień 2016
    • Listopad 2016
    • Październik 2016
    • Wrzesień 2016
    • Lipiec 2016
    • Czerwiec 2016
    Blog wydawnictwa
    Informatyka w najlepszym wydaniu
    Strona wydawcy:
    www.helion.pl
    Księgarnia Helion.pl
    Nowości
    Bestsellery
    Promocje
    Bądźmy w kontakcie:
    Chcesz zostać autorem?
    Masz pytania do redakcji?
    Napisz do nas »
    • Artykuły
    • Autorzy
    • Recenzje
    • Konkursy
    Blog Helion