LISTA KONTROLNA KODOWANIA 181
A
LISTA KONTROLNA
KODOWANIA
Aby krótko przypomnieć najważniejsze zagadnienia niniejszej książki, sporządzi-
łem listę kontrolną zawierającą najważniejsze zagadnienia dotyczące projektu, im-
plementacji, opcji testowych, testowania i poprawiania błędów. Zrezygnowałem
przy tym z przypominania rzeczy oczywistych, jak odpowiednie ustawienie opcji
kompilatora, utrzymywanie testowej wersji programu (obok jego wersji handlo-
wej), konieczność usuwania pojawiających się błędów na bieżąco itd. Warto przy-
najmniej pobieżnie przeczytać ją co jakiś czas, szczególnie przed przystąpieniem
do rozbudowy lub modyfikacji istniejącego kodu.
PROJEKT
Gdy wybiera się określoną koncepcję projektową, nie należy kierować się wyłącznie
kryterium efektywności lub rozmiaru kodu. Należy także uwzględnić ryzyko związane
z implementowaniem i konserwacją kodu oraz upewnić się, iż kod ten istotnie realizuje
założone cele projektowe. Należy wówczas zadać sobie następujące pytania:
f& Czy projekt uwzględnia wszelkie możliwe sposoby zachowania się programu,
czy też istnieją w nim elementy losowe lub niezdefiniowane? Czy projekt za-
wiera elementy nadmiernej elastyczności lub czyni nieuzasadnione założenia?
f& Czy jakiekolwiek dane przekazywane są za pośrednictwem statycznych lub
globalnych buforów? Czy jakakolwiek funkcja uzależnia swe poprawne dzia-
łanie od szczegółów implementacyjnych innych funkcji? Czy każda funkcja
wykonuje tylko jedno, ściśle określone zadanie?
C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\rdodA.doc 181
182 NIEZAWODNOŚĆ OPROGRAMOWANIA
f& Czy projekt określa sposób postępowania z danymi o specjalnej postaci? Czy
kod dokonujący tej specjalnej obsługi jest odizolowany od reszty kodu?
f& Czy każdy z parametrów  i ewentualny wynik  funkcji reprezentuje dobrze
określoną informację, czy też łączy użyteczne dane z informacjami diagnostycz-
nymi?
f& Czy sposób zdefiniowania każdej z funkcji właściwie sugeruje poprawny sposób
jej użycia?
f& Czy w projekcie istnieją funkcje, które mogą zwracać informację o błędzie za-
miast oczekiwanego wyniku? Czy jest możliwe takie ich przedefiniowanie, by
zawsze kończyły się bezbłędnie? Pamiętaj, iż każdy przypadek sygnalizacji
błędu musi być obsłużony przez funkcję wywołującą.
f& I najważniejsze: czy możliwe jest automatyczne zweryfikowanie projektu za
pomocą testowania jednostek? Jeżeli nie, należy wybrać inny projekt.
IMPLEMENTACJA
Po zaimplementowaniu projektu należy upewnić się, iż implementacja jest wystar-
czająco solidna i odporna na błędy.
f& Czy implementacja realizuje projekt sensu stricto, czy tylko jego przybliżenie?
Nawet drobne uchybienia pod tym względem niosą ze sobą poważne ryzyko
błędów. Przypomnij sobie zachowanie funkcji IntToStr w sytuacji, gdy kon-
wertowana liczba jest najmniejszą liczbą ujemną.
f& Czy przy tworzeniu kodu poczyniono jakieś nieuzasadnione założenia? Czy
użyto nieprzenośnych typów danych? Czy implementacja w jakikolwiek spo-
sób zależna jest od konkretnych cech sprzętu, użytego kompilatora, czy systemu
operacyjnego?
f& Czy obliczane wyrażenia mogą powodować nadmiar lub niedomiar?
f& Czy używane są jakiekolwiek ryzykowne idiomy języka C? Czy kod zawiera
zagnieżdżone operatory ?:? Czy istnieją w kodzie wyrażenia łączące operato-
ry z różnych grup?
f& Czy kod napisany jest w sposób zrozumiały dla programisty o przeciętnych
kwalifikacjach?
f& Czy każda z czynności zawartych w projekcie wykonywana jest w ściśle okre-
ślonym miejscu kodu, czy też istnieje kilka fragmentów wykonujących (w różny
sposób) tę samą operację? Czy występują fragmenty dokonujące obsługi  przy-
padków szczególnych i czy można je wyeliminować dzięki użyciu innego algo-
rytmu? Czy istnieją instrukcje if, które można wyeliminować?
f& Czy wywoływana jest jakakolwiek funkcja, której wykonywanie może nie za-
kończyć się pomyślnie? Czy można zmienić projekt w taki sposób, by taki przy-
padek wyeliminować i uniknąć kłopotliwej obsługi błędu?
182 C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\rdodA.doc
LISTA KONTROLNA KODOWANIA 183
f& Czy występują w kodzie odwołania do nieprzydzielonych obszarów pamięci,
w szczególności  pamięci zwolnionej? Czy implementacja nie narusza pry-
watnych danych należących do innych aplikacji?
f& Czy implementacja funkcji określa ograniczony rozmiar buforów wejściowych
i wyjściowych? (Funkcja wywołująca mogła ograniczyć ten rozmiar do wartości
niezbędnej z punktu widzenia wywołania.)
ELEMENTY TESTOWE W APLIKACJI
Wyposażenie kodu aplikacji w asercje (i inny kod diagnostyczny) może przyczynić
się do zmniejszenia czasu niezbędnego do znalezienia i poprawienia błędu.
f& Czy funkcja zawiera asercje weryfikujące poprawność jej parametrów? Jeżeli
nie jest możliwe zweryfikowanie określonego parametru, z powodu niedosta-
tecznej informacji o nim, czy istnieją inne, dodatkowe środki kontrolujące in-
tegralność funkcji?
f& Czy przyjęte w implementacji założenia weryfikowane są za pomocą stosow-
nych asercji? Czy kontrolowane są przypadki nadużywania mechanizmów
specyficznych dla określonego środowiska?
f& Programowanie defensywne przyczynia się do łatwiejszego wykrywania we-
wnętrznych błędów aplikacji  czy w wersji testowej programu istnieją zwią-
zane z tym asercje?
f& Czy każda z asercji jest samodokumentująca? Jeżeli nie, należy opatrzyć ją
stosownymi komentarzami. W przeciwnym razie programiści, nie rozumiejąc
zadania spełnianego przez asercję, uznają ją za zbędną i usuną z kodu.
f& Czy przydział i zwalnianie pamięci w wersji testowej połączone jest
z wypełnianiem przydzielonych i zwalnianych bloków odpowiednim wzor-
cem? Wyeliminowanie losowej zawartości pamięci przyczynia się do powtarzal-
ności błędów wynikających z niewłaściwego zarządzania nią.
f& Czy procedury organizacyjne zwalniające bloki pamięci niszczą jednocześnie
ich zawartość?
f& Czy wyniki produkowane przez użyty algorytm dają się zweryfikować za po-
mocą innego algorytmu?
f& Czy w programie istnieją dane, których poprawność można by zweryfikować
już przy starcie? Czy program zawiera tablice przeglądowe i czy ich zawartość
można w jakiś sposób zweryfikować?
TESTOWANIE
Jest sprawą niezmiernie ważną, by programiści gruntownie testowali tworzony przez
siebie kod, nawet jeżeli miałoby to powodować opóz
nienia w harmonogramie.
C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\rdodA.doc 183
184 NIEZAWODNOŚĆ OPROGRAMOWANIA
f& Czy kod kompiluje się bez ostrzeżeń? Jeżeli używasz programu lint lub in-
nego narzędzia diagnostycznego, czy przeprowadziłeś wszystkie dostępne te-
sty? Czy przetestowane zostały wszystkie jednostki kodu?
f& Czy wykonanie kodu prześledzone zostało za pomocą pracy krokowej? Czy
zweryfikowana została poprawność przepływu danych?
f& Czy kod został poddany adiustacji lub reformatowaniu? Czy został póz
niej
przetestowany ponownie?
f& Czy dla nowo stworzonego kodu opracowano testy weryfikujące poprawną
współpracę jednostek?
POPRAWIANIE BA

DÓW
Gdy przystępuje się do wykrycia przyczyny błędu raportowanego przez testerów,
należy każdorazowo rozważyć następujące kwestie:
f& Czy raportowany błąd istotnie występuje? Jeżeli nie, należy pamiętać, iż błędy
nie znikają samoczynnie, a jedynie przestają się objawiać w sposób powtarzalny
wskutek zmian poczynionych w kodzie. Być może błąd został poprawiony przez
innego programistę. Podczas analizy kodu z
ródłowego, należy zawsze używać
tej jego wersji, z której korzystają testerzy.
f& Czy dana okoliczność jest przyczyną błędu, czy tylko jego objawem?
f& W jaki sposób mogłem uniknąć popełnienia tego błędu? W jaki sposób mogę
go uniknąć w przyszłości?
f& W jaki sposób mógłbym doprowadzić do automatycznego wykrycia tego błę-
du? Jakie zmiany w testowej wersji produktu należałoby wprowadzić w
związku z tym?
184 C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\rdodA.doc
LISTA KONTROLNA KODOWANIA 185
C:\WINDOWS\Pulpit\Szymon\Niezawodność oprogramowania\rdodA.doc 185