W czym przejawia się jakość kodu źródłowego?

Punktem wyjścia w dyskusji o jakości dostarczanego kodu źródłowego jest jego kom-pletność w sensie opisanym w pkt 5, pokrycie kodu źródłowego testami jednostkowy-mi (ang. unit tests; patrz poniżej) oraz aktualność rozujednostkowy-miana jako zgodność ze środo-wiskami produkcyjnymi. Zapewnienie tych dwóch atrybutów jest fundamentem prawi-dłowej dbałości o to ważne aktywo przedsiębiorstwa. Tu także przynależy kompilo-walność kodu źródłowego. Jeśli bowiem nie potrafimy skompilować kodu źródłowego,

62 Od procesów do oprogramowania: badania i praktyka

nie możemy rozwijać systemu informatycznego. Jego kod źródłowy może mieć dla nas wtedy wartość wyłącznie sentymentalną. Autor spotkał się z żądaniami dostawców zapłaty sporych kwot za przekazanie wiedzy nt kompilacji pojedynczych systemów.

Zdawać trzeba sobie sprawę także z negatywnych skutków monopolizowania tej wie-dzy (i nie tylko tej) przez własnych, pojedynczych pracowników.

Wspomniana powyżej kompletność kodu źródłowego obejmuje dodatkowo dwa aspekty, odnoszące się głównie do jakości procesu zarządzania nim:

 kompletność scalenia (ang. merging, łączenie) wszystkich zmian w kodzie, które były planowane na potrzeby danego wydania - scalenie z określonych gałęzi do głównej gałęzi rozwojowej. By nie zapominać o scaleniu zmian, często wokół repozytorium kodu źródłowego nadbudowuje się narzędzia do zarządzania kodem źródłowym.

 kompletność funkcjonalna kodu źródłowego oddanego do testowania - czy przed rozpoczęciem testów odbiorczych zaimplementowano wszystkie oczekiwane funkcjonalności? Niestety praktyka konstruowania kodu dopiero na etapie testów jest powszechna i wynika m. in. ze słabości zarządzania wymaganiami oraz z problemów z dostępnością deweloperów i testerów po stronie dostawcy. Jest to zjawisko patologiczne, z którym trzeba bezwzględnie walczyć, przedłuża ono bowiem testy. Przy sztywnych datach wydań implikuje nadto uruchomienie nieprzetestowanych funkcjonalności. Z pomocą repozytorium kodu źródłowego można łatwo, szybko i tanio mierzyć, jaki procent kodu źródłowego powstał w czasie testów. Przy przekroczeniu założonego progu można analizować przyczyny tego faktu i ryzyka z niego wynikające. Oczywiście powyższe możliwe jest pod warunkiem, że zapewnimy także hermetyczność (patrz poniżej) procesu tworzenia środowisk testowych, nie tylko produkcyjnych. Jest to swego rodzaju quick-win wdrożenia postulowanego poniżej procesu zarządzania kodem źródłowym.

Często pojęcie jakości kodu źródłowego kojarzone jest z jego zgodnością ze stan-dardami kodowania - dobrymi praktykami programistycznymi. Są one opisane w formie reguł, którymi rządzić powinien się dobry kod źródłowy. Poziom zgodności to tzw. wewnętrzna jakość kodu źródłowego (ISO-9126-3, patrz [6]) w odróżnieniu od jakości zewnętrznej, którą obserwować można na podstawie zachowania uruchomione-go systemu. W przeciągu kilkunastu ostatnich lat wypracowano standardy kodowania dla większości języków programowania. Dostępne są także narzędzia, w których te standardy zaimplementowano i które służą do wyłapywania błędów programistów. Są to tzw. statyczne analizatory kodu źródłowego.

W ujęciu dynamicznym jakość kodu źródłowego może być definiowana jako pro-cent pozytywnie zakończonych testów jednostkowych. Są to liczne, acz małe frag-menty kodu źródłowego, których zadaniem jest weryfikacja poprawności działania kodu źródłowego. Uruchamianiem testów jednostkowych zajmują się zazwyczaj na-rzędzia tzw. ciągłej integracji (patrz akapit „Nana-rzędzia”).

Dość świeżym pojęciem w kontekście jakości kodu źródłowego jest dług IT (ang.

IT debt, technical debt). To próba oszacowania, jak duży jest niezbędny wysiłek pro-gramistów, by usunąć z kodu źródłowego wszelkie naruszenia dobrych praktyk. Wysi-łek ów przelicza się na pieniądze, czyli rzeczony dług, który tkwi w kodzie. Metodyka wyliczenia tego wskaźnika jeszcze raczkuje.

