On 18/07/2013 21:12, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ks5dga$ei6$...@s...invalid...
>
>> Kto tak napisał? I jak to argumentował?
>
> Rozdział 4.,
> http://helion.pl/ksiazki/czysty-kod-podrecznik-dobre
go-programisty-robert-c-martin,czykod.htm

To jest tłumaczenie Clean Code? Z wrażenia aż zdjąłem z półki i
sprawdziłem, i albo nieuważnie przeczytałeś, albo masz bardzo złe
tłumaczenie. WWłaśnie notki copyrightowe i licencje tam, gdzie jest to
wymagane, są podane jako przykład "dobrych" komentarzy. Jako zły rodzaj
komentarza było pisanie kto napisał przy poszczególnych kawałkach kodu,
przykład z książki "Added by Rick". No więc ja się zgadzam, że takie
komentarze są bez sensu.

>> bardziej, i dla konkretnego przypadku twoim zadaniem jest wykombinować,
>
> Ajtam moje zdanie. Moje zdanie to tylko moje zdanie. Problem zaczyna się
> wtedy, gdy wychodzi "brzydka prawda" - np. błąd FDIV w CPU Pentium
> "trochę kosztował" firmę Intel.

Można po pierwsze zwrócić uwagę, że to problem sprzętowy, a nie
software'owy. Metodologie tworzenia oprogramowania nie mają zastosowania
- chociaż zdaje się unit testy są inspirowane rozwiązaniami z
elektroniki. Ja w każdym razie nie znam się na tyle, żeby doradzać
Intelowi, jak testować procesory.

Tak czy inaczej, firma Intel jak ostatnio sprawdzałem to jescze istniała.

> Czy testy + nisko kwalifikowana niedbała kadra mogą przed tym
> zabezpieczyć lepiej niż po prostu staranność, myślenie, zatrudnianie
> fachowców? Testy jednostkowe (czy jakiekolwiek) nie sprawdzają się -
> moim zdaniem - jako proteza IQ i umiejętności. Ale to jest tylko moje
> zdanie.

To, co przedstawiasz, to fałszywa alternatywa. Albo zatrudniasz
fachowców i wtedy masz wybór między zatrudnianiem fachowców i
testowaniem a zatrudnianiem fachowców i nie testowaniem, albo z jakiegoś
powodu wolisz zatrudnić nisko kwalifikowaną niedbała kadrę, i wtedy też
masz wybór między taką kadrą i testami albo taką kadrą i brakiem testów.

>> 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
>
> Problem jaki powstaje - to zwiększenie złożoności. Testy. Testy do
> testów. Moduł testowy testujący moduł weryfikujący. Całość robi się...
> no właśnie, jaka?

Jakie testy do testów? Do testów nie piszesz testów przecież. Co to jest
w tym przypadku "moduł weryfikujący"? Testy jednostkowe (a także
acceptance tests) są testowane w metoldach TDD ręcznie w bardzo prostu
sposób - zaczynasz od pisania testu, jeśli test przechodzi, znaczy że
jest źle napisany. Następnie implementujesz to, co test testuje i
regularnie zapuszczasz testy, jeśli testy przejdą zanim skończysz, to
znaczy że test jest źle napisany. Jeśli skończysz, a test nie
przechodzi, to dedukujesz tradycyjnymi metodami dlaczego i albo
znajdujesz błąd w kodzie, albo w teście.

> Wszystko to zabiera czas i zasoby (ludzkie, nie komputera). A tych
> zasobów jest ograniczona ilość.

Oczywiście, ale konsekwencje braku unit testów (i innych testów
automatycznych) często zabierają więcej czasu i zasobó niż pisanie tych
testów.

>> 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
>
> O to klawo jak cholera - time nieskończony (bo czemu nie?), z
> materiałami gorzej (ale przecież możemy wmówić klientowi, że np.
> potrzebujemy zajefajnego sprzętu, ton papieru, pięciu pięter w biurowcu,
> dodatkowego personelu).
>
> Czy jednak nie możemy? Dlaczego nie możemy?!

Czas w time and materials jest taki, za jaki klient chce zapłacić. Chce
płacić w nieskończoność to może. Część "materials" jest zwykle wpisana w
umowę, czym może być, czym nie może - zazwyczaj to są rzeczy typu
pokryci kosztów podróży i takie tam.

Znowu - możesz sobie zawrzeć taką umowę, na jaką się zgadzasz z drugą
stroną (chyba że nielegalna albo nieważna).