On 10/12/2011 18:32, Roman W wrote:
> On Dec 10, 3:22 pm, Andrzej Jarzabek<a...@g...com>
>>
>>> Male szanse, zeby system bankowy napisany w latach 70-tych czy 80-tych
>>> nie przeszedl od tej pory wielu zmian. Zmiany w regulacjach, nowe
>>> produkty, itd.
>>
>> Jasne, ale wydaje mi się, że proporcje będą jednak inne.
>
> Nie wiem. W tej czesci bankowosci w ktorej pracuje, wiekszosc kodu
> jest dosc nowa.
> W detalicznej moze byc oczywiscie inaczej, zwl. w krajach w ktorych
> kapitalizm zaczal sie wczesniej niz w 89 roku.

No więc te wszystkie bankowe systemy w COBOL-u to raczej głównie
bankowość detaliczna. Zresztą jeśli chodzi o bankowość detaliczną, to ja
słyszałem historie o technologiach, przy których COBOL jest jeszcze
całkiem sensownym językiem.

>> Ja, przyznam też nie jestem fanem podejścia "parę miesięcy
>> refaktoryzujemy", znaczy w banku nie pracowałem, ale tak w ogóle wydaje
>> się mało praktyczne. Według mnie sensowniej refaktoryzację powiązać ze
>> zmianami funkcjonalnymi.
>
> Zalezy jak duzo w kodzie jest do poprawki. Dwa razy bralem udzial w
> duzym wysilku porzadkowania kodu. Zwl. w pierwszym przypadku stan
> wyjsciowy byl taki, ze ciezko bylo cokolwiek dodac.
>
> Martin Fowler zdaje sie poleca rozdzielac zmiany funkcjonalne i
> refaktoryzacje?

Jak najbardziej, ale niekoniecznie przecież w skali miesięcy. Po to masz
właśnie inkrementalną technikę refaktoryzacji, żeby nie musieć się
zagrzebywać w jakichś wielomiesięcznych fazach, w których nie możesz
dodawać funkcjonalności.