Jakość kodu wskazuje, jak dobrze kod jest napisany i czytelny. Jakość kodu jest subiektywna, a różne branże, organizacje i zespoły różnie definiują jakość kodu. Wysokiej jakości kod może mieć wpływ na efektywność działania zespołów i organizacji. Często jakość kodu jest trudna do określenia przez zespół programistów na dużą skalę.
W tym artykule chciałbym przedstawić pięć wyzwań stojących przed zespołami wdrażającymi oprogramowanie:
- łatwość konserwacji
- skalowalność
- testowalność
- czytelność
- wydajność
Dlaczego jakość kodu jest ważna
Każdy projekt jest łatwy i zrozumiały dla każdego (na początku) Następnie programiści podejmują różne decyzje, które wpływają na jakość kodu.
Na początku projektu ludzie są zazwyczaj zadowoleni, a praca idzie gładko. Z czasem tempo spada, a uśmiech znika.
- puk puk
- Kto tam jest?
- dług techniczny
Ostatecznie deweloperzy są sfrustrowani, podobnie jak właściciele projektów. Gdzie popełniliśmy błąd? Ludzie pytają.
Ta historia pokazuje, dlaczego jakość kodu jest ważna. Jakość wpływa nie tylko na sposób działania aplikacji. Oczywiście kod niskiej jakości powoduje problemy np. z wydajnością.
Ponadto kiepski kod spowalnia rozwój produktu w dłuższej perspektywie, sprawia, że deweloperzy są niezadowoleni, w wyniku czego często zmieniają pracę, a na ich miejsce trudno jest znaleźć innych, ponieważ nikt nie chce pracować z długiem technologicznym.
Pięć głównych wyzwań stojących przed deweloperami
Zidentyfikowałem pięć wyzwań, przed którymi stanęli deweloperzy w fazie rozwoju projektu. Jeśli nie zadbasz o te rzeczy, twój projekt stanie się potworem, od którego wszyscy będą uciekać. Utrzymywanie wyzwań na pierwszym planie to skuteczny sposób na zaoszczędzenie energii i czasu podczas tworzenia aplikacji.
Maintainability
Trudność utrzymania projektu zależy od liczby deweloperów. Zarządzanie jakością kodu nie jest trudne, gdy w projekcie uczestniczy dwóch programistów (ale nadal może być). W dużych projektach potrzebny jest doświadczony lider/programista, aby upewnić się, że projekt spełnia wymagania funkcjonalne i niefunkcjonalne oraz że dług techniczny nie wzrośnie z dnia na dzień.
Rola lidera
Rola lidera(czasem nazywanego architektem)jest szczególnie ważna na początku projektu (również przed fazą kodowania). Są to zazwyczaj osoby o szerokim zakresie umiejętności, od frontend/backend, przez testowanie, DevOps, aż po infrastrukturę.
Ich zadaniem na początku jest zebranie wymagań, oszacowanie wysokiego poziomu i opracowanie planu realizacji, w tym określenie, jakie osoby są potrzebne do projektu. Ponadto architekci są również odpowiedzialni za projektowanie architektury dla danych wymagań.
Często rozpoczynają projekt, tj. przygotowują środowisko programistyczne, potoki CI / CD, kontrole i weryfikację koncepcji niektórych części aplikacji.
Oczywiście architekci często konsultują swoje pomysły z innymi specjalistami, takimi jak inżynierowie dev ops, programiści backendu, specjaliści QA itp.
Czy architekci są naprawdę potrzebni?
Możesz zapytać, dlaczego piszę teraz o architekcie w kontekście utrzymania projektu.
Okazuje się, że duże projekty, które nie mogły liczyć na wsparcie doświadczonej osoby na samym początku prac, często kończyły się albo porażką, albo ogromnym długiem technologicznym. Jednym z najczęstszych błędów podczas wdrażania projektu jest rozpoczęcie pracy z kodem zbyt szybko.
Po rozpoczęciu projektu architekt jest nadal obecny w projekcie i bezpośrednio uczy zespół, jak tworzyć kod, a wraz z liderem zespołu lub kierownikiem inżynierii opracowuje proces rozwoju. Z czasem zaangażowanie architekta maleje, ponieważ zespół jest w pełni kompetentny i może później tworzyć i utrzymywać kod.
Skalowalność
Problem jest taki sam jak w przypadku łatwości konserwacji. Ogólnie rzecz biorąc, ma to również zastosowanie do wszystkich aplikacji. Wiem, że sztuka tworzenia dobrego kodu może również wymagać czegoś więcej niż tylko dobrego projektu.
Często wykonuje się MVP na małą skalę, aby przetestować pomysł.
Gdy projekt jest już wykorzystywany przez użytkowników, często okazuje się, że należy go skalować tak, aby:
- obsługiwał większą liczby użytkowników
- większy ruch
- dodawać nowe funkcje
- integrować projekt z innymi systemami
Często wiąże się to z przepisywaniem, refaktoryzacją, dodawaniem nowego kodu i ogólnie dużymi zmianami.
Na tym etapie ponownie można popełnić wiele błędów, które mogą zepsuć projekt. Dobrym pomysłem jest zwiększenie zaangażowania lidera/architekta, aby pomóc deweloperom stawić czoła nowym wyzwaniom.
Testowalność
Często słyszałem, że „nie piszemy testów, bo teraz nie mamy na to czasu, a dodamy je później”.
Takie podejście stwarza duże ryzyko, ponieważ testowanie kodu nie jest tak proste, aby wziąć każdy komponent i funkcję i po prostu je przetestować.
Testowalne/nietestowalne komponenty
Jeśli nie myślisz o testach podczas pisania kodu, często tworzysz nietestowalne komponenty, ponieważ są one napisane tak, że nie można ich przetestować i wymagają refaktoryzacji.
Pozostawienie testowania na końcu sprawia, że kończysz z bazą komponentów/funkcji/kodu, których nie można przetestować. A więc znowu dług technologiczny.
Fitness functional testing
Innym aspektem testowania jest sprawdzenie, czy architektura projektu spełnia określone wymagania. Na przykład wymóg, aby projekt internetowy spełniał wymagania Google Core Vitals lub aby strona ładowała się na urządzeniach mobilnych w ciągu 1 sekundy.
Możesz wdrożyć funkcje fitness, które to mierzą i musisz to mierzyć od początku projektu, a nie np. trzy miesiące po uruchomieniu.
Podsumowując: nie zostawiaj testów na sam koniec.
Czytelność
Co oznacza czytelność? Sam kod może być czytelny lub nieczytelny, ale często jest to opinia.
Zautomatyzowane narzędzia
Na szczęście istnieją narzędzia, które pozwalają sprawdzić jakość i czytelność kodu. Takie narzędzia nie wydają opinii; testują kod w oparciu o daną konfigurację i pokazują, czy jest on sklasyfikowany jako dobry.
Niestety, można napisać kiepski, którego takie narzędzie nie wykryje. Jest to możliwe. Co więc możemy zrobić, aby poprawić czytelność kodu?
Nie chcę tutaj zagłębiać się w kod, ale chciałbym podkreślić trzy ważne punkty:
Uwagi
Krótkie i jasne opisy trudniejszych części kodu
Dokumentacja
Wysokopoziomowy opis tego, co kod robi i co robi. Wykresy działają dobrze, ponieważ ludziom łatwiej jest zrozumieć obraz niż tekst
Testy
Przetestowany kod jest bardziej zrozumiały, ponieważ test pozwala odczytać, co robi kod. Widziałem przypadki, w których test zastępował dokumentację, a kod był zrozumiały
Wydajność
Wydajność aplikacji jest obecnie bardzo ważna i nie ma znaczenia, na jakim systemie pracujesz. W końcu jest użytkownik, który oczekuje, że coś będzie działać bardzo szybko.
Wydajność to często kompromis. Aby aplikacja działała szybciej, trzeba z czegoś zrezygnować.
Wydajność to często poszukiwanie nieoczywistych rozwiązań, hacków w kodzie, które wpływają na wszystkie wyżej wymienione obszary, tj. utrzymywalność, skalowalność, testowalność i czytelność.
Dlatego dbanie o wydajność jest stałym i bardzo ważnym procesem w rozwoju oprogramowania, którego nie można ignorować.
Narzędzia do sprawdzania jakości kodu
Zautomatyzowane narzędzia
Większość deweloperów używa już Git do zarządzania swoim repozytorium i przyzwyczaiła się do używania pull requestów do recenzji. Możliwe jest również zautomatyzowanie przeglądów kodu za pomocą kilku narzędzi. Kwestie bezpieczeństwa należy również uwzględnić w jakości kodowania. Jakość kodu i bezpieczeństwo są takie same, a analiza statyczna umożliwia wykrycie każdego rodzaju problemu. Zazwyczaj programiści wykorzystują techniki analizy statycznej do tworzenia i testowania projektów komponentów i oprogramowania.
Ważne jest, aby upewnić się, że wszystkie narzędzia są poprawnie skonfigurowane i połączone z żądaniem ściągnięcia.
Code reviews
Gdy statyczna analiza kodu zostanie wykonana, a wszystkie kontrole/budowy są „zielone”, nadszedł czas na ludzką weryfikację kodu.
Uważam, że nie powinno się sprawdzać kodu, który nie przeszedł pierwszego etapu wspomnianego powyżej, ponieważ oznacza to, że kod ma już jakieś problemy, które wykryła maszyna i nie warto nawet marnować ludzkiego czasu na jego sprawdzanie.
Przeprowadzanie przeglądów kodu to z pewnością temat na osobny artykuł. Najważniejszą rzeczą jest sprawdzenie tego, czego statyczna analiza kodu nie może sprawdzić, np.
- czy kod jest zgodny z założeniami wysokompoziomowymi
- jeśli nie ma w nim hacków
- Czy jest czytelny dla człowieka?
- czy spełnia wymagania biznesowe
Podsumowanie
Jakość kodu jest ważna zarówno dla programistów, jak i właścicieli produktów. Dobrej jakości kod jest łatwiejszy w utrzymaniu i rozwijaniu.
Czytelność, testy i dokumentacja znacząco wpływają na jakość kodu i produktu jako całości, a tym samym na zadowolenie z pracy członków zespołu, a wreszcie użytkowników końcowych korzystających z produktu.
Jakość kodu może być mierzona dzięki automatycznym narzędziom, takim jak akcje GitHub, chmura Sonar, a także dzięki przeglądowi kodu przez człowieka.
