Na straży wejścia
-
- 08.06.2010
Generalnie jednak pola niosące zawartość tekstową o charakterze opisowym są trudne, jeśli chodzi o dyscyplinowanie ich zawartości. O ile nie mamy do czynienia ze skończonym i przewidywalnym zbiorem wartości, to możliwości pojawiania się tu wszelkiej maści rozmaitości są praktycznie nieograniczone. Czasami projektant oprogramowania chce dobrze, co przeradza się niechcący w koszmar dla użytkownika, chociaż na początku wygląda całkiem zachęcająco.
Pilnować, gdzie trzeba
Czego program nie może, tego użytkownik powinien dopilnować. Jednak wiemy, jak to bywa. Oczywiście, nie bez racji będzie pytanie, dlaczego w takich wypadkach nie posiłkować się jakimiś mechanizmami autokorekty językowej zaczerpniętej żywcem z edytorów tekstu. Można, ale trzeba wziąć pod uwagę, że są to mechanizmy ciężkiej wagi, wymagające sporych narzutów przy w sumie niewielkim z tego pożytku płynącym bądź dające wręcz negatywne skutki, uniemożliwiając wprowadzenie określonej wartości, gdy program "się uprze".
Jeśli wprowadzane informacje mają jedynie opisowy charakter i stanowią tylko pewne przybliżenie rzeczywistości, wówczas nie warto za wszelką cenę walczyć o zapewnienie mechanizmów kontroli i autokorekty. Często wręcz narzuty z takich mechanizmów wynikające przynoszą więcej szkody niż pożytku. Są jednak miejsca, w których szczególnie uważnie powinno się pilnować wprowadzanych informacji, zwłaszcza tych, które biorą udział w późniejszym przetwarzaniu lub mają istotny wpływ na bieg spraw.
Ustawiając twarde warunki automatycznej kontroli danych wejściowych należy liczyć się z tym, że zawsze pojawią się wyjątki, zaistnieją sytuacje nie wzięte pod uwagę przy opracowywaniu projektu, co spowoduje błędną interpretację faktów. Poza tym nie istnieje żaden algorytm strzegący w sposób doskonały czegoś, co jest nie do końca i jednoznacznie zdefiniowane.
Podczas prowadzenia jednego z projektów systemu internetowej rejestracji klientów założyliśmy, że pole nazwiska będzie sprawdzane na obecność przynajmniej trzech znaków - tylko dlatego, aby dowcipnisie nie wykpiwali się czymkolwiek. Wydawało się wówczas, że niemożliwe jest istnienie krótszych nazwisk. Kilka dni później znalazłem w lokalnej prasie nekrolog osoby noszącej nazwisko Ek. Jako że było to źródło wiarygodnej informacji, wyciąłem nekrolog i wręczyłem go, jako "życiowy" dowód problemu, prowadzącemu ten odcinek programiście, który przyjął to ze zdziwieniem i ku pamięci powiesił na swojej korkowej tablicy. Po zakończeniu realizacji projektu programiście temu podziękowano za współpracę z tytułu kryzysowej redukcji etatów. Wieszanie nekrologów, nawet jeśli w słusznym celu, jest chyba jednak złym omenem.
Z nazwiskami nigdy nie wiadomo do końca jak postąpić. Gdyby chodziło tylko o polskie, nie byłoby problemu, nawet z tymi dwuczłonowymi, łączonymi myślnikiem. Oprogramowanie byłoby w stanie samo zadbać o wstawienie łącznika, wycięcie spacji okalających i normalizację wielkości liter. Problem zaczyna się wraz z pojawianiem się nazwisk niepolskich, zawierających nietypowe u nas przedrostki: van, der, von, de. Okazuje się, że w takim zestawieniu dopuszczalnych kombinacji wartości wieloczłonowych zagadnienie algorytmicznej autokorekty nazwiska należy z konieczności uprościć do utrzymywania stałych odstępów między składnikami i pozbycia się nadmiarowych odstępów. I pomyśleć tylko, jak ambitne wytyczne kreowano przy rozpoczynaniu projektu, a na czym się skończyło. Znowu okazuje się, że życie swym bogactwem sytuacji potrafi zweryfikować niejedne założenia.
