On Dec 10, 3:22 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On 10/12/2011 12:54, Roman W wrote:
>
> > On Dec 10, 12:24 pm, Andrzej Jarzabek<a...@g...com>
> > wrote:
> >> Kolejna sprawa to wiek samego kodu - jeśli weźmiemy jakiś system bankowy
> >> napisany w czymkolwiek, który powstał w latach 70-tych czy 80-tych i co
> >> najmniej od 15 lat ma stabilne ficzery, a wysiłek idzie w dużej mierze w
> >> robienie go bardziej niezawodnym i bezpiecznym, to nie jest dziwne, że
> >> jest bardziej niezawodny czy bezpieczny niż system podobnej wielkości,
> >> który zaczął powstawać półtora roku temu. Będzie to raczej prawdą
> >> niezależnie od zastosowanych języków. I tak dalej i tak dalej.
>
> > 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.

>
> > Moje osobiste obserwacje z systemami uzywanymi w duzych bankach (na
> > przykladzie Murex) sa takie, ze one sie rozwijaja organicznie i nowe
> > funkcjonalnosci sa czesto wrecz dopychane kolanem. Nikt nie ma czasu
> > porzadkowac kodu, bo klienci (wewnetrzni badz zewnetrzni) naciskaja na
> > nowe produkty. Grupa rozwijajaca dany kawalek kodu musi miec spory
> > autorytet zeby przeforsowac decyzje "nie dodajemy nowych
> > funkcjonalnosci przez pare miesiecy tylko refaktoryzujemy" bez
> > spotkania sie z wielkim oporem. A programisci w bankach sa dobrze
> > platni, ale na ogol nie maja wielkiego autorytetu.
>
> 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?

>
> Z drugiej strony pozwalanie na zapuszczanie kodu pod pretekstem
> oszczędności czasu to kompletne marnotrawstwo - potem doprowadza się do
> tego, że prosta zmiana czy bugfiz zamiast pół dnia zajmuje tydzień.

O tak tak.

> Niestety znam takie przykłady z autopsji, z czego wynika że nie tylko w
> bankach ten problem się pojawia. Może w bankach jest gorzej, bo jest
> presja na krótkie terminy,

Zalezy jaki projekt. Jak trader chce miec zbudowany arkusz Excela do
wyceny jakiejs pojedynczej egzotycznej opcji, to moze Ci rzucic
terminem "pol godziny" (literalnie kiedys mi powiedzieli "musimy miec
te cene w 15 minut, albo kontrakt przepada" - i cene dostali :)).
Natomiast cos, co ma byc uzywane do regularnego obliczania zyskow/
strat (tzw. P&L) ksiegi musi przejsc etap testowania, musi byc
udokumentowane, zaakceptowane przez middle office, itd. - wiec terminy
sa normalne. Banki stac na zatrudnianie dobrych programistow, wiec
odpada problem, ze kolega obok jest glabem i jego kod wnosi negatywna
wartosc do projektu. Takie rzeczy sie raczej b. rzadko zdarzaja.

> ale z mojego doświadczenia wynika, że to
> często jest wina nie tylko presji, ale samych programistów.
>
> A ten Murex to jak guglnąłem to jest robiony przez jakąś firmę, a nie
> przez programistów pracujących w banku, czy źle patrzę?

Tak, ale jego integracja w duzym banku to wielki projekt sam w sobie,
itez wymaga pisania sporo kodu.

RW