[ Pobierz całość w formacie PDF ]

nad programem błąd powinien rzucać się w oczy  lepiej, żeby był kłopotliwy,
niż żeby został przeoczony. Jednocześnie w wersji przekazywanej użytkowni-
kowi błędy nie powinny sprawiać kłopotów  powinny umożliwiać konty-
nuowanie pracy lub w uporządkowany sposób ją przerywać. Oto kilka porad
pomocnych przy podejmowaniu decyzji o tym, które elementy kodu defen-
sywnego należy pozostawić w kodzie wersji finalnej:
Zostaw kod wykrywający ważne błędy. Określ, w których obszarach programu
niewykryte błędy są dopuszczalne, a w których nie. Jeżeli na przykład piszesz
program arkusza kalkulacyjnego, możesz pozwolić na ich występowanie w części
programu zajmującej się odświeżaniem ekranu, bo będzie to skutkować wyłącz-
nie problemami z wyświetlanym obrazem. Niedopuszczalne jest jednak nie-
wykrycie błędu w mechanizmie obliczeniowym, ponieważ może on dopro-
wadzić do trudnych do zauważenia zmian w arkuszu danych użytkownika.
Zakłócenia w wyświetlaniu danych mają charakter przejściowy i są dla użyt-
kującego program mniej dotkliwe niż wydruk z błędnymi wynikami obliczeń
albo zniekształconymi danymi.
Usuń kod wykrywający banalne błędy. Jeżeli konsekwencje błędu są mało
istotne, można usunąć wykrywający go kod. Odwołując się do wcześniejszego
przykładu, można pozbyć się kodu weryfikującego poprawność odświeżania
arkusza. Oczywiście nie chodzi o usuwanie kodu w znaczeniu dosłownym.
Należy użyć systemu kontroli wersji, kodu preprocesora lub innej metody, która
pozwala na skompilowanie programu bez zbędnego kodu. Jeżeli pojemność
pamięci masowej nie jest problemem, można pozostawić kod sprawdzający
błędy, ale skierować komunikaty do pliku dziennika.
Usuń kod, który gwałtownie przerywa pracę programu. Jak wspominałem,
w trakcie pracy z kodem wykrywane błędy powinny być jak najbardziej wido-
czne, aby przypominały o konieczności wprowadzenia poprawek. Często najlep-
szą metodą osiągnięcia tego celu jest wypisanie komunikatu i przerwanie pracy
aplikacji. Jest to praktyczne nawet w przypadku drobnych błędów.
Kod przekazywany użytkownikom ma inne wymagania. Użytkownik musi mieć
szansę zapisania swojej pracy przed zakończeniem programu i zapewne chętnie
zgodzi się na najróżniejsze zakłócenia jego funkcjonowania, jeżeli zyska dzięki
temu możliwość zabezpieczenia danych. %7ładne ułatwienie debugowania i wyni-
kająca z niego przyszła poprawa jakości aplikacji nie wynagrodzą utraty pracy
w wyniku nagłej awarii. Jeżeli w programie znajdują się fragmenty, które mogą
doprowadzić do zniszczenia, skasowania lub niezapisania danych, należy je
z wersji finalnej usunąć.
246 Rozdział 8. Programowanie defensywne
Zostaw kod, który pozwala łagodnie przerwać pracę programu. Jeżeli program
zawiera kod wspomagający debugowanie, który wykrywa błędy mogące unie-
możliwić dalszą pracę, pozostaw elementy zapewniające łagodne jej zakoń-
czenie. Inżynierowie projektujący sondę marsjańską Pathfinder zostawili w jej
programie część elementów wspomagających debugowanie. Gdy po wylądo-
waniu sondy został wykryty błąd, informacje, które zapewnił pozostawiony kod,
umożliwiły zdiagnozowanie problemu i przesłanie do niej nowej wersji opro-
gramowania, dzięki czemu misja zakończyła się sukcesem (March 1999).
Rejestruj błędy istotne dla personelu pomocy technicznej. Wez
pod uwagÄ™
pozostawienie w wersji finalnej kodu pomocniczego i wprowadzenie jedynie
zmiany jego działania w taki sposób, aby obsługa błędów była niekłopotliwa
dla użytkownika. Jeżeli w kodzie jest dużo asercji, które w trakcie pracy z nim
przerywają wykonywanie programu, możesz rozważyć zmodyfikowanie pro-
cedury asercji tak, aby jedynie rejestrowała komunikaty w pliku.
Dbaj o to, aby komunikaty były zrozumiałe i praktyczne. Gdy pozostawiasz
w programie wewnętrzne komunikaty błędów, zadbaj o to, aby były sformu-
łowane w języku czytelnym dla użytkownika. W toku jednego z pierwszych
w moim życiu projektów programistycznych zadzwonił do mnie użytkownik
z wiadomością, że wyświetlił się komunikat  Zła alokacja wskaz
nika, spadaj! .
Całe szczęście miał poczucie humoru. Popularnym i praktycznym podejściem
jest powiadomienie użytkownika o wystąpieniu  błędu wewnętrznego i zawar-
cie w komunikacie adresu e-mail lub numeru telefonu, pod którym można
zgłosić wystąpienie problemu.
8.8. Defensywne podejście
do programowania defensywnego
Nadmiar jest zawsze zły,
Nadmiar elementów programowania defensywnego może doprowadzić do
ale nadmiar whiskey
zupełnie nowych, specyficznych problemów. Jeżeli przekazywane za pomocą
jest w sam raz.
parametrów dane podlegają drobiazgowej kontroli w każdym możliwym miej-
 Mark Twain
