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.
