Automatyzm zapobiegawczy

Nie ma innej praktycznej drogi do budowy oprogramowania o wysokiej jakości, jak tylko poprzez wprowadzenie rozwiązań automatycznego zapobiegania pojawianiu się błędów. Ta koncepcja to wymienione wcześniej pięć zasad plus automatyzacja całości. Oczywiście połączenie automatyzacji i zapobiegania błędom nie jest łatwym zadaniem i wielu połamało sobie już na tym zęby.

Jak to zrobić? Po pierwsze, trzeba zaimplementować sprawdzone rozwiązania ograniczające liczbę powstających błędów w trakcie rozwoju oprogramowania (to przede wszystkim standardy kodowania, testy modułowe, testy integracyjne, testy obciążeniowe i inne - wszystkie te dobre praktyki mogą być włączone do procesów wytwórczych i w daleko idącym stopniu zautomatyzowane).

Błędy lokalizowane gdziekolwiek w trakcie procesu wytwórczego mogą zostać powiązane z procedurami, w trakcie realizacji których one powstały. Wówczas bazując na indywidualnych przypadkach można tak zmodyfikować samą procedurę, by ograniczyć występowanie błędu w przyszłości. Dalszym krokiem jest automatyzacja takiego ulepszania procesów wytwórczych - koncepcja automatycznego zapobiegania błędom pasuje do wielu różnych metodyk - począwszy od modelu kaskadowego, aż do eXtreme Programming.

Bardzo ważną rzeczą jest tutaj uwzględnianie zachowań grupowych. Wspomniane wyżej działania muszą być realizowane w obrębie całych zespołów tworzących aplikacje. Kluczową kwestią jest ścisły podział zadań i odpowiedzialności - każdy, czy to programista, czy kierownik projektu, czy architekt systemowy - musi dobrze rozumieć swoją rolę, tak by mógł prawidłowo umiejscawiać ją w procesie wytwórczym. Dla przykładu wiedza o tym, kto tworzy standardy kodowania, gdzie są one dostępne, kto i kiedy ma je stosować, jest niezbędna, by cały zespół wdrożył w praktyce swojego działania zautomatyzowane standardy kodowania. Zachowania grupowe mają to do siebie, że cechują się większą bezwładnością - trudniej je wprowadzić, ale potem przez dłuższy czas pozostają stabilne.

Inną, nie mniej ważną rzeczą, jest zdolność do usprawniania procesów, do czego potrzebny jest przepływ informacji zwrotnej. Dla przykładu, załóżmy, że tworzymy n-warstwowy system sieciowy. By sprawdzić, z jak dużym ruchem taki system może sobie poradzić, trzeba przeprowadzić testy obciążeniowe. No i okazuje się, że system pada, bo warstwa pośrednia oprogramowania posiada zbyt wątłe połączenia z bazą danych. Wystarczyłoby więc naprawić ten błąd, zamykając w danej chwili wszystkie inne połączenia i otwierając je na potrzeby tej warstwy, ale czy to sprawi, że podobne zjawisko nie pojawi się w przyszłości? Może lepiej byłoby ustalić, co było pierwotną przyczyną wystąpienia błędu? W podanym przykładzie może to być zjawisko polegające na tym, że po otwarciu połączenia z bazą nie jest ono zamykane. Załóżmy, że middleware, który był źródłem problemu, napisany został w języku Java - trzeba więc się upewnić, że w każdej klasie, w której otwierane są połączenia, wywoływana jest procedure finalize, która zamyka połączenie.

Do tego wystarczy konsekwencja w stosowaniu standardów kodowania - a konkretnie zasada, że odpowiednie wywołania procedur muszą być sparowane, a narzędzie automatyczne może sprawdzić to w kodzie, czy tak się stało faktycznie. Do stworzenia takiej zasady potrzebne jest cofnięcie się w cyklu rozwojowym aplikacji od testów obciążeniowych aż do ustalania standardów kodowania (żadne otwierane połączenie nie może zostać niezamknięte).

Tutaj dochodzimy do automatyzacji. Skaner sprawdzający standardy kodowania może zweryfikować, czy rzeczywiście cały zespół zastosował się do nowej reguły. Czyli nie tylko zmieniamy procedurę, tak aby błąd się więcej nie pojawił, ale również uruchamiamy narzędzia, które w sposób automatyczny weryfikują, czy zmiany w procedurze zostały zaadaptowane w praktyce przez zespół deweloperski. To zaś pozwala stwierdzić, czy zmiana była rozsądna i została skutecznie wprowadzona, czy też może potrzeba podjąć jakieś inne działania.

Oczywiście praktyczne stosowanie takiego podejścia nie jest łatwe, ani szybkie. Wymaga doświadczenia i cierpliwości we właściwej implementacji. Ale z czasem stosowanie automatycznego zapobiegania błędom staje się prostsze do realizacji - na pewno na początku bardzo pomocne będzie wdrożenie istniejących standardów kodowania. Dzięki temu można zutylizować tysiące godzin spędzonych przez ekspertów z branży, którzy analizowali tworzone kody źródłowe pod kątem przyczyn występowania typowych błędów. To będzie znacznie bardziej efektywne, niż ślęczenie nad niezadowalającymi wynikami testowania własnego oprogramowania. Zacznijmy więc od standardów kodowania, wprowadzanych na różnych poziomach i w różnych miejscach, a dopiero potem przechodźmy do innych rozwiązań automatycznego zapobiegania błędom w tworzonym oprogramowaniu.

Co nas czeka

Przemysł oprogramowania musi dorosnąć. Nie będzie to możliwe bez wprowadzenia rozwiązań zapobiegania powstawaniu błędów i istotnemu ulepszeniu jego procesów produkcyjnych. Nie mamy wyjścia - musimy to zrobić. W przeciwnym razie branża zapłaci za to bolesną cenę, podobnie jak przemysł samochodowy, który w latach 60. i 70. stracił blisko połowę rynku w wyniku działań konkurencji, która stosując techniki pozwalające na zapobieganie powstawaniu defektów na liniach produkcyjnych zaczęła oferować produkty istotnie wyższej jakości.

Adam Kolawa jest współzałożycielem i prezesem amerykańskiej firmy Parasoft. Wyjechał z Polski w 1983 r., by zrobić doktorat w Stanach Zjednoczonych. Wraz z grupą współpracowników opuścił potem mury uczelni i stworzył Parasoft, firmę specjalizującą się w narzędziach wspomagających procesy tworzenia systemów informatycznych.