7. „Jeśli czegoś nie potrafisz zmierzyć, nie jesteś w stanie tym zarządzać”

Na potrzeby zarządzania jakością kodu źródłowego opracowano wiele mierników, m.in.

ISO/IEC 25040 [7] i SEI maintainability index [10]. Szczególnie interesujące mogą być te, które w sposób automatyczny wyliczane są przez statyczne analizatory kodu źródłowego (patrz poniżej „Standardy kodowania”). Równie istotne są także miary określające jakość i efektywność samego procesu zarządzania kodem źródłowym. Oto kilka przykładów:

 procent kodu źródłowego wytworzonego podczas testów UAT (ang. user acceptance tests). Miernik określa jakość testowania zmian i można go oprzeć np. na porównaniu wielkości raportu zmian w repozytorium kodu źródłowego dla fazy konstrukcji i dla fazy testów. W przypadku narzędzia Subversion jest to instrukcja ‘svn diff’.

 aktualność repozytorium kodów źródłowych – procent systemów, dla których znana jest lokalizacja kodu źródłowego aktualnej wersji produkcyjnej.

Można go mierzyć porównując datę wersji wskazanej w bazie konfiguracji (ang. configuration management data base - CMDB) z datą ostatniego wydania, w którym wykonano zmianę w tym systemie. W CMDB zazwyczaj wskazuje się charakter zmiany - czy zmiana polegała na zmianie konfiguracji czy zmianie w kodzie źródłowym. Trzeba w tym miejscu podkreślić kluczową rolę prawidłowej inwentaryzacji systemów i zmian w nich dokonywanych dla zarządzania kodem źródłowym.

 kompletność kodu źródłowego – choćby wskazując procent systemów, w których zachowano hermetyczność procesu wytwórczego tj. zmiany w systemie oparte są na repozytorium kodów będącym pod kontrolą zamawiającego zmianę.

Autor na potrzeby transformacji procesu zarządzania kodem dużego zbioru syste-mów opracował miarę dojrzałości procesu zarządzania kodem źródłowym opisującą stopień jego hermetyzacji. W ten sposób możliwe było przejrzyste (np. przy pomocy sugestywnych kolorów), liczbowe raportowanie postępu upragnionych zmian organi-zacyjnych, podawanie wartości per departament i ich agregację. Polegała ona na przy-pisaniu liczby do atrybutów jakościowych opisujących osiągnięcie ważnego kamienia w projekcie, jak poniżej:

 poziom 0: brak kodu źródłowego, nieznana lokalizacja kodu źródłowego

 poziom 1: kod źródłowy w „szufladzie”, na serwerze, nie w repozytorium

 poziom 2: kod źródłowy w repozytorium pod kontrolą wersji, znana lokalizacja odnotowana w CMDB, jednak bez możliwości skompilowania kodu lub bez pewności, że jest on zgodny z kodem wersji produkcyjnej (np.

środowiska są stawiane z repozytorium dostawcy). Wymagane są testy regresji przed odtworzeniem środowiska produkcyjnego.

 poziom 3: system produkcyjny stawiany jest na podstawie repozytorium zamawiającego (proces jest nadzorowany) ale kompilacja nie jest

wykonywana „w murach” zamawiającego lub narzędziami zamawiającego lub kompilacja jest wieloetapowa i jest wykonywana ręcznie. Weryfikowane są licencje bibliotek dostarczanych wraz z kodem źródłowym - patrz niżej

„Hermetyzacja procesu wytwórczego”.

 poziom 4: kompilacja (ang. build) systemu może odbywać się „ręcznie” lecz dokonuje się to w środowiskach zamawiającego a nie dostawcy, nadto istnieje

64 Od procesów do oprogramowania: badania i praktyka

pojedynczy skrypt budujący system czyli wiedza o procesie kompilacji jest zaszyta w formie algorytmu, nie tylko w głowie developera. Tak

wyprodukowane kompilaty są uruchamiane w środowiskach produkcyjnych.

 poziom 5: kompilacja jest wykonywana przez tzw. środowisko ciągłej integracji (patrz niżej „Podstawowe narzędzia”). To ważny etap zarówno ze względu na wyeliminowanie czynnika ludzkiego z procesu kompilacji jak i powtarzalność procesu.

 poziom 6: środowisko produkcyjne jest „stawiane automatycznie”, wersja wykonywalna (kompilat) jest dystrybuowany przez automat (skrypt). To kolejny krok w pozyskaniu wiedzy zaszytej w głowach osób zaangażowany w proces wytwarzania oprogramowania służący także zwiększeniu efektywności operacyjnej.

Rysunek 1. Poziomy dojrzałości procesu zarządzania kodem źródłowym