Cezary Gr?dys <c...@w...onet.pl> wrote:
> W dniu 20.03.2017 o 10:22, J.F. pisze:
> >
> > U?ytkownik "Cezary Gr?dys" napisa? w wiadomo?ci grup
> > dyskusyjnych:58cf885b$0$5154$6...@n...neostrada
.pl...
> > W dniu 17.03.2017 o 19:35, J.F. pisze:
> >>> Ale to przeciez trzeba sprawdzic, czy sie nie odwoluje. I czek sie
> >>> nalezy.
> >
> >> Ale sprawdzi? 10 linijek, czy 10 milion?w to taka sama robota.
> >
> > 10 mln zapewne nie jest w jednym pliku. I ilosc roboty rosnie.
> > Ewentualnie "za sprawdzenie 1$. Za to, ze wiedzialem jak to zrobic w 5
> > minut 999$"
> >
> > J.
> >
> Jak tylko sprawdzi?, to niewiele wi?cej roboty
> find -type f -exec grep .... {} \; -print
>

Kompletenie nie doceniasz problemu. Programy bankowe
sporo dzialaja z datami (procenty, raty, zlecania
terminowe). Po czyms w tym stylu wyjdzie Ci powiedzmy
10000 potencjalnych lini z problemem. Do wielu z nich
przychodza dane z wielu miejsc. Jak to zaczniesz naiwnie
sledzic to moze wyjsc 1 milion liniejek do dokladniejszego
sprawdzenia.

W realu uzywano calkiem zaawansowanych narzedzi, ktore
proste problemy potrafily automatycznie naprawiac
(o ile wiem np. powiekszyc rozmiar wszystkich zmiennych
w prostym ciagu zaleznosci). Oprocz powiekszania pol
stosowano tez "okienkowanie": w 100-letnim okienku
np. 50 od bierzacego w przod to przyszlosc, 50 w tyl
przeszlosc. Poprawnosc "okienkowania" zalezy od tego
czy moga sie pojawic duze roznice dat, jesli nie to
jest OK. Takie sprawdzenie to sporo roboty (trzeba
dobrze zrozumiec program), ale ogranicza zmiany w
kodzie. A mimo narzedzi zostawalo sporo kawalkow
ktore trzeba bylo recznie przepisac. Tzn. nie tylko
sprawdzac ale wprowadzic istotne zmiany.

Zeby byla jasnosc: ja sam nie mam nic wspolnego z
systamami bankowymi. Ale mam dosc doswiadzczenia
z softwarem i dosc czytalem o problemie i metodach
zeby docenic problem i rozwiazanie.

Nie chce mi sie teraz za tym googlowac, ale z tego
z pamietam byly w male zaciecia w paru bankach.
Bez dwu lat naprawiania problemy mogly byc duzo
wieksze.

PS. Nie mowie ze cala ta histora problemu roku
2000 byla racjonalna: przez ponad 20 ignorowano
problem a potem przez 2 lata bylo gaszenie pozaru.
Ale byl problem i choc niepotrzebnie duzym kosztem
to uniknieto wiekszych skutkow.

PS2. Jak na razie to wyglada ze przed 2038 moze
byc powtorka, tyle ze z C i Unixem.

--
Waldek Hebisch