Kamil Jońca pisze:

>> Przykład jest nieadekwatny, bo w tym konkretnym wątku rozmawiamy o
>> konkretnym błędzie w implementacji. Nie przekonasz mnie, że jakakolwiek
>> specyfikacja kazała informatykom celowo nie odróżniać wypłaty od zapłaty.
>
> A dlaczego? Może na początku nie odróżniali "sprzedaży" od
> "sprzedaży+cashback" bo nie było to do niczego potrzebne.

Są to dwie różne operacje i to wystarczy. Bank powinien dysponować pełną
wiedzą, choćby na wypadek, gdyby klient złożył reklamację.

A ja nie wyobrażam sobie, że kodując cokolwiek mógłbym nie odróżnić
różnych możliwych przypadków. Jasne wyodrębnienie wszystkich możliwych
sytuacji wejściowych jest podstawą przejrzystego i łatwo modyfikowalnego
algorytmu.
Z tym że ja programowałem w czasach, gdy się liczyło bajty, więc moje
podejście jest zapewne mocno niewspółczesne... Kto by się dziś
przejmował takimi bzdetami...

> (Bo jeśli się nie nalicza opłat za np. CB to po co rozróżniać?)

Choćby po to, żeby debuggowanie się udało. A testy, które nie
uwzględniają różnych możliwych sytuacji to po prostu złe testy są...

> I tak zostało, bo stwierdzono że dla paru świrów z pbb nie opłaca się
> modyfikować systemu.

To być może. System nie został zmodyfikowany i już nie zostanie. Ja
jednak twierdzę, że on od początku źle był zaprojektowany. Nawet jak
jeszcze nie było potrzeby rozróżniania, to system wewnętrznie
powinienbył rozróżniać.

W zasadzie jedynym rozsądnym powodem nierozróżniania może być fakt, że
kiedyś w ogóle nie było takiej usługi, więc nie było takiej możliwej
sytuacji. Jak usługę nową wymyślono, to programiści poszli na łatwiznę i
zamiast dodać pełną obsługę nowej sytuacji, po prostu dodali swego
rodzaju protezę - czyli sprowadzili nowy przypadek do przypadku już
rozwiązanego, tracąc po drodze pewne dane. W starych systemach takie
rakowe narośla często się pojawiają, a potem są przyczyną problemów - bo
"ktoś czegoś nie przewidział".

--
MiCHA