Jak programista może uniknąć błędów? Przewiduj błąd!

Z cyklu „Paradoksy programowania”
Wspinacz wspina się po stromym zboczu. Wyobrażasz sobie, co by się stało, gdyby się poślizgnął i lina asekuracyjna pękła? Wyobrażasz sobie? Nie zdążył? A już tam jest. Dno przepaści jest bardzo blisko…

Czekaj, przepraszam, miałem na myśli programistę, a on się nie wspina, on po prostu tam siedzi. Jedyne, co się rusza, to mysz w jego dłoni. „Programista to zupełnie inna sprawa”, możesz powiedzieć. Ale czy myślisz, że nie ma miejsca na poślizg? Tak! I to w znacznie większym stopniu niż alpinista. Awaria komputera, utrata danych, błąd, który wkradł się do programu, awaria systemu… Nie sposób wymienić wszystkich. Po prostu nie dotrze na dno otchłani. Po drodze natknie się na dział kadr. A potem oni się nim zajmą. Jeśli nie dotrze do działu kadr, na pewno będzie miał duże kłopoty. Przynajmniej drobne są zawsze gwarantowane.

Ale nie bądźmy tak pesymistyczni. Istnieją proste kroki, które mogą pomóc uniknąć takiego scenariusza. Rozważmy je.

1. Regularnie twórz kopie swojej pracy lub zadbaj o to, aby były tworzone automatycznie (ja bym tak robił).

2. Podczas kopiowania ważnych informacji z jednego okna do drugiego, najlepiej, aby okno docelowe było puste. W ten sposób nigdy nie pomylisz się, z którego okna kopiować. (Wyobraź sobie, że drugie okno zawiera poprzednią kopię informacji, a Ty na chwilę się rozpraszasz i przypadkowo poruszasz myszką. Pierwsze okno nagle staje się drugim, a drugie pierwszym). Zdarzało mi się, że kopia nadpisywała oryginał. Sam też kiedyś tak zrobiłem.

3. Unikaj podstawowego zamieszania! Załóżmy, że masz dwa skróty lub moduły. Najpierw musisz pracować z jednym, potem z drugim. Mają ten sam interfejs, są nieodróżnialne. Różnica pojawi się dopiero na głębszym poziomie obliczeniowym. Pracujesz z pierwszym i idziesz na lunch. Po powrocie nie wiesz, który moduł należy uruchomić. Pomyliłeś je w myślach!

W praktyce najlepiej nie umieszczać tych skrótów obok siebie. W ostateczności tymczasowo przenieś drugi, aby uniknąć przypadkowego kliknięcia, lub usuń go! Następnie przywróć go. Ale będziesz mieć pewność, że pracowałeś z właściwym skrótem. Miałem ten problem. Musiałem uruchomić moduł M1 w dziesięciu katalogach, ale tuż obok znajdował się moduł M. Nie było widocznej różnicy po ich uruchomieniu. Działałem szybko, ale przy piątym uruchomieniu przyłapałem się na uruchamianiu modułu M jak zwykle, a nie M1, co było tymczasowe. Ile razy już popełniłem ten błąd? Nie mogłem go łatwo namierzyć. Więc tymczasowo usunąłem moduł M i rozpocząłem cały proces od nowa.

4. Nie przeciążaj mózgu niepotrzebnymi zadaniami! Jeśli musisz wprowadzić operatora do programu lub niezbędne polecenie, lepiej, o ile to możliwe, skopiować je z wcześniej debugowanego bloku, niż wprowadzać je ponownie. Prosty błąd literowy może być kosztowny! Miałem nawet problemy z pojedynczym słowem, którego jakoś nie potrafiłem poprawnie wpisać. Litera była w złej wielkości, brakowało cyfry. Ale mój mózg rozwiązywał już kolejny problem i całkowicie ufał moim rękom – wydawało się to proste. Próbowałem i próbowałem, w końcu się poddałem (oczywiście nie na monitorze), poszedłem i skopiowałem. Problemy zniknęły.

