On Dec 10, 9:34 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On 10/12/2011 21:00, Roman W wrote:
>
> > On Dec 10, 7:20 pm, Andrzej Jarzabek<a...@g...com>
> > wrote:
> >> On 10/12/2011 18:33, Roman W wrote:
> >>> Ja lubie dokumentacje. Tylko nie lubie jej pisac.
> >> Ja nieszczególnie lubię sytuację, kiedy:
> >> a) jest dokumentacja, ale opisuje nie do końca to, jaki program
> >> faktycznie jest,
>
> > Ja tam wole miec niekompletna dokumentacje + zrodla niz tylko zrodla.
>
> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.

Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
nie zmieni, i przynajmniej ten udokumentowac.
Poza tym, jezeli np. ktos udokumentowal 4 parametry funckji, a potem
dodal piaty ktory nie jest udokumentowany, to i tak lepiej niz kiedy
zaden parametr nie jest.

>
> Poza tym ja się w ogóle zgodzę, że dokumentacja czasem jest potrzebna
> lub przydatna. Z tym że w takiej sytuacji najlepiej ją stworzyć już po
> napisaniu kodu. Dokumentacja wymagań lub projektu powstająca przed
> napisaniem kodu - może być, ale nie jest to według mnie najbardziej
> skuteczny sposób pracy (oczywiście to mocno zależy od tego, co się
> robi).

Oczywiscie. Np. teraz opracowuje i implementuje model do wyceny
pewnych instrumentow pochodnych. W miare jak wyprowadzam wzory i
opracowuje schematy kalibracji, wszystko sobie spisuje w pliku
texowym.
Mam w ten sposob dokumentacje "co kod powinien liczyc", ktora bedzie
podstawa pisania oficjalnej dokumentacji dla dzialu walidacji, oraz
moge pokazac zleceniodawcy (traderom) nad czym pracuje.

> No i oczywiście rozwiązania agile nie polegają na tym, że nie
> masz dokumentacji i tyle. Masz mniej dokumentacji niż w niektórych
> innych rozwiązaniach, ale zamiast dokumentacji masz coś innego.

Co? Testow jednostkowych nie uznaje za dokumentacje.

RW