Dalsi priklad z praxe: autor predvidavo spravil transakcnu tabulku + uzavierkove zaznamy. Takze jeden by si pomyslel, ze mudro nespravil "fail pri navrhu". Ale chyba lavky. Po rokoch prisiel statny organ a povedal "dajte report" a ten vyzaduje pohlad nekorespondujuci s tymi "uzavierkovymi zaznamami", takze sa to robi z tych transakcnych.
Hele to ze prijde zmena pozadavku je v poradku... a je ocekavany stav ze bude potreba do toho sahnout a upravit aby sel snadno generovat novej typ reportu...
(Teda slysel jsem o pripadu kdy se proti tomu firma celkem uspesne branila prez pravniky, protoze provadeci predpis k novele nespecifikoval presne interval a tudiz stary report technicky vyhovoval a tak museli
statni organi chytnout abakus a dopocitat si to rucne... ale)
Proste kdyz vyvijim novej report tak se u toho bude muset prepocitat ta transakcni tabule... ale samozrejme si muzu mezivypocty ulozit pro priste, protoze uz budu ocekavat ze prijdou a budou ten report chtit znova...
Nicmene... jak casto vam prijde "statny organ" ze chce novej report? Jednou za kvartal?
No a jak casto prijde update technologii co pouzivate? A jak casto se stane, ze tam je nejaka nekompatibilita a musi se premigrovat na nejakou novou verzi? A jak casto se stane za se vam objevi nejaky security vulnerabilities ktery musite fixnout updatem nebo migraci na jinou knihovnu? U nas se to deje radove casteji... spousta je automatizovana a vsechno jede jak po masle... Dokud se nenarazi na to, ze nejakej chytrolin kvuli nejaky optimalizaci pouzil neco co je deprecated... nebo "radoby sealed" a chytre to zapece do kodu primo na urovni entitnich typu.
A o tom ja mluvim... nikdo nemuze hadat na patnact let dopredu, ze budou nejaky legislativni zmeny vyzadujici reporting...
Ale je celkem snadny uhodnout ze ta knihovna kterou jsem vybral tak bud bude mit nove verze, nebo security issues... nebo proste nebude a budu ji muset nejak nahradit...
Takze proste potrebuju abstrahovat od technikalii a ochranit svoji business logiku pred technickymi zmenami.