Co dziś nowego w pracy? szczur informatyczny

W tym wpisie i w następnych oddalam się nieco od żywego oprogramowania, idąc w kierunku często zaniedbywanych, choć naprawdę niezbędnych, składników projektu. Na początek trywialna sprawa: dokumentacja…

Analiza dokumentacji

Motywacja/Cel
Analiza dokumentacji ma na celu głównie sprawdzenie jej kompletności i aktualności. Są to bardzo ważne aspekty, ponieważ dokumentacja jest podstawą dalszego rozwoju oprogramowania oraz leży u podstaw kształtowania procesów w projekcie.

Metoda
Analiza dokumentacji nie jest niczym innym jak “ręcznym” sprawdzeniem wszelkich dokumentów, które mają wpływ na kształtowanie oprogramowania i całego projektu. W szczególności należy poświęcić uwagę następującym zagadnieniom:

• Czy dokumentacja jest aktualna? Czy jest w razie potrzeby na bieżąco aktualizowana?
• Czy dokumentacja jest kompletna? Przez kompletność rozumiem tutaj to, że wszystkie fazy tworzenia aplikacji, wszystkie elementy natury biznesowej jak i elementy właściwego oprogramowania są opisane w sposób wystarczający i pozbawiony luk. W szczególności ważne jest zdefiniowanie zależności między warstwami aplikacji i innymi obiektami oraz sprecyzowanie używanych pojęć (glosariusz!)
• Czy dokumentacja jest łatwo dostępna dla wszystkich uczestników projektu? Powinna ona znadjować się w z góry zdefiniowanym miejscu (katalog na serwerze, wiki itp.), które z łatwością jest dostępne dla wszystkich zainteresowanych. W idealnej sytuacji sposób przechowywania dokmentacji powinien zapewniać mechanizm wersjonowania.
• Czy forma dokumentacji jest jednorodna w projekcie? Szablony dokumentacji usprawniają jej tworzenie i “konsumpcję” w ramach projektu.

(Kontr)przykład
W jednym z projektów dokumentacja różnych modułów miała zupełnie różną formę, zakres i inną definicję tych samych pojęć. Doprowadziło to do kompletnego chaosu w implementacji i chociaż techniczna struktura aplikacji była we wszystkich modułach taka sama, to funkcjonalność rozkładała się zupełnie inaczej na różne warstwy. Dochodzący do tego brak wspónego rozumienia tak samo brzmiących nazw i terminów (brak glosariusza dla całego projektu) doskonale utrudniał komunikację pomiędzy architektami i programistami, prowadząc do zwiększonego nakładu pracy.

Metryki oprogramowania

Motywacja/Cel
Metryki oprogramowania to funkcje matematyczne, dzięki którym możliwa jest ilościowa (numeryczna) analiza kodu i ocena jego właściwości. Używamy ich w audycie, żeby ilościowo zobrazować lub uzasadnić jakościową ocenę oprogramowania.

Metoda
Istnieje niemal nieskończona ilość metryk oprogramowania Ponieważ, mimo istnienia narzędzi automatycznie obliczających metryki, ich analiza i interpretacja jest uciążliwa i czasochłonna, należy wybrać te, których wartości dadzą najwięcej informacji potrzebnych do osiągnięcia celu audytu.
Poniżej prezentuję kilka metryk, stosowanych w ocenie łatwości konserwacji i dalszego rozwoju systemu informatycznego.

• NCSS (Non Commenting Source Statements): jest to ilość linijek kodu w danej jednostce (jednym pliku, klasie, metodzie, funkcji), które nie są komentarzami. Zbyt wysoka wartość sugeruje, że badana jednostka kodu zawiera zbyt dużo funkcjonalności.
• Ilość metod w klasie i klas w pakiecie: jest to odpowiednik NCSS na wyższym poziomie organizacji kodu. Zbyt wysokie wartości najczęściej oznaczają nieodpowiedni projekt danego modułu i zbyt dużą ilość funkcjonalności w jednostce kodu. Naturalnie w językach oprogramowania, które nie organizują kodu w klasy i pakiety, należy stosować metryki do odpowiednich struktur charakterystycznych dla tego języka.
• CCN (Cyclomatic Complexity Number) opisuje, jak bardzo skomplikowany jest przepływ sterowania w programie. Jest to bardzo istotne dla testowania, eliminacji błędów oraz dalszego rozwoju oprogramowania. Im wyższy stopień skomplikowania, tym trudniej jest ocenić wpływ zmian w kodzie na jego funkcjonowanie.
• Zduplikowany kod w zasadzie nie powienien istnieć. Zduplikowana implementacja logiki wymaga w przypadku wprowadzania zmian odnalezienie, modyfikacji i testowania kodu w wielu miejscach. Zasada DRY (Don’t Repeat Yourself) mówi, że powinno się unikać powtórzeń, aby zapewnić zachowanie konsystencji w aplikacji.
• Cykliczne zależności między komponentami systemu (na różnych poziomach abstrakcji) wskazują na bardzo silne powiązania pomiędzy nimi. Oznacza to, że zmiany w jednym komponencie mogą mieć nieprzewidywalne efekty w zupełnie innych miejscach systemu (ripple effect), co najczęściej łączy się z podwyższonymi kosztami eliminacji błędów i testowania. Cykle często wynikają z nieodpowiedniego podziału funkcjonalności na warstwy lub moduły.

Przykład
Jako przykład poniżej prezentuję macierz zależności pomiędzy warstwami w badanym systemie. Plusy poniżej diagonali pokazują dopuszczalne zależności pomiędzy warstwami. W idealnym przypadku, powinny one jednak istnieć tylko na polach tuż pod diagonalą. Z macierzy widać też, że warstwy abs i sss leżą na jednym poziomie. Liczby powyżej diagonali pokazują ile razy zostały złamane zasady separacji warstw.

Tym razem post z nie do końca polskim tytułem, ale nie widzę sensu tłumacznia akurat tych wyrażeń i właściwie nie znam też ich polskiego odpowiednika.

Code/Architecture-Walkthrough

Motywacja/Cel
Są to środki, które pozwalają na ocenę szczegółów implementacji danego systemu. Stosuje się je w celu zgromadzenia dodatkowych informacji dotyczących poprzednio zidentyfikowanych lub wcześniej znanych problemów.

Metoda
Code-Walkthrough polega na maualnej analizie dostępnego kodu źródłowego. Naturalnie w przypadku dużych projektów niemożliwe jest oglądnięcie całego kodu, dlatego należy sie skoncentrować na miejscach, gdzie potencjalnie mogą występować problemy. Te miejsca dostarcza nam analiza architektury.
Na poziomie technicznym należy sprawdzić na ile implementacja odpowiada aktualnym standardom programowania w danym języku. Natomiast na poziomie strukturalnym (architektura oprogramowania) skupiamy się na sprawdzeniu, czy implementacja pasuje do dokumentacji lub specyfikacji.

Warto przyglądnąć się nastepującym aspektom:

• Struktura kodu (podział na pakiety, klasy, moduły, funkcje, w zależności od stosowanego języka programowania)
• Czytelność kodu: ile wysiłku kosztuje odczytanie funkcjonalności z implementacji
• Komentarze: czy kod jest wystarczająco skomentowany i (co nawet jest ważniejsze) czy komentarze są aktualne
• Ogólnie przyjęte wzorce i antywzorce w programowniu

Jeśli w projekcie istnieją wytyczne dotyczące stylu programowania, warto zbadać kod również po kątem ich zachowania.