Po czym poznać, że kod JavaScript jest najwyższej jakości?

Będąc programistą w dzisiejszych czasach, mającym już jakieś doświadczenie zawodowe, trudno się nie spotkać z pojęciem jakości kodu. Gdyby odpytać każdego web developera po czym poznać jakościowy kod, to odpowiedzi będzie wiele.

Jest jednak kilka odpowiedzi, które się powtarzają i to na nich będę chciał się skupić.

Section 1Standardy kodowania

Czym są standardy kodowania. Jest to zestaw reguł dotyczących stylu pisania kodu, które musi spełniać kod napisany przez każdego programistę w danej firmie czy w danym projekcie. Dzięki temu, kod może być z łatwością odczytany przez innego programistę w zespole. Zachowując ten sam styl pisania kodu, sprawiamy że ewentualne szukanie błędów jest trochę łatwiejsze i na starcie nie musimy martwic się o nieodpowiednio sformatowany kod.

Do zasad określających standardy pisania kodu możemy zaliczyć między innymi:

• używanie 4 spacji zamiast 1 taba,
• umieszczanie deklaracji zmiennych na samym początku funkcji zamiast rozmieszczania ich w dowolnym miejscu w zależności od widzimisię programisty,
• sposób nazywania metod i zmiennych.

Tego typu zasad może być i jest ich więcej. Każdy zespół definiuje wg jakich reguł będzie pisany kod. W sytuacji, gdy mamy do czynienia z opornymi programistami (a są tacy, którzy za wszelką cenę chcą się trzymać swojego sposobu pisania kodu), możemy się wspomóc automatami do analizy kodu i automatycznego jego poprawiania. To może ułatwić życie całemu zespołowi sprawiając że kod będzie czytelniejszy dla każdego.

Innym sposobem weryfikacji standardów kodowania jest wykorzystywanie narzędzi, tzw. linterów, które podczas pisania kodu wskazują miejsca, gdzie kod jest niezgodny z założeniami, np. stosowanie normalnego porównania - ==, zamiast porównania typu stricte - ===. Tego typu narzędzia pozwalają też wykryć ewentualne błędy w kodzie. Jednym z takich narzędzi jest na przykład JSHint.

Section 2Pokrycie kodu testami jednostkowymi

Inną miarą jakości kodu, może być sprawdzenie czy napisany przez nas kod został pokryty w 100% testami jednostkowymi. Jest to dobre podejście, ale ma swoje wady. Mechanizm wykrywania stopnia pokrycia kodu testami jednostkowymi można łatwo oszukac pisząc testy, które sprawdzą tylko i wyłącznie ścieżkę działania kodu, która zawsze przechodzi. Tym samym, łatwo można pominąc miejsca w których dzieje się coś ważnego i powinno byc dobrze przetestowane. Jednym z takich narzędzi do sprawdzania pokrycia kodu testami jest Istanbul.js

Osobiście nie polegałbym na tej mierze jako wskaźniku jakościowego kodu. Lecz skupiłbym się na analizie testów jednostkowych podczas przeprowadzania code review i sprawdzeniu czy wszystkie zakładane przypadki użycia zostały przetestowane (o ile to możliwe). Dzięki temu, będziemy pewniejsi że w kodzie nie ma krytycznych błędów.

Section 3Spełnianie wymagań funkcjonalności a optymalny kod

Bardzo często spotykam się z sytuacją, że osoba zajmująca się wybranym zadaniem skupia się na tym, aby kod działał i spełniał wymagane kryteria akceptacji ze strony project managerów - kierowników projektu, i zupełnie zapomina o tym, aby do tego samego kodu wrócić po jakimś czasie i go zoptymalizować. Przez to można mieć do czynienia z istną puszką Pandory, czyli kodem który z biegiem czasu będzie coraz trudniejszy do utrzymania, bo będzie rósł tzw. dług techniczny - czyli ogólnie mówiąc zbiór problemów powstałych podczas tworzenia oprogramowania, które nie zostały rozwiązane w trakcie procesu tworzenia kodu a które powodują, że dalszy rozwój kodu o nowe rzeczy będzie bardzo trudny bądź niemożliwy. Należy unikać zbyt dużego długu technicznego.

Dług techniczny - zbiór problemów powstałych podczas tworzenia oprogramowania, które nie zostały rozwiązane w trakcie procesu tworzenia kodu a które powodują, że dalszy rozwój kodu o nowe rzeczy będzie bardzo trudny bądź niemożliwy.

Na czym może polegać optymalizacja kodu? Może polegać między innymi na:

• cachowaniu wartości zmiennych,
• refaktoryzacji kodu metod, aby były krótsze i robiły tylko jedną rzecz na raz,
• unikaniu tzw. callback hell, czyli sytuacji gdy mamy do czynienia z zagnieżdżonymi funkcjami wywołującymi inne funkcje:
  

Section 4Podsumowanie

Zdaję sobie sprawę z tego, że powyższe kilka punktów nie wyczerpuje definicji jakościowego kodu. Tak naprawdę, to każdy zespół, każda firma sama definiuje wymaganą poziom jakości kodu. W każdej firmie/projekcie może być brane pod uwagę co innego. Lecz tak jak wspomniałem na początku, powyższe 3 punkty pojawiały się najczęściej.

Jeśli masz uwagi odnośnie powyższych definicji, bądź chcesz się podzielić swoimi spostrzeżeniami to zapraszam do komentowania.