Nowy rok, nowe błędy. Wpis miał być o czymś innym, tzn. miało to być podsumowanie poprzedniego i plany na obecny rok, ale jak to w życiu bywa, plany poszły się paść. Będzie o czymś, moim zdaniem, ciekawszym. Będziemy przyzywać wielkich przedwiecznych W.

Kontekst

Mając możliwość obcowania z różnymi systemami, zauważyłem pewną prawidłowość. Im bliżej biznesu umieszczamy kod, tym bardziej niezrozumiałe i skrótowe są nazwy. Dotyczy to zarówno nazw usług, jak i bytów biznesowych. Co ciekawe w dokumentacji mamy do czynienia z całymi tabelami translacji, które tłumaczą nazwy domenowe na nazwy techniczne. Jednocześnie im bardziej zagłębiamy się w kod, tym bardziej opisowe i abstrakcyjne nazwy poszczególnych elementów. Takie nazewnictwo, zarówno bliżej biznesu jak i bliżej krzemu ma pewne negatywne konsekwencje.

Nazwy skrótowe

Wiele lat temu pracując przy systemie SIS, spotkałem się z bardzo ciekawym problemem. Pewien fragment systemu posługiwał się nazewnictwem pozbawionym samogłosek. No spoko, da się żyć z tego typu „optymalizacją”. Tyle tylko, że nazwy pochodziły z języka portugalskiego. No kurwa…

Dopiero wtedy odkryłem, po co mi była karteczka z tłumaczeniami, którą otrzymałem pierwszego dnia od liniowego. Tak, zawierała ona tłumaczenie skrót → całe słowo po portugalsku → słowo po angielsku, bo oczywiście klasy były już w cywilizowanym języku. Narzut komunikacyjny, który był spowodowany koniecznością, takiego wielokrotnego tłumaczenia był znaczny.

Kolejny ciekawy przykład, to tytułowy PrtDtRefStsMngmnt, który jest nazwą klasy. Spoko, prawda? Tylko co to, kurwa, jest? A teraz wyobraźcie sobie, że spotykacie taki oto fragment kodu:

Listing 1. Co to?

List<String> attrList=prtDtRefStsMngmnt.queryPrtDtRefSts();

Cytując klasyka, o co tu kurwa jego mać chodzi, w tym burdelu? Pozostawię was z tym problemem.

Powyższy kawałek kodu jest wynikiem pracy z SOAP-em i usługami na szynie danych. Tak już się jakoś złożyło, że biznes postanowił oszczędzić kilka znaków i spłodził potworka.

Dlaczego tak się dzieje?

Moje obserwacje wskazują na trzy główne powody używania tego rodzaju konwencji nazewniczych. Po pierwsze to ograniczenia innych technologii. XML nie jest jakoś specjalnie elastyczny, jeśli chodzi o nazwy. Podobnie wiele narzędzi około XML-owych wprowadza własne ograniczenia związane zazwyczaj z długością nazw. Po drugie na poziomie analizy istnieje silna potrzeba upraszczania. Upraszczanie jest najbardziej widoczne na poziomie długości nazw. Działa to trochę jak taka typowa restrukturyzacja w przedsiębiorstwie. Wywali się 30% załogi, a reszcie utnie pozapłacowe dodatki i będzie zreformowane. Nie ważne, że procesy nadal są słabe, ale finansowo widać poprawę. Podobnie tutaj. Wywali się długie nazwy, które robią wrażenie skomplikowania systemu. W zamian wstawi się skróty, które będą wyglądać mądrze i pseudo-technicznie, a jednocześnie przepchną „komplikację” na stronę techniczną. Inaczej mówiąc, analitycy chcą dobrze, ale ci techniczni… Po trzecie lenistwo w pisaniu. Dziesięć znaków wedle konwencji pisze się szybciej niż 20 pełnej nazwy.

Oczywiście jest to moja obserwacja i może być błędna, ale chyba nie mylę się jakoś szczególnie.

W niektórych przypadkach, szczególnie bardzo starych systemów, przyczyną są rzeczywiste ograniczenia techniczne. W DOSieW nazwa pliku mogła mieć jedynie osiem znaków plus trzy znaki rozszerzenia. Tyle tylko, że DOS umarł w 2003 roku wraz z wersją 7.1 (dla specyficznych maszynek IBMa).

Konsekwencje

Najpoważniejszą konsekwencją są wspomniane wcześniej zatory komunikacyjne. Nowa osoba wchodząca do projektu musi poświęcić mnóstwo czasu i energii na odszyfrowanie dziwnych nazw. Czy stać nas na ten luksus? Chyba tak, bo twardo trzymamy się tego typu nazw. Kolejny problem to błędy wynikające ze stosowania intuicji. Jeżeli mamy takie oto nazwy:

  • attrValStr
  • attrValInt
  • attrValBool
  • attrValReal

to, co oznacza attrValPrnt? Odpowiedź będzie w jednym z kolejnych postów, a na razie czekam na propozycje w komentarzach.

Podsumowanie

Blogonotkowe życie toczy się samo. Miała być szybka notka będą pewno trzy. Jednocześnie mam nadzieję, że mi się uda wrócić do regularnego pisania 🙂