On Sun, 07 Aug 2011 01:21:31 +0200, m...@t...pl wrote:

>> On Sat, 06 Aug 2011 22:13:47 +0200, m...@t...pl wrote:
>
>> W dalszym ciagu nie rozumiem co wielowatkowosc ma do rzeczy
>Przeciez to proste, nie trzeba wykonywac testow zwiazanych z
>synchronizacja watkow,

Jakich testow?...

>program bez watkow jest prostszy, mniejszy,

Mnei sie zawsze wydawalo ze jak sa swtki to jest bardziej
skomplikwoany


>mniej trzeba sie w nim troszczyc o estetyke kodu.

Niby dlaczego?...

> A moze to
>juz chodzi o cos wiecej niz estetyke i styl, moze chodzi o
>jakas "systematycznosc".
>
>> Jezeli klamra otwiera sie w linii 100 a zamyka w linii 1000, to
>> jedynym sensownym rozwiazaniem jest wyrzucenie programisty z pracy.

> Programowanie to nie matematyka, ze jesli
>2 + 2 = 5 to cos na pewno zostalo spieprzone.
>

Acha. Rozumiem. A czy 2 + 2 = 7 tez moze byc?...

>Duza procedura o ktorej mowie jest polimorficzna w
>wielu klasach. Projekt zostal tak skonstruowany ze
>rozszerzenie funkcjonalnosci dodaje sie poprzez
>tego typu klase (wyprowadzona z bazowej).

A co to zanczy?...

> Przed
>wykonywaniem wlasciwych operacji na danych nastepuje
>szereg testow. Testy sa podzielone na kilka logicznych
>etapow, ale pomimo to, jeden z etapow testowania bywa
>orgomy.

[..]

Dlatego powinien byc ustrukturalizowany a nie napisany jako jeden
"ciurek" kodu.

>Przy duzej ilosci if-ow robi sie metlik. Jesli tylko mozna,
>to nalezy uproscic przez continue. contiune i return upraszcza,

Owszem, robi sie metlik. Ale nie uparszcza sie go przez continue,
return i break, tylko przez obiektowosc i zasosowanei odpowiednich
wzrocow programowych. Nei tylko w trosce o czytelnosc, ale i
elastycznosc. Oarz dekompozycje testow do zbioru obiektow
odpowiedzalnych za testowanei okreslonych aspektow.

A.L.