7 wskazówek jak sprawdzić jakość kodu nie będąc programistą

fot. unsplash.com

Po pierwsze profilaktyka

Zanim nawiążesz współpracę warto sprawdzić swojego potencjalnego współpracownika pod kątem jakości kodu. Jak to zrobić? Poproś go o próbki kodu udostępnionego prywatnie lub na serwisie typu github. Kod sprawdź uzyskanym kluczem lub poproś doświadczonego programistę o wstępną ocenę.

Co wpływa na złą jakość kodu?

Jest kilka przyczyn, które wpływają na złą jakość kodu i nie zawsze jest to niedbalstwo wykonawcy. Ty również jako osoba zlecająca możesz przyczynić się do obniżenia jakości kodu. Wpływa na to:

• zbyt krótki termin realizacji

• źle rozplanowany projekt, specyfikacja robiona w biegu

• domykanie projektu kolanem – ograniczony budżet, programista dopisuje kolejne zmiany przy tym samym budżecie.

• gdzie programistów sześć tam…. zły kod. Staraj się zachować znany Ci, stały zespół.

• projekt/współpraca z Tobą  jest jednorazowa

• poznaj podstawy programowania w języku, w którym Twój projekt jest wykonywany

Dlaczego nie lubimy złego kodu?

Powodów jest kilka i są dość bolesne biznesowo:

• rozwój i utrzymanie kodu jest drogie

• czasami wszystko wymaga napisania od nowa

• trudno znaleźć programistów chętnych do pracy na złym kodzie

• może zatrzymać lub spowolnić rozwój biznesu

• obniżone bezpieczeństwo

• generuje trudne do zlokalizowania błędy

Bałagan w kodzie

Otwórz parę plików i przejrzyj je. Jeśli zamiast ładnego, regularnie ułożonego tekstu, którego w ogóle nie rozumiesz

ZObaczysz Bałagan        z którego już w

ogÓŁE nic nie umiesz wyczytać, rozumieć, interpretować,

CZY DOJRZEć jakieś logiki

to poinformuj wykonawcę, że to Cię niepokoi.

Nazwy i konwencja nazewnictwa

Jeśli w jakiś sposób miałeś do czynienia z programowaniem to wiesz co to są funkcje i zmienne. Jeśli masz z tym problem 5 minutowa lektura jakiekolwiek poradnika pozwoli Ci na rozpoznanie w badanym kodzie funkcji, klas, zmiennych. Co powinno Cię zaniepokoić

• zapis nie po angielsku

• niezrozumiałe nazwy np: xyz() zamiast addUser()

• niekonsekwencja w formie zapisu np. nazwafunkcji, nazwa_funkcji, nazwaFunkcji

<!– Nadużywanie komentarzy –>

Mogłyby się wydać, że /*komentarze w kodzie z opisem działania wszystkiego*/ to dobra praktyka. No cóż nie dokońca, w szczególności jeśli wykonawca miał problemy w poprzednim akapicie i próbował nadrabiać komentarzami. Ostatecznie kod powinien być zrozumiały bez dodatkowego opisu, jeśli jest to niemożliwe wtedy powinny być zastosowane komentarze.

Co za dużo technologii to niezdrowo

Jeśli Wasz wykonawca radzi wykorzystanie wielu technologii trzeba byłoby się zastanowić, czy wszystkie są konieczne i w szerszym gronie zweryfikować to. Jeśli będziemy duplikować technologie, które mogą nam wykonać te same zadania doprowadzimy do zbędnego skomplikowania kodu, a także nasza strona będzie cięższa i bardziej awaryjna.

Nowa technologia lub stara, ale jare

Bardzo łatwo sprawdzić czy wykonawca użyje technologii, której nauczył się X lat temu i nadal ją próbuje wpychać klientom, czy też próbuje nas przekonać do nowinek. W obu przypadkach możemy mieć problemy z utrzymaniem naszego serwisu.

Zobacz jak prowadzone jest repozytorium

W przypadku tworzenia stron WWW nie wymagałbym prowadzenia repozytorium, ale jeśli masz do niego dostęp, pozwoli Ci to na bieżąco śledzić postęp prac, ale także po tzw. commitach i ich opisie możesz ocenić jak jest projekt prowadzony. Jeśli opis commita jest bezsensowny, nie przekazuje żadnej informacji, może być w przyszłości trudny do odnalezienia.

Zapytaj o testy

W przypadku aplikacji równolegle powinny być pisane m.in. testy jednostkowe, które mają za zadanie przyspieszyć sprawdzanie kodu i też wg. mnie wymuszają większą dbałość o jakość.

Jeśli właśnie wrobiłem Waszego programistę….

bo zmotywowałam Was do sprawdzenia jakości kodu, to przepraszam za spowodowany problem. W zależności od Waszych umów i zobowiązań, należałoby wskazać przyczyny złego jakościowo kodu i nakreślić plan naprawczy i go najszybciej wdrożyć, aby nadal nie brnąć w tą ślepą uliczkę.

A na koniec życzę Wam samych udanych projektów z dobrym jakościowo kodem 🙂

–

Bartosz Wojdon  

CEO, Designer, Developer w Codenest  

Webdeveloper z zawodu. Podróżnik z zamiłowania. Nieudany reżyser z pasji. Inżynier Budownictwa z wykształcenia. Na co dzień wysiaduje kod w codenest.pl, gdzie wykluwają się świeżutkie strony internetowe i aplikacje webowe dostosowane do wymagań Waszych Klientów.