5. Chroń ważne informacje przed przypadkowym dostępem, w tym swoje własne. Opowiem ci zabawną historię. Były inżynier systemowy z mojej poprzedniej pracy zadzwonił do mnie i powiedział, że nagle przestał działać duży system graficzny. Bez niego nie można było odczytać kilku tysięcy modeli zaprojektowanych przez lata. Awaria nie miała z tym nic wspólnego. Wszystko działało dobrze tego wieczoru, ale rano nie chciało się uruchomić. System nie działał już od półtora dnia. Zacząłem się zastanawiać. Przeanalizowałem komunikat programu. Wszystko wskazywało na utratę dostępu do katalogu C. Zadałem mu przez telefon następujące pytania:

– Czy katalog A jest dostępny?
– Tak.
– Katalog „B”?
– Na miejscu.
– Katalog „C”?
– To samo.
– Co znajduje się w katalogu „C”?

On to nazywa. Wszystko się zgadza. Nie ma sposobu, żeby się przyczepić. I to nie działa. Robimy przerwę na lunch. Potem znowu zaczynam go pytać o katalogi, tylko w odwrotnej kolejności. „Dlaczego?” – pytasz. „Teraz wszystko jasne!”. Ale właśnie po sprawdzeniu tego w odwrotnej kolejności okazuje się, zupełnie przypadkiem, że katalog „C” znajduje się w katalogu „B”, a nie tuż obok, gdzie powinien.

Czyjeś zwinne ręce przypadkowo podniosły myszką literę „C” i nieświadomie wrzuciły ją do „B”. Te ręce równie dobrze mogłyby należeć do mojego kolegi, inżyniera systemów. Szybko pisał na klawiaturze i sprawnie posługiwał się myszką. Sam miałem podobne doświadczenia. Najlepiej zablokować dostęp do tak wrażliwych obszarów. Jeśli to niemożliwe, należy ograniczyć dostęp do odczytu. Ale to nie zawsze jest praktyczne. Co jeśli program zapisze dane do katalogu? Cóż, to zależy od ciebie. Zawsze jest jakieś wyjście. Nie powinniśmy karać osoby za błąd (oczywiście, jeśli kogoś takiego znaleźliśmy), ale raczej wyeliminować możliwość jego popełnienia.

6. Nigdy nie zastępuj formatów danych tworzonych programowo ręcznym asemblerem! Nawet jeśli są łatwe i proste w tworzeniu. Miałem taki przypadek. Z banku przyszła dyskietka z kolejną informacją, którą należało wprowadzić do naszego systemu. Księgowy włożył dyskietkę do komputera, uruchomił program i po minucie potrzebne dane pojawiły się na ekranie. Tym razem zrobił to samo. Jednak po spojrzeniu na ekran, z przerażeniem chwycił telefon. Dwie minuty później stanąłem przed ekranem. Zrobiło mi się zimno. Wszystkie nazwiska w naszej ogromnej bazie danych zostały zastąpione tylko jednym. Nie powiem, którym, ale mogę zapomnieć swojego, ale tego prawdopodobnie nigdy nie zapomnę. Przywrócenie go zajęło półtora dnia. Zastąpiono nie tylko nazwiska, ale także wiele danych osobowych, w tym informacje o zarobkach.

Jak się później okazało, w banku pojawiła się nowa osoba, która zapisując dane na dysku, zaniedbała stary program i wprowadziła dane ręcznie. Tak było szybciej. Oczywiście, w naszym oprogramowaniu były kontrole, ale nie da się przewidzieć wszystkiego. Rzadka kombinacja błędów zmusiła nasz program do czynienia cudów.

7. Na koniec chciałbym powiedzieć: bądź ostrożny z bazami danych produkcyjnymi. Nigdy nie łącz się z nimi podczas debugowania! Możesz zapomnieć o powrocie do bazy debugowania, a wtedy… W ostateczności, jeśli musisz coś przetestować na bazie produkcyjnej i nie ma możliwości zrobienia tego na kopii, poproś o pomoc kolegę. Połączysz się z nim, a on pomoże ci się rozłączyć.

Aby więc Twoje programy wykonywały mniej niepotrzebnych cudów, zastosuj te proste zasady. Uchronią Cię one przed wieloma nieszczęściami, o których nawet nie będziesz wiedzieć. A co z alpinistą? Pozwól mu się wspinać, ale teraz jest znacznie mniej prawdopodobne, że się potknie.