Konstantide tabel kui anti-pattern?

Iga vähegi pikemat aega kasutuses olnud süsteem on täis selliseid asju ja 5 aastat hiljem avastad, et oled ka ise siin ja seal üle nurga lasknud. Mida sellisel juhul teha?

1. Kirjelda probleem ja selle potentsiaalsed tagajärjed veahaldussüsteemis veana (te ju ikka kasutate veahaldusüsteemi?).
2. Tõsta teema üles järgmise arendusiteratsiooni planeerimise koosolekul (te ju ikka kasutate iteratiivset arendusmetoodikat?).
3. Mõned vead ei väärigi parandamist, mitte kohe. Olen kindel, et järgmise aasta jooksul (hiljemalt 2015) satub ette mingi situatsioon, mille puhul antud koodi ümberkirjutamine teeb lihtsamaks mingi kasutajale olulise funktsiooni realiseerimise või parandab olulise vea. Voila - Sul ongi konks käes oma unetust põhjustava koodi ümberkirjutamiseks.

On mõeldav kombinatsioon päringukeelest, andmemassiivist ja ekspert-lõppkasutajast, kellel on 80-veerulise pea asemel kartesiaanpea, mis on võimetu harjuma ajamärke mingisugusel teisel, isegi SQLi date/time vahenditega töötlema. Sel puhul on lokaalselt olulisem antipattern selles, et arendaja ei suuda lahti selgitada, mis värk põikpäise lõppkasutajaga on ja ei ole ära dokumenteerinud, et 2015. aasta paiku rakendus katki läheb.

Nüüd, kui kasutaja on ära õigustatud (kuupäevaformaat on reetlik ;) ), teistpidi ka. Aastate/kuude/päevade rehkendamine on oma olemuselt protseduuriline töö ning viisakas arhitektuuris selliseid tabeleid ei tehta. Eestikeelseid kvartalilühendeid ka viisakas arhitektuuris andmetabeli sisse ei kirjutata. Ja viisakas arhitektuuris hoitakse ajamärke ajamärgi-, mitte stringitüüpi veergudes, mille positiivsete omaduste hulka kuulub muuhulgas see, et mootor oskab nende ajamärkidega teha mingisuguseid rehkendusi, näiteks välja arvutada, mitu päeva 1995. aasta algusest möödas on. Negatiivne omadus on muidugi, et müstilise süsteemiga liidestamisel võib ajamärki olla tarvis konverteerida, aga mõistlikult korraldatud arendustegevuse korral on see triviaalsus, mille positiivsed omadused kuhjaga üles kaaluvad.

Ja viisakas organisatsioonis ei ole "töötab nii ka" legitiimne abstraktsioonitase konstruktiivse kriitika tagasi lükkamiseks. Vähemalt triage'i võiks ikka ära pidada ja jälje maha jätta, et vaialised X, Y ja Z on küsimuse läbi arutanud ja leidnud, et kõnealuse projekti kontekstis oleks parandamisest saadav tulu väiksem kui andmemudeli muutmisele ja põikpäise kasutaja Q ümberkoolitamisele tehtavad kulutused. Kui 2016. aastal süsteemi pangestumisest miljonieuroline kahju sigineb, siis saab süsteemihaldur tõendada, et mitte tema ei ole süsteemi kehvasti hallanud vaid vaialised hindasid miljoni euro kaotuse riski tuhande euro kokkuhoidmise nimel aktsepteeritavaks.

Alustades vastuse "nii töötab ju ka" aktsepteerimisega ja samm-sammult allapoole langedes võib lõpuks igasugust jama läbi lasta. Näiteks, milleks siis üldse tabeli veergudele nimesid panna, kui numbrid töötavad sama hästi jne.

Andmebaasi enda võimaluste kasutamise seisukoha toetuseks lisan järgmised (triviaalsed) argumendid: 1. väheneb rakendust moodustava koodi hulk, millest omakorda järelduvad väiksemad arendus ja testimiskulud. 2. standardsed kuupäeva ja kellaaja väljad on arendusvahendite poolt toetatud, millega omakorda vähenevad arenduskulud veelgi. Kui neid asjaolusid välja tuua, on mõistlik otsida välja viide ka mõnele asjalikule programmeerimisõpikule (võib-olla ka sqli käsiraamatule), sest niiviisi saad võimalikud vastuväited suunata endast mööda autoriteetsete õpikute autorite pihta. Kas Stroustrup on tõesti loll ja eksis nii lihtsas asjas? Pigem mitte. Ma ise ei oska hetkel kahjuks viiteid anda, võib-olla mõni targem aitab.

Administreerimise koha pealt tekib ka kohe küsimus, et mis siis saab, kui programmi vea tõttu on andmed eri veergudes omavahel vastukäivad (esimeses tabelis võib nii juhtuda aastaga). Kas on selle kohta juhendid olemas või annab programmi tootja äkki garantii, et nii ei juhtu kunagi?