On 17/12/2011 20:02, Roman W wrote:
> On Dec 17, 7:12 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>>
>>> A co jest rezultatem tej rozmowy? Notatki pisane olowkiem na serwetce,
>>> watem mailowy w firmowym Outlooku, czy cos bardziej
>>> ustrukturyzowanego?
>>
>> Przede wszystkim rezultatem tej rozmowy jest to, że programista wie, co
>> jest prawidłowym zachowaniem budowanego systemu.
>
> Systemu jako calosci? Czyli jednak dokumentacja.

Systemu jako całości lub danego kawałka. Wiedza to nie jest to samo, co
dokumentacja.

>> Jeśli chodzi o
>> artefakty, to może to być "user story" (czy inny "change control ticket)
>> - jeśli objaśnienie się kwalifikuje, będzie to prawdopodobnie jeden lub
>> kilka testów (acceptance test, unit tests),
>
> Ale to opisuje wycinek systemu.

Łącznie wszystkie te opisy opisują cały system. Tak samo jak z
dokumentacją wymagań zresztą: składa się zwykle z jakichś rozdziałów,
które opisują wycinki systemu.

>> no i przede wszystkim będzie
>> to działający kod, który robi właśnie to, co trzeba.
>
> Nie, bedzie to kod przechodzacy kilka testow. To nie to samo.

Jednak nie tylko przechodzący kilka testów, bo jego forma się bierze
stąd, że programista _rozumie_ co program ma robić, a nie z tego, że
widział kod testów i dostaje zadanie napisania kodu je przechodzącego.

To, że 100% gwarancji na poprawność kodu nie ma, to osobna sprawa -
dokumentacja też przecież takiej gwarancji nie daje.

>>> Czy uwazasz, ze 100% funkcjonalnosci mozna udokumentowac w formie
>>> testu?
>>
>> Nawet jeśli można udokumentować 99%, to praktycznie różnica jest niewielka.
>
> Czyli uwazasz, ze osiagalne jest "99%" (czyli prawie kompletny opis)?
> Tak/nie.

Ostrożnie powiem, że to zależy od dziedziny, a ja się na wielu
dziedzinach nie znam. Ale na ogół uważam, że tak właśnie jest - między
odpowiednio ekspresywnie napisanymi testami a odpowiednio ekspresywnie
napisanym kodem da się wyrazić to, co zazwyczaj się wyraża w
dokumentacji - równie dobrze jak w dokumentacji.

>>> Zalozmy, ze projekt zawiera biblioteke numeryczna. Czy wystarczy
>>> "acceptance test", czy nie nalezy rowniez udokumentowac algorytmow,
>>> ktore biblioteka ma implementowac?
>>
>> Nie wiem konkretnie jak jest z bibliotekami numerycznymi.
>
> Jest tak, ze nie wystarczy wiedziec, ze biblioteka przechodzi X
> testow, zeby ocenic, czy design jest poprawny czy nie. Testy moga
> sprawdzic skonczona liczbe przypadkow, ale wymagania stawiane
> bibliotekom numerycznym jest ciezko zawrzec calkowicie w formie
> testow.
> Np. wymaganie moze brzmiec "procedura X ma implementowac algorytm
> calkujacy Grubiediewa". Jak to sprawdzisz unit testem?

Po pierwsze - tak w ogóle - testy to nie tylko unit testy.

Po drugie w innych działkach, i przypuszczam, że tutaj tak samo, wybór
algorytmu wynika z pewnym właściwości całkowania tym algorytmem, które
są rzeczywistym wymaganiem. I te właściwości można jak najbardziej testować.

Poza sprawdzeniem obserwowalnych właściwości zachowania programu,
istotne właściwości implementacji zamiast zapisywać w dokumentacji można
często zapisać w kodzie. Trochę żartobliwie mogę powiedzieć, że to, co
napisałeś da się zapisać tak:

double X (args) {
return calkujAlgortymemGrubiediewa(args);
}

>> Jeśli chodzi o
>> to, że wykorzystujesz jakieś algorytmy z literatury i chcesz
>> udokumentować fakt, że stosujesz algorytm Kamionnego-Łomonosowa z
>> artykułu "Zastosowanie metod numerycznych przy wykopywaniu ziemniaków"
>> publikowanego w miesięczniku Kołchoźnik nr 8/51? No to może faktycznie
>> należy dać przypis w komentarzu.
>
> A jesli algorytm nie zostal nigdzie opublikowany?

To co napiszesz w dokumencie? Że funkcja całkuje algorytmem, który nie
został nigdzie opublikowany? Takie coś to można napisać w komentarzu.

Jeśli chodzi o opis działania samego algorytmu, to programiści dysponują
znakomitym narzędziem właśnie do tego, jakim są wysokopoziomowe języki
programowania.

Oczywiście jeśli masz taką sytuację, że wymyślasz własny algorytm i
musisz np. formalnie udowodnić jego poprawność, to może i najlepiej to
zrobić w postaci dokumentu. Ale jak często zdarzają się tak naprawdę
takie sytuacje?

>>> A jezeli zmieni dzialanie programu w aspekcie nie objetym testami?
>>
>> To dobrze, że przynajmniej zdaje sobie sprawę, że zmieni.
>
> Skad ma zdawac sobie sprawe? Przeciez nie ma dokumentacji, moze uznac,
> ze zmiana w kodzie nie zmieni istotnych aspektow dzialania programu,
> bo... unit testy przechodza.

Po pierwsze może się po prostu wziąć z analizy "jakie będą konsekwencje
jeśli zmienię program w ten sposób". Jeśli programiście mylnie się
wydaje, że zachowanie programu się nie zmieni, to dokumentacja w niczym
tu nie pomoże. Jeśli programista jest w stanie stwierdzić, że zachowanie
programu się zmieni, to powinien być też w stanie stwierdzić, że nie ma
testów testujących aspekt który się zmieni, więc jest w stanie uruchomić
całą procedurę "dlaczego nie ma na to testów".

Po drugie tak w ogóle ten scenariusz nie różni się za bardzo od
sytuacji, kiedy zmiany wprowadzone przez programistę powodują zmianę
działania programu w aspekcie nie objętym dokumentacją.

>> sytuacji, skoro aspekt nie jest objęty testami, to prawdopowodnie należy
>> go objąć testami. No chyba że OSCR powie, że ten aspekt jest nieistotny,
>> to wtedy nie ma problemu.
>
> Ale skad programista ma *wiedziec*, ze zmiana ktora chce wprowadzic w
> kodzie jest istotna i powinna byc skonsultowana z OSCR, skoro nie ma
> dokumentacji? Ma trzymac OSCR non-stop przy sobie? A jesli nad
> projektem pracuje wiecej niz 1 programista, to ile osob ze strony
> klienta ma je nadzorowac?

Zakłada się, że programista ma jakąś inteligencję i powinien na
podstawie rozmów z OSCR nabyć wiedzy i rozumienia na temat tego, jak
program ma działać i dlaczego właśnie tak.

Poza tym dąży się do tego, żeby zmiany funkcjonalne praktycznie zawsze
były objęte istniejącymi testami. Jeśli coś nie jest objęte testem, a
może być istotne, to się testy dodaje i potem one już są.