scu, program staje się rozwlekły i powolny. Co gorsza, dodatkowy kod to zawsze
dodatkowa złożoność. Ponadto kod ten nie jest bardziej odporny na błędy niż
główny kod programu. W nim też mogą wystąpić błędy, a jest to tym bardziej
prawdopodobne, że najczęściej nie jest on pisany i rozwijany z równą uwagą
co podstawowy kod operacji. Zakres defensywnego programowania musi być
przemyślany  nadmiar jest równie szkodliwy jak niedostatek.
cc2e.com/0868
Lista kontrolna: Programowanie defensywne
Programowanie defensywne ogólnie
Czy procedura jest chroniona przed niepoprawnymi danymi wej-
ściowymi?
Czy użyłeś asercji do opisu przyjętych założeń, przede wszystkim
warunków wstępnych i końcowych?
8.8. Defensywne podejście do programowania defensywnego 247
Czy stosujesz asercje wyłącznie do opisywania sytuacji, które nigdy
nie powinny się zdarzyć?
Czy architektura lub projekt wysokiego poziomu wyznaczajÄ… okre-
ślony zbiór mechanizmów obsługi błędów, które powinny być
stosowane?
Czy architektura lub projekt wysokiego poziomu definiujÄ…, czy
obsługa błędów powinna być ukierunkowana na odporność, czy
na poprawność?
Czy wprowadziłeś między obszarami programu podziały zapew-
niające ograniczenie szkód powodowanych przez błędy i reduku-
jące ilość kodu, w którym niezbędne jest sprawdzanie poprawno-
ści danych?
Czy używałeś w programie kodu wspomagającego debugowanie?
Czy kod wspomagajÄ…cy debugowanie jest wprowadzany w taki spo-
sób, aby jego aktywowanie i dezaktywowanie nie było kłopotliwe?
Czy ilość kodu defensywnego jest odpowiednia  nie jest go za
dużo ani za mało?
Czy używałeś technik programowania ofensywnego, aby zabez-
pieczyć się przed przeoczeniem błędów?
WyjÄ…tki
Czy w projekcie określone zostało spójne podejście do stosowania
wyjątków?
Czy rozważyłeś alternatywy dla użycia wyjątku?
Czy lokalna obsługa błędów ma zawsze pierwszeństwo przed zgła-
szaniem nielokalnych wyjątków?
Czy unikasz zgłaszania wyjątków w konstruktorach i destruktorach? [ Pobierz całość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

kajaszek.htw.pl