Zostań magiem programowania

Programista powinien pisać programy od razu poprawnie. Jeśli nie jest to możliwe, powinien poddawać swój kod wnikliwemu testowaniu. A jeśli ten etap nie zostanie przeprowadzony jak należy, niechybnie pojawią się błędy wykonania. Przyczyn błędów programista powinien dopatrywać się u siebie, a nie poszukiwać zaczarowanej fikcyjnej ich genezy.

Programista powinien pisać programy od razu poprawnie. Jeśli nie jest to możliwe, powinien poddawać swój kod wnikliwemu testowaniu. A jeśli ten etap nie zostanie przeprowadzony jak należy, niechybnie pojawią się błędy wykonania. Przyczyn błędów programista powinien dopatrywać się u siebie, a nie poszukiwać zaczarowanej fikcyjnej ich genezy.

Ciągle jest sporo wyznawców inżynierii programowania określonej jako voodoo programming, których wiara w magię jest silniejsza od logiki. I niestety do grona tego oprócz użytkowników należy cała masa programistów. Jak łatwo jednak przekroczyć tę kruchą granicę, będąc nawet doświadczonym i świadomym programistą, niech świadczą opisane tu przypadki. O tym, jak o mały włos nie zostałem wciągnięty w czeluść sekciarskiego nurtu programowania, jak omal nie zszedłem z prostej i świetlanej drogi logiki i jak krzewiłem wiedzę oraz prostowałem ścieżki młodszych kolegów, będę dzisiaj pisał.

W jednym z programów mam generator procedur składowanych. Generator ten pobiera kod źródłowy zapisany lokalnie, przekazuje go na serwer i nadaje uprawnienia wykonawcze. Tak dzieje się w środowisku eksploatacyjnym. Zanim jednak procedury zostaną oddane do szerokiego użytkowania, przechodzą cykl konstrukcyjny w niezależnym środowisku testowym. Każde uruchomienie procedury w tym środowisku powoduje utworzenie jej od nowa i zapamiętanie na serwerze testowym - jednak bez uprawnień, które nie są tu potrzebne. Gdy taki sam "numer" zrobi się na serwerze produkcyjnym, użytkownicy tracą możliwość wykonania pewnych funkcji. I zdarzyło się, że przyszedł pan Marek, któremu (jak zwykle) coś się nie zgadzało w "jego" danych. Uruchomiłem więc w pośpiechu (jak zwykle) stosowną procedurę składowaną, korzystając z mojego środowiska testowego, ale w bazie eksploatacyjnej, aby mieć dostęp do rzeczywistych danych. Sprawa została pozytywnie wyjaśniona, bo w gruncie rzeczy wszystko było w porządku, tylko pan Marek wyciągnął złe (jak zwykle) wnioski z wyników. Wiele dni później zgłasza się pan Marek ponownie, że mu ta funkcja w aplikacji nie działa. Po analizie doszedłem do wniosku, że ktoś zdjął uprawnienia do wykonania procedury na serwerze. Zastanawiałem się, kto mógł coś tu grzebać i to w tak subtelnym zakresie. Uczuliłem także na sprawę nowego administratora. Prawdę powiedziawszy, to nawet miałem podejrzenia w stosunku do niego. Wiele tygodni później sytuacja - można powiedzieć - powieliła się. Po dłuższej chwili namysłu wykluczyłem czyjeś celowe działanie. Po jeszcze dłuższej chwili przypomniałem sobie, że już coś takiego miało miejsce. Za moment wiedziałem już, że sprawcą tego jestem ja sam. Od tej pory wisi przede mną kartka z czerwonym napisem: "uwaga na uprawnienia przy testowaniu procedur".

Niedawno mój podwładny poprosił mnie o pomoc w znalezieniu błędu. Chodziło o to, że do istniejącej już funkcji miała być dodana kontrola elementu o numerze dostarczanym przez jeden z parametrów funkcji. Pracownik dopisał jedną zaledwie prostą instrukcję i wystarczyło, aby zaczęła dziać się jakaś magia. Zaleciłem wyłączyć programową obsługę błędu, która zbytnio maskowała szczegóły. Debuger pokazał, że numer elementu jest jakiś z kosmosu wzięty. Sprawa okazała się trywialnie prosta: do funkcji były przekazywane dwa parametry numeryczne, a ten niewłaściwy w tym zastosowaniu to numer klienta. I pech chciał, że programista akurat jego sobie upodobał.

Jeśli mimo wszystko ktoś wierzy w magię, to naprawdę nie ma podstaw, aby dopatrywać się jej przejawów w informatyce - w żadnej odmianie, odcieniu i natężeniu. Nawet jeśli pozory zdają się przemawiać za cudami, to jest to tylko i wyłącznie objaw niewiedzy.


TOP 200