On Fri, 7 Jan 2011 22:56:43 +0000 (UTC), " "
<k...@g...pl> wrote:

>Wyobrażam sobie, że tak można rozwijać kod który ma służyć lata. Front office
>w banku inwestycyjnym musi zmieniać modele w skali czasowej dni albo godzin. I
>owszem, mają procedury testowe. Firma w której pracowałem wcześniej nie była
>bankiem ("wynajmowala" swoje modele innym firmom) ale miała typową procedurę
>testową: testy regresji, testy użytkowników (nie-quantów i nie-programistów),
>dzial QA, testy jednostkowe. Ale quantom i tak pozwalali pisać kod, bo tak
>jest wydajniej i wbrew pozorom bezpieczniej.

Zalezy od definicji "bezpieczenstwa". Quanty i inni jajoglowi pisza
neistety kod tak ze jak dane sa zgodne ze specufikacja to wszystko
jest OK. Jak sa neizgodne, to program sie "wykzracza" bez zadnego
ostzrezenia. Zreszta, jak sa zgodne to czasem wie "wykrzacza" bo ktos
czegos tam nie pzrewidzial.

Jakos "quanty" nei moga przyjac do wiadomosci ze 75% produkcyjnego
kodu to wlasnie pilnowanei "kontraktu", obsluhe wyjatkow i tak dalej.
program nie moze sie "wykzraczac".

Ale racja, ze jek cos jest potencjalnie do wyrzucenia, to moze byc na
spinacze i gume do zucia...

Zgadzam sie tez ze programow wykorzystujacych matematyke nie napisze
pzrecietny programista, chociaz bym mu i miesiac tlumaczyl o co
chodzi. Ja pisze moje programy sam, dostarczajac "normalnym"
programistom API z ktorych moga korzystac bez specjalnego myslenia.
Ale neistety, robie to w trybie o ktorym pisalem: nei mozna sie obejsc
bez formalnej specyfikacji i dokumentacji. Ale na szczescie jestem
pzrede wszytkim inzynierem :)

>> W Europie, IC-PARC (neiistniejaca juz komorka Imperial College) w
>> ramach projektu ESPRIT zwanego CHIP opracowala 4 tomowy manual o
>> konstrukcji oprogramowania z komponentami optymalizacujnymi. Neistety,
>> nie jest dostepny on-line, bo zatonal wraz z IC-PARC, ale mam wlasna
>> kopie, wiec moge podeslac.
>
>Bardzo chetnie!
>

No, musze miec jakis adres na ktory moge wyslac :)

A.L.