Pracując z dużymi systemami komputerowymi, nabrałem pewnych przyzwyczajeń, z których dzisiaj, w środowisku mikrokomputerów, trudno mi zrezygnować, tym bardziej że nawyki owe zaliczyć należy w poczet pozytywnych. Mam tutaj na myśli np. rozdzielanie kodu programu od zewnętrznych zasobów.

W dużych systemach etapowi wykonania towarzyszył opis zadania, w którym były zdefiniowane wszelkie niezbędne zasoby, jak dyski i drukarki. Zmiana zasobów zewnętrznych nie wymagała konieczności ingerencji w źródło programu. Czynię tak i teraz, aczkolwiek innymi sposobami, dając operatorowi możliwość zdefiniowania ścieżek dostępu do baz danych oraz wielu innych parametrów. Korzyści z tego wynikające są oczywiste, chociaż na etapie kodowania trzeba się trochę napracować.

Programy bogato parametryzowane przerzucają na użytkownika cały trud związany z konfiguracją środowiska, czyniąc przedeksploatacyjny etap przygotowawczy zajęciem dosyć żmudnym i wymagającym znajomości istoty rzeczy, niemniej osiągnięta elastyczność rozwiązania odpłaca się z nawiązką w okresie ustabilizowanej eksploatacji. Spotkałem w swojej praktyce wiele programów, które nawet nie przewidywały możliwości dynamicznego wskazania folderu docelowego podczas instalacji, nie mówiąc już o określeniu innego niż narzucony folder z plikami danych. Osobiście nie popieram, a wręcz odradzam tego typu rozwiązania, głęboko trącające amatorszczyzną.

Nie o wszystkich kwestiach dotyczących funkcjonowania oprogramowania użytkownicy powinni wiedzieć, stąd wiele flag parametrycznych umieszczam bezpośrednio w programie. Dotyczy to przede wszystkim obsługi błędów wykonania, które mogą być jawnie sygnalizowane lub przechodzić nie zauważone dla użytkownika. Oczywiście dotyczy to tylko błędów określonej klasy, których pojawienie się może być przez program zniwelowane i nie wpływa na jakość danych. Generalnie błędów nie należy lekceważyć, nawet jeżeli wydają się nie znaczące - można natomiast reagować na nie "głośno" lub po "cichu".

Pisząc programy, staram się unikać wszelkich niejednoznaczności, które mogłyby konfundować użytkowników. Stąd nie dopuszczam, aby na ekranie pojawiały się polecenia typu: "wpisz odpowiedź: a, b, c lub d", obawiając się, że musiałbym kontrolować, czy w tekstowym okienku wpisu nie pojawiło się "lub" i czy tekst odpowiedzi składa się rzeczywiście z jednego znaku, który nadto nie jest przecinkiem.

Staram się ograniczać ilość ręcznego wpisywania przez operatorów, tam gdzie nie jest to rzeczywiście niezbędne. Ostatnio udało mi się stworzyć program, w którym - poza jednorazowym, wstępnym wpisaniem danych parametrycznych - całą konwersację z użytkownikiem, w tym i wprowadzanie danych (pobieranych oczywiście z już istniejących zbiorów), można załatwić bez dotykania klawiatury. Doprowadziłem nawet do tego, że usuwanie elementu lub jednego znaku jest wykonywane myszą. Zakrawa to na wprowadzanie reżimu wśród użytkowników w czasach demokracji, ale porządek musi być.

Jeśli chodzi o kwestię parametryzowania, jednej rzeczy nie udało mi się do tej pory rozwiązać - jak poprzez plik parametrów definiować ścieżkę dostępu do niego samego.