On 16/07/2013 18:51, slawek wrote:
>
> Ostatnio czytałem książkę pewnego dość znanego "agilistyka". Upierał się
> on, że pisanie w kodzie źródłowym np. kto jest autorem i jakie są
> ograniczenia licencyjne jest "fuj". Nie polimeryzuję z tym poglądem, po
> prostu w drodze dedukcji z tej przesłanki wynikałoby że 99% kodu
> źródłowego jest "fuj". Nawet a zwłaszcza ten "sweterkowy", z GPL.

Kto tak napisał? I jak to argumentował?

W korpora

> Zaciekawiły mnie też testy: jak przetestować, że np. f(x,y) zwraca
> poprawne wyniki? Dla przykładu takie dzielenie: 1/1, 2/1, 1/2, 0/1, 1/0,
> 0/0 wystarczy sprawdzić? Biorąc pod uwagę tylko 1E38 liczb (circa zakres
> singli), mamy 1E76 wartości do sprawdzenia, co przy prędkości 1000
> teraflopsów zajmie... trochę dłużej niż będzie istniał Wszechświat.
> (Intel/CPU/Pentium/FDIV-bug)

Mylisz testowanie z formalną weryfikacją. Ideą testowania (tak w ogóle,
nie tylko w agile) jest to, że sprawdzenie działania programu na próbie
danych testowych zmniejsza prawdopodobieństwo błędnego działania.
Dopisując kolejne przypadki prawdopodobieństwo zmniejszasz coraz
bardziej, i dla konkretnego przypadku twoim zadaniem jest wykombinować,
jaki zestaw przypadków wybrać żeby uzyskać pożądaną równowagę między
prawdopodobieństwem wyłapania błędu a kosztem napisania i uruchamiania
testów.

Skoro piszesz o testowaniu funkcji, to być może masz na myśli unit
testing. Otóż unit testy to rodzaj tzw. white box testing, są pisane na
podstawie wiedzy jak wewnętrznie działa to, co jest testowane. W tym
przypadku jako programista piszący testy wiesz, jakiego algorytmu
będziesz używał do implementacji dzielenia i na tej podstawie możesz
wymyśleć przypadki, dla których istnieje największe ryzyko, że mogą nie
działać. Jeśli nie potrafisz wymyśleć takich przypadków, a ryzyko jest
nadal nieakceptowalne, to musisz się zastanowić nad innymi formami
weryfikacji, może inne rodzaje testów, może formalny dowód poprawności.
I w tym tak samo powinieneś policzyć koszty, bo jeśli wymagasz tak
wysokiego stopnia pewności, o jakim piszesz, to weryfikacja może być
bardzo kosztowna i może tego programu w ogóle się nie opłaca pisać.

> Jest też ciekawe kto, przy zmianie specyfikacji zamówienia generowanej
> przez kupującego program, płaci za ekstra wysiłek? Z podręczników
> Agilizmu wynika, że to jest free (tj. płaci swoim czasem/zasobami firma
> softwareowa), ze zdrowego rozsądku wynikałoby że ???

Których podręczników? W tych podręcznikach, które znam, zaleca się
stosowanie kontraktu typu time&materials, wtedy nie ma tego problemu -
klient chce zmiany specyfikacji, robi się szacunek kosztu tej zmiany i
klient decyduje, czy woli płacić za to, czy za co innego, czy też
przestać płacić i odebrać produkt taki, jaki jest. Z czytanych przeze
mnie podręczników to akurat na ten temat więcej jest w "The Scrum Field
Guide" Mitcha Lacy'ego. Wiele opisów czy książek o agile w ogóle się tym
nie zajmuje, bo decydowanie kto płaci i jak się formułuje kontrakty to
nie jest stricte problem inżynierii oprogramowania.