Nazewnictwo procedur

Nazewnictwo procedur to konwencja nazw porządkująca kod bazy — odradza się przedrostka sp_, zarezerwowanego dla procedur systemowych.

Nazewnictwo procedur jako porządek kodu bazy danych

Nazewnictwo procedur oznacza przyjęty sposób tworzenia nazw dla procedur składowanych, czyli zapisanych w bazie danych zestawów instrukcji wykonywanych na żądanie aplikacji, administratora albo zaplanowanego mechanizmu. Sama nazwa nie zmienia działania procedury, ale wpływa na to, czy kod można łatwo odczytać, wyszukać, utrzymać i bezpiecznie rozwijać. W większym systemie procedury są wywoływane przez wiele modułów, raportów, formularzy i usług. Jeżeli każda z nich otrzymuje nazwę według innej zasady, szybko powstaje zbiór trudny do opanowania.

Dobra konwencja powinna od razu sugerować przeznaczenie obiektu. W nazwie można odzwierciedlić czynność, główny obiekt danych oraz ewentualny kontekst działania. Przykładowo nazwa opisująca pobranie aktywnych zamówień jest czytelniejsza niż skrót złożony z przypadkowych liter. Nie oznacza to, że nazwa ma zastępować dokumentację. Powinna jednak stanowić pierwszy, zwięzły komunikat o tym, co dana procedura robi i jakiego rodzaju wynik może zwrócić.

Przy porządkowaniu istniejącego kodu warto najpierw ustalić słownik pojęć. Należy rozstrzygnąć, czy stosowane będą czasowniki w języku polskim, angielskim czy w innym uzgodnionym standardzie, jak zapisywane są liczby pojedyncze i mnogie, a także czy człony nazwy rozdziela się podkreśleniami. Najważniejsza jest konsekwencja. Jedna reguła stosowana przez cały zespół zwykle przynosi więcej korzyści niż pozornie krótsze, lecz zmienne nazwy.

Nazewnictwo procedur a kontekst techniczny i porównanie konwencji

W praktyce spotyka się kilka sposobów budowania nazw. Pierwszy opiera się na czasowniku i obiekcie, na przykład czasowniku oznaczającym odczyt, dodanie, zmianę albo usunięcie danych, po którym występuje nazwa encji. Drugi podkreśla cel biznesowy, taki jak przygotowanie zestawienia, sprawdzenie uprawnień lub zamknięcie okresu. Trzeci wykorzystuje nazwy wskazujące etap przetwarzania, na przykład walidację danych wejściowych albo przygotowanie wyniku do eksportu. Każde podejście może być poprawne, o ile zakres procedury pozostaje jasny.

Warto oddzielić nazwę procedury od nazw tabel, kolumn i funkcji. Te elementy mogą mieć podobne słownictwo, lecz nie powinny tworzyć dwuznaczności. Jeżeli procedura modyfikuje dane, powinno dać się to odczytać z nazwy lub z ustalonego schematu. W przypadku procedur zwracających dane przydatne jest rozróżnienie zapytań służących do pobierania listy, pojedynczego rekordu, podsumowania albo danych przeznaczonych do raportu. Nie należy jednak tworzyć bardzo długich nazw zawierających każdy szczegół implementacji, ponieważ po zmianie kodu nazwa może stać się myląca.

Porównując konwencję opartą na skrótach z konwencją opisową, zwykle łatwiej utrzymać tę drugą. Skróty bywają wygodne dla osób, które je utworzyły, ale utrudniają pracę po zmianie zespołu lub po dłuższej przerwie. Warto też uważać na nazwy sugerujące działanie szersze, niż rzeczywiście wykonuje procedura. Jeżeli procedura tylko sprawdza warunek, nie powinna nazywać się tak, jakby zatwierdzała operację. Jeżeli zmienia jeden rodzaj danych, nie powinno się używać określenia sugerującego aktualizację całego obszaru.

W wielu środowiskach odradza się stosowanie przedrostka sp_, ponieważ może kolidować z rozpoznawaniem procedur systemowych i utrudniać interpretację obiektów. Zamiast tego można wykorzystać neutralny, uzgodniony schemat, który wskazuje funkcję, moduł albo typ operacji. Przed wdrożeniem zasad należy sprawdzić ograniczenia konkretnego silnika bazy danych, dozwolone znaki, wielkość liter oraz sposób traktowania nazw podobnych do słów zastrzeżonych.

Nazewnictwo procedur i typowe problemy w codziennym utrzymaniu

Jednym z częstszych problemów jest mieszanie kilku konwencji w tej samej bazie. Część procedur może mieć nazwy opisowe, część skrócone, a część może zawierać nazwiska autorów, daty albo oznaczenia związane z dawną wersją aplikacji. Taki zapis szybko traci wartość informacyjną. Data w nazwie nie zawsze oznacza wersję, która jest aktualna, a inicjały autora nie mówią, kto obecnie odpowiada za utrzymanie.

Innym problemem jest umieszczanie w nazwie szczegółów, które powinny pozostać w parametrach. Jeżeli procedura może działać dla różnych statusów, nie należy tworzyć osobnej nazwy dla każdego statusu tylko po to, aby opisać wartość wejściową. Podobnie nie powinno się mnożyć obiektów przez różne formaty dat, sortowania lub warianty filtrowania, jeżeli jeden czytelny interfejs może obsłużyć te przypadki.

Ryzyko powstaje także wtedy, gdy nazwa nie odzwierciedla skutków ubocznych. Procedura określana jako pobierająca dane może w rzeczywistości zapisywać log, zmieniać status albo usuwać rekordy pomocnicze. Taką rozbieżność trzeba wyjaśnić przez zmianę nazwy, podział odpowiedzialności lub dokumentację. W przeciwnym razie osoba wywołująca procedurę może użyć jej w niewłaściwym miejscu, zakładając, że jest bezpieczna tylko do odczytu.

Warto zweryfikować również zgodność nazw z mechanizmem uprawnień. Nazwa nie zastępuje kontroli dostępu, ale może pomóc w audycie. Procedury wykonujące operacje modyfikujące powinny być łatwe do odfiltrowania w katalogu obiektów. Przydatne jest także sprawdzenie, czy podobne nazwy nie dotyczą różnych schematów, baz albo środowisk. Drobna różnica w zapisie może prowadzić do wywołania niewłaściwego obiektu, szczególnie gdy narzędzia podpowiadają nazwy automatycznie.

Nazewnictwo procedur a praktyczne wskazówki wdrożeniowe

Prace nad konwencją dobrze rozpocząć od krótkiego dokumentu zawierającego kilka reguł i przykładów. Należy opisać kolejność członów, dopuszczalne separatory, sposób oznaczania procedur odczytujących i modyfikujących dane oraz zasady dla operacji raportowych. Warto także wskazać nazwy, których nie należy używać, w tym przedrostki mogące sugerować przynależność do mechanizmów systemowych. Dokument powinien być na tyle zwięzły, aby można było korzystać z niego podczas codziennego tworzenia kodu.

• Najpierw należy nazwać czynność lub cel procedury, a następnie określić główny obiekt danych.
• Należy używać jednego języka i jednolitej formy czasowników w całym obszarze projektu.
• Nie powinno się umieszczać w nazwie wartości parametrów, nazw osób ani informacji zależnych od bieżącej wersji.
• Każda procedura powinna mieć jasno określony zakres odpowiedzialności.
• Zmiana nazwy powinna uwzględniać wszystkie miejsca wywołania, skrypty wdrożeniowe i dokumentację.

Podczas przeglądu kodu można stosować prostą listę kontrolną. Najpierw sprawdza się, czy nazwa jest jednoznaczna bez otwierania treści procedury. Następnie ocenia się, czy nie myli odczytu z modyfikacją, czy nie zawiera zbędnych skrótów oraz czy odpowiada aktualnemu zakresowi działania. Jeżeli procedura z czasem rozrosła się i wykonuje kilka niezależnych zadań, sama zmiana nazwy może nie wystarczyć. Wtedy rozsądniejsze bywa rozdzielenie jej na mniejsze elementy.

W starszych bazach nie zawsze opłaca się zmieniać wszystkie nazwy jednocześnie. Bezpieczniejszy bywa etapowy proces: sporządzenie spisu obiektów, oznaczenie nazw problematycznych, ustalenie reguł dla nowych elementów, a następnie planowe porządkowanie najczęściej używanych procedur. Przed zmianą należy ustalić zależności i przygotować możliwość wycofania modyfikacji. Szczególnej uwagi wymagają aplikacje, które przechowują nazwy procedur w konfiguracji albo wywołują je dynamicznie.

Nazewnictwo procedur i moment zgłoszenia problemu do serwisu

Trudności z procedurami często ujawniają się nie podczas samego pisania kodu, lecz przy pracy komputera: pojawiają się długie oczekiwania, błędy połączenia z bazą, nieoczekiwane zamknięcia narzędzia, problemy z uruchomieniem środowiska programistycznego albo utrata dostępu do plików projektu. Przyczyną może być zarówno konfiguracja aplikacji, jak i usterka nośnika danych, pamięci, chłodzenia lub systemu operacyjnego. W takiej sytuacji warto najpierw zabezpieczyć kopię kodu i logów, a potem przekazać urządzenie do sprawdzenia.

Do serwisu warto zgłosić się także wtedy, gdy komputer działa niestabilnie po aktualizacji, nie rozpoznaje dysku z projektem, nadmiernie się nagrzewa albo samoczynnie się wyłącza podczas kompilacji i testów. Przydatne jest opisanie objawów, momentu ich wystąpienia oraz zmian wykonanych tuż przed awarią. Dzięki temu łatwiej rozdzielić problem z nazewnictwem lub konfiguracją procedur od problemu sprzętowego. W Warszawie takie zgłoszenie można skierować do firmy Warszawskie Pogotowie Komputerowe 24/7, przedstawiając model urządzenia i krótki opis sytuacji.

Przed przekazaniem komputera należy, o ile jest to możliwe, wykonać kopię zapasową repozytorium, plików konfiguracyjnych oraz dokumentacji. Nie powinno się jednak wielokrotnie uruchamiać uszkodzonego dysku, jeżeli występują niepokojące dźwięki albo znikają pliki. W przypadku danych zawierających hasła, klucze dostępu lub informacje poufne należy usunąć zbędne kopie i jasno określić, jakie materiały mogą zostać udostępnione do diagnostyki. Dzięki temu uporządkowane nazewnictwo procedur będzie wsparte równie uporządkowanym i bezpiecznym podejściem do całego środowiska pracy.