🚀 go-pugleaf

>Nie ze wszystkim sie zgadzam, ale wg mnie warte przeczytania. Zwlaszcza 

<cut/>
IMHO szkoda czasu. Artykul (nie tylko w mojej opinii) jest stekiem bzdur
wyssanych z palca. Krytyka bez jakiejkolwiek znajomosci tematu...

m.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

Dnia Thu, 08 Jun 2006 04:17:34 +0200, Aleksander Galicki skrobie:
> To pewnie znak czasow, ale sledze z kilka(nascie) blogow ludzi, ktorzy wg mnie 
> maja cos ciekawego do powiedzenia.

> http://beust.com/weblog/archives/000392.html

> Nie ze wszystkim sie zgadzam, ale wg mnie warte przeczytania. Zwlaszcza 
> smakowite kawalki z prezentacji Jeff'a Langr'a.

No nie wiem. Na razie przeczytałem ten pierwszy, i jeśli ten gościu
rzeczywiscie ma coś ciekawego do powiedzenia, to najwyraźniej tego nie
zdradził.

Ja również jestem zdania, że co jest nietestowalne jest bezużyteczne. Co
więcej, argumentacja tego gościa (duże projekty, setki tysięcy linii kodu,
ścisłe terminy oddania, wielu developerów) nie przemawia do mnie zupełnie, bo
tak się akurat składa, że mam do czynienia w pracy z takimi właśnie
projektami, nasz proces nawet nie jest typowo Agile'owy, ale w to, że kod
powinien być wytestowany na każdą ewentualność nikt nigdy nie próbował wątpić.

Co więcej, w krótkim projekcie, który prowadziłem, też (za namową :)
zaczynaliśmy od napisania testu, a dokładnie test był pisany jak tylko została
ustalona konstrukcja interfejsu. Co ciekawe, bardzo takie podejście pomagało w
napisaniu implementacji.

Jedną z wyśmiewanych opinii przez tego gościa, którego bloga przeczytałem,
jest co ma zrobić, jeśli ma nieseparowalny kod. Odpowiedź dostał, że stosując
metody Agile nie będzie takowego miał. I to jest niestety prawda. Ja miałem
kiedyś właśnie do przetestowania "hostowego" kod teoretycznie nieseparowalny.
To co zrobiłem? No cóż, odseparowałem go. :)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
wrote:

> Co więcej, w krótkim projekcie, który prowadziłem, też (za namową :)
> zaczynaliśmy od napisania testu, a dokładnie test był pisany jak tylko 
> została
> ustalona konstrukcja interfejsu.

Kurde Sektor chyba po dziesieciu latach klotni z Toba
na newsach zwatpilem _nieslusznie_ ze  mozemy miec w
czymkolwiek w 100% zbiezne opinie :)
Szczerze (bez cienia sarkazmu, ironii czy prowokacji) popieram w/w !
Uznanie dla Ciebie.

> Co ciekawe, bardzo takie podejście pomagało w
> napisaniu implementacji.

128% zgody :)

To ze w/w podejscia nigdy sie nie stosuje w praktyce
(nigdy == 98.45% polskeigo "widma") nie znaczy ze nie jest ono ze
wszech miar sluszne.

PS: Gdybym byl szefem projektu to nawet bylbym w stanie posunac
        sie do tego zeby wy.. programiste z pracy za uporczywe ignorowanie
        zakazu implementacji _przed_ napisaniem testow.
        OK, wiem ze skrajnosc ale..

AK

On Sun, 11 Jun 2006 10:37:08 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

>Dnia Thu, 08 Jun 2006 04:17:34 +0200, Aleksander Galicki skrobie:
>> To pewnie znak czasow, ale sledze z kilka(nascie) blogow ludzi, ktorzy wg mnie 
>> maja cos ciekawego do powiedzenia.
>
>> http://beust.com/weblog/archives/000392.html
>
>> Nie ze wszystkim sie zgadzam, ale wg mnie warte przeczytania. Zwlaszcza 
>> smakowite kawalki z prezentacji Jeff'a Langr'a.
>
>No nie wiem. Na razie przeczytałem ten pierwszy, i jeśli ten gościu
>rzeczywiscie ma coś ciekawego do powiedzenia, to najwyraźniej tego nie
>zdradził.
>
>Ja również jestem zdania, że co jest nietestowalne jest bezużyteczne. Co
>więcej, argumentacja tego gościa (duże projekty, setki tysięcy linii kodu,
>ścisłe terminy oddania, wielu developerów) nie przemawia do mnie zupełnie, bo
>tak się akurat składa, że mam do czynienia w pracy z takimi właśnie
>projektami, nasz proces nawet nie jest typowo Agile'owy, ale w to, że kod
>powinien być wytestowany na każdą ewentualność nikt nigdy nie próbował wątpić.

Panie Sektor, kodu sie na da "wytestowac na kazda ewentualnosc". W
jakiejs dziwnej firmie Pan pracuje, albo rewelacje wysysa z palca.

A.L.

Dnia Sun, 11 Jun 2006 15:20:49 +0200, Adam Karpierz skrobie:
> PS: Gdybym byl szefem projektu to nawet bylbym w stanie posunac
>         sie do tego zeby wy.. programiste z pracy za uporczywe ignorowanie
>         zakazu implementacji _przed_ napisaniem testow.
>         OK, wiem ze skrajnosc ale..

Ja tam skrajności nie lubię. Często mi się zdarzało coś takiego, że
konstrukcja interfejsu była mocno zmieniana pod wpływem próbnych
implementacji. Po prostu czasami nie byłem w pełni świadom np. tego, jakie
argumenty ma przyjmować funkcja, bo nie wiedziałem do końca, co jej w
rzeczywistości będzie potrzebne do poprawnego działania. A "z dupy" strzelić
interfejs, napisać potem do niego test, a potem poprawiać po kilka razy test,
bo po napisaniu implementacji trzeba było poprawić interfejs - to też nadmiar
niepotrzebnej roboty. Przynajmniej przydałoby się wstępnie naszkicować
implementację i określić, co jej jest potrzebne. Mając to dopiero wtedy wiemy,
jaki na pewno jest interfejs, a do niego możemy napisać test.

My to robiliśmy dokładnie tak, że najpierw mając określone wymagania (czyli:
co to nasze coś ma robić) opracowywaliśmy plany testów ("jak sprawdzić, że
robi rzeczywiście"), potem próbny szkic implementacji (mając testy nawet
łatwiej się wtedy pisze, bo się pisze "pod klienta" :), wtedy robi się test
dostosowany do implementacji i doprowadza się implementację do działania (test
i implementację nawet często pisały inne osoby). Tak nawet jeszcze dokładniej,
to często test potrzebował mieć jakieś dodatkowe "ostubowanie" i to właśnie
"ostubowanie" pisało się jeszcze przed implementacją.



-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Sun, 11 Jun 2006 08:46:11 -0500, A.L. skrobie:
> On Sun, 11 Jun 2006 10:37:08 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

> >Dnia Thu, 08 Jun 2006 04:17:34 +0200, Aleksander Galicki skrobie:
> >> To pewnie znak czasow, ale sledze z kilka(nascie) blogow ludzi, ktorzy wg mnie 
> >> maja cos ciekawego do powiedzenia.
> >
> >> http://beust.com/weblog/archives/000392.html
> >
> >> Nie ze wszystkim sie zgadzam, ale wg mnie warte przeczytania. Zwlaszcza 
> >> smakowite kawalki z prezentacji Jeff'a Langr'a.
> >
> >No nie wiem. Na razie przeczytałem ten pierwszy, i jeśli ten gościu
> >rzeczywiscie ma coś ciekawego do powiedzenia, to najwyraźniej tego nie
> >zdradził.
> >
> >Ja również jestem zdania, że co jest nietestowalne jest bezużyteczne. Co
> >więcej, argumentacja tego gościa (duże projekty, setki tysięcy linii kodu,
> >ścisłe terminy oddania, wielu developerów) nie przemawia do mnie zupełnie, bo
> >tak się akurat składa, że mam do czynienia w pracy z takimi właśnie
> >projektami, nasz proces nawet nie jest typowo Agile'owy, ale w to, że kod
> >powinien być wytestowany na każdą ewentualność nikt nigdy nie próbował wątpić.

> Panie Sektor, kodu sie na da "wytestowac na kazda ewentualnosc". W
> jakiejs dziwnej firmie Pan pracuje, albo rewelacje wysysa z palca.

Ja je wysysam niestety z własnego doświadczenia. Nie wiem, może pracuję w
"dziwnej" firmie, skoro "wytestowanie na każdą ewentualność" jest niemożliwe.

Oczywiście nie twierdzę, że każda aplikacja jest testowana na absolutnie każdą
ewentualność. Recovery do błędów (głównie systemowych) testuje się tylko w
najważniejszych punktach, albo w przypadku bardzo krytycznej aplikacji (tzn.
dokładnie to w przypadku, gdy aplikacja "musi sobie poradzić nawet gdyby
system zaczął wariować" - to oczywiście skrajna rzadkość).

Natomiast jest oczywiście tak, że aplikacja, zakładając że część systemowa nie
robi błędów, ma przechodzić dokładnie i wyłącznie te ścieżki przejścia do
jakich jest przewidziana i każda taka ścieżka jest sprawdzana (warianty
dobiera się względem pokrywania się stopni swobody i ich zależności). O
szczegółach zresztą już dyskutowaliśmy.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

>Dnia Thu, 08 Jun 2006 04:17:34 +0200, Aleksander Galicki skrobie:
>> To pewnie znak czasow, ale sledze z kilka(nascie) blogow ludzi, ktorzy wg
>mnie 
>> maja cos ciekawego do powiedzenia.
>
>> http://beust.com/weblog/archives/000392.html
>
>> Nie ze wszystkim sie zgadzam, ale wg mnie warte przeczytania. Zwlaszcza 
>> smakowite kawalki z prezentacji Jeff'a Langr'a.
>
>No nie wiem. Na razie przeczytałem ten pierwszy, i jeśli ten gościu
>rzeczywiscie ma coś ciekawego do powiedzenia, to najwyraźniej tego nie
>zdradził.

Panie Sektorze, ale sie pan odniosl do tylko jednego zdania. Tylko tyle pan 
potrafil w tej notce przeczytac? Mnie np zainteresowal inny nieco temat. Temat 
fanatyzmu niektorych proponentow TDD. Podejscie pt "take it or die" - albo 
stosujesz sie do wszystkich wytycznych, albo twoj projet jest do dupy. Jesli 
nie mozesz stosowac naszych rad, to twoje projekt jest do dupy. Albo 
przedstawiania TDD jako jakiegos generalnego lekarstwa na wszystko - z 
oslawionym juz stwierdzeniem ze testy = specyfikacja. 

>Ja również jestem zdania, że co jest nietestowalne jest bezużyteczne. Co
>więcej, argumentacja tego gościa (duże projekty, setki tysięcy linii kodu,
>ścisłe terminy oddania, wielu developerów) nie przemawia do mnie zupełnie, bo
>tak się akurat składa, że mam do czynienia w pracy z takimi właśnie
>projektami, nasz proces nawet nie jest typowo Agile'owy, ale w to, że kod
>powinien być wytestowany na każdą ewentualność nikt nigdy nie próbował
>wątpić.

Wie Pan, z takimi projektami jak Cedric Beust pan na pewno nie mial do 
czynienia - bez urazy. Zanim Cedric'a nie zgarnal Google, Cedric byl lead 
developerem kontenera EJB w BEA. To niestety zupelnie inna klasa projektow niz 
cokolwiek produkowanego w PL. 

A tak zupelnie z innej beczki: mam takie brzydkie podejrzenie, ze te duze 
projekty o ktorych pan pisze to takie bardziej robienie bugfixow i 
enchancementow (dorzezbic tu kawalek, tanto troszeczke zmienic) niz tworzenie 
duzego systemu od poczatku.


A.

-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

On Mon, 12 Jun 2006 01:01:02 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
 
>
>Oczywiście nie twierdzę, że każda aplikacja jest testowana na absolutnie każdą
>ewentualność. Recovery do błędów (głównie systemowych) testuje się tylko w
>najważniejszych punktach, albo w przypadku bardzo krytycznej aplikacji (tzn.
>dokładnie to w przypadku, gdy aplikacja "musi sobie poradzić nawet gdyby
>system zaczął wariować" - to oczywiście skrajna rzadkość).
>
>Natomiast jest oczywiście tak, że aplikacja, zakładając że część systemowa nie
>robi błędów, ma przechodzić dokładnie i wyłącznie te ścieżki przejścia do
>jakich jest przewidziana i każda taka ścieżka jest sprawdzana (warianty
>dobiera się względem pokrywania się stopni swobody i ich zależności). 

Stowmi swobocy CZEGO?...

Panie Sektor, nawet jezeli Panska aplikacja to baza danych szlauchow
i kaloszy dla Miejskiego Przedsiebiorstwa Kanalizacyjnego, to i tak
nie da sie sprawdzic KAZDEJ sciezki. Za duzo tych sciezek, wie
Pan... No i niech bedzie z 10 userow, i kazdy ma inny scenariusz
poslugiwania sie aplikacja, i robie to rownolegle, to jak Pan bedzie
testowal KAZDA sciezke?...

A.L.

On Mon, 12 Jun 2006 03:52:35 +0200, "Aleksander Galicki" <no@no.com>
wrote:
 
>A tak zupelnie z innej beczki: mam takie brzydkie podejrzenie, ze te duze 
>projekty o ktorych pan pisze to takie bardziej robienie bugfixow i 
>enchancementow (dorzezbic tu kawalek, tanto troszeczke zmienic) niz tworzenie 
>duzego systemu od poczatku.
>

Ja tez, zwlaszcza w kontekscie sugestii Pana S. testowania
"wszystkich mozliwych sciezek wykonania"

A.L.

>On Mon, 12 Jun 2006 03:52:35 +0200, "Aleksander Galicki" <no@no.com>
>wrote:
>
>>A tak zupelnie z innej beczki: mam takie brzydkie podejrzenie, ze te duze 
>>projekty o ktorych pan pisze to takie bardziej robienie bugfixow i 
>>enchancementow (dorzezbic tu kawalek, tanto troszeczke zmienic) niz
>tworzenie 
>>duzego systemu od poczatku.
>>
>
>Ja tez, zwlaszcza w kontekscie sugestii Pana S. testowania
>"wszystkich mozliwych sciezek wykonania"

BTW: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-
nearly.html

prawie spadlem z krzesla jak to zobaczylem....


A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

>>On Mon, 12 Jun 2006 03:52:35 +0200, "Aleksander Galicki" <no@no.com>
>>wrote:
>>
>>>A tak zupelnie z innej beczki: mam takie brzydkie podejrzenie, ze te duze 
>>>projekty o ktorych pan pisze to takie bardziej robienie bugfixow i 
>>>enchancementow (dorzezbic tu kawalek, tanto troszeczke zmienic) niz
>>tworzenie 
>>>duzego systemu od poczatku.
>>>
>>
>>Ja tez, zwlaszcza w kontekscie sugestii Pana S. testowania
>>"wszystkich mozliwych sciezek wykonania"
>
>BTW:
>http://googleresearch.blogspot.com /2006/06/extra-extra-read-all-about -it-
>nearly.html

dla wygody: http://tinyurl.com/qddag


A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

"Aleksander Galicki" <no@no.com> wrote:

> prawie spadlem z krzesla jak to zobaczylem....

Co w tym takiego dziwnego ?
Spie.. implementacja i tyle

AK

"Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
wrote:

> Ja tam skrajności nie lubię.

Heh

> Często mi się zdarzało coś takiego, że
> konstrukcja interfejsu była mocno zmieniana pod wpływem
> próbnych implementacji.

Kurde Sektor.
Mowimy o _ustalonym_ interfejsie.

AK

Adam Karpierz <karpierz@NOOOOSPAAAAMpython.pl> napisał(a): 

> "Aleksander Galicki" <no@no.com> wrote:
> 
> > prawie spadlem z krzesla jak to zobaczylem....
> 
> Co w tym takiego dziwnego ?
> Spie.. implementacja i tyle

Pan uwaznie to czytal...?

Blad zawierala nie tylko ta jedna implementacja. Blad zawierala bardzo znana
ksiazka napisana jeszcze w 1986 roku. Wiem, ze nie tak dawno zostala wydana
rowniez w Polsce (WNT czyba). Na wikipedii teraz jest poprawiona wersja, ale
przed wpisem J. Bloch'a w blogu rowniez wikipedia zawierala ten sam blad.
Pewnie mnostwo publikacji wciaz zawiera ten sam blad. A przeciez poprawnosc
algorytmu miala byc udowodniona, a pewnie mnostwo implementacji zostaly
przetestowane przez roznych implementatorow X razy. A blad wylazl dopiero
teraz, gdy ktos w Javie zechcial sobie posortowac gigantyczna tablice int'ow.
Nie jest wiec to problem jednej skopanej implementacji.



A. 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> Pan uwaznie to czytal...?

W miare uwaznie.
Co w tym takiego dziwnego ?
Malo to nawet samych algorytmow bywalo delikatnie mowiac
"nie dzialajacych zgodnei z zalozeniami" ?

> Pewnie mnostwo publikacji wciaz zawiera ten sam blad.

Normalka.
Copy & Paste based development

> Nie jest wiec to problem jednej skopanej implementacji.

Powiem tak.
W numeryce az sie zawsze roilo od przypadkow
(a + b + c) * z /  y

To do programisty nalezalo temu podobne wyraznienia
tak napisac, aby nie wystapil overflow ani NAN ani INF itp.

Daletego uwazam dalej ze jest to spie.. implementacja
a nei algorytm.
(niewazne kto ja napisal: autor algorytmu czy podrzedny programista
jak np ja).

Teoterycznie/matematycznie (nie wnikajac w nature intow longow
czy innych, zapis (a + b)  integer_divide 2 jest przeciez poprawny

A to co oni kombinuja z ta naprawa w Javovej implementacji
wola o pomste do nieba.

<cytat>
The bug is in this line:

 6:             int mid =(low + high) / 2;So what's the best way to fix the 
bug? Here's one way: 6:             int mid = low + ((high - low) / 2);
Probably faster, and arguably as clear is:

 6:             int mid = (low + high) >>> 1;
In C and C++ (where you don't have the >>> operator), you can do this:

 6:             mid = ((unsigned) (low + high)) >> 1;<cytat>

Czy nie mozna po prostu ?:
 6:             int mid =((long)low + (long)high) / 2;Z w/w ich poprawek 
podoba mi sie jedynie ta:

6:             int mid = low + ((high - low) / 2);


(w C++ juz tak latwo nie ma)

PS: a ta ksiazke Bentley "Programming Pearls" mam od bardzo dawna

AK

>> Pan uwaznie to czytal...?
>
>W miare uwaznie.
>Co w tym takiego dziwnego ?
>Malo to nawet samych algorytmow bywalo delikatnie mowiac
>"nie dzialajacych zgodnei z zalozeniami" ?
>

Mnostwo pewnie. Ale ten przyklad jest jednak dosc spektakularny. W znanej
niemal wsztstkim ksiazce znany spec rozwazal szczegolowo dosc prosty algorytm.
Udowodnil poprawnosc tego algorytmu. Nastepnie napisal implementacje w C. Na
jakies _20 liniek_. I ta implementacja byla z prostym bledem, ktorego NIKT nie
znalalz przez 20 lat. 

Ten kod z ksiazki :

int binarysearch(DataType t)
{
 int l, u, m;
 l = 0;
 u = n-1;
 while (l <= u) {
  m = (l + u) / 2;
  if (x[m] < t)
  l = m+1;
  else if (x[m] == t)
   return m;
  else /* x[m] > t */
   u = m-1;
 }
 return -1;
}

Nastepnie dobry programista (J Bloch) zaimplementowal ten algorytm na
platformie, ktora przez pare(nascie) lat byla powszechnie uzywana w przemysle.
I przez 9 lat tego bledu nikt nie znalazl.

Jaki wniosek? Ja zgadzam sie z Blochem:
"We programmers need all the help we can get, and we should never assume
otherwise. Careful design is great. Testing is great. Formal methods are great.
Code reviews are great. Static analysis is great. But none of these things
alone are sufficient to eliminate bugs: They will always be with us. A bug can
exist for half a century despite our best efforts to exterminate it. We must
program carefully, defensively, and remain ever vigilant." 


A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

"Aleksander Galicki" <no@no.com> wrote:

> Mnostwo pewnie. Ale ten przyklad jest jednak dosc spektakularny.

Tu sie zgadzam w pelni z Panem.
Wiele uczacy.

> I ta implementacja byla z prostym bledem, ktorego NIKT nie
> znalalz przez 20 lat.

Hm...
_Nigdy_ nie zdazylo mie sie uzyc algorytmu "z ksiazki"
bez sprawdzenia.
_Nawet_ w  takich algorytmow jak w ksiazkach
prof Sysly czy np Findeisena. Szymanowskeigo, Wierzbickiego
gdzei podawane programy algorytmy byly po prostu
drukami dzialajacych w praktyce programow.
Zawsze trzeba miec doze niepewnosci.
Zreszta o tych ksiazkach i algorytmach moze szerzej
powiedziec AL
On byl ich wspolautorem.

Troche odbiegne od tematu:
Powiem szczerze ze nigdy pozniej nie spotkalem (no z jednym
wyjatkiem) ksiazki ktora by w taki profesjonalny sposob podchodzila
do sprawy jak w/w.
Zrzeszta mam duzo sentymentow do tych ksiazek bo tam nawet
nie taka znow trywialna teoria (z wyjatkiem moze czesci p.Wierzbickiego
- tej nie moglem przetrawic :) byla podana w bardzo przystepny
sposob (nawet dla niematematykow)

Wracajac do tematu:
Ba. Zwykle bledy w druku sie zdarzaja (np w podstawowej ksiazce
Strostroupa ANSI C++ w gramatyce jezyka C++ jest byk w polskim
wydaniu jak cho.. - w angielskim byc moze tez)

Dlatego bardzo sie dziwie ze ten blad istnial publicznie tyle lat
i byl bezkrytycznie powielany.

> Nastepnie dobry programista (J Bloch) zaimplementowal ten algorytm na

dobry programista nie implikuje bezbledny programista

> Jaki wniosek? Ja zgadzam sie z Blochem:
> "We programmers need all the help we can get, and we should never assume
> otherwise. Careful design is great. Testing is great. Formal methods are 
> great.
> Code reviews are great. Static analysis is great. But none of these things
> alone are sufficient to eliminate bugs: They will always be with us. A bug 
> can
> exist for half a century despite our best efforts to exterminate it. "

Trudno sie z tym nie zgodzic, ale to troche ma sie tak
do tego w sumie trywialnego bledu jakby tlumaczenie tego ze
kwiatek krzywo rosnie wplywem Jowisza.
No jest ten wplyw ale..
Przynajmniejw w w/w wypadku bardziej niz technikalia
zagrala psychologia => slepa wiara w autorytety (ze one nie moga sie
zwyczajnie po ludzku "walnac") a potem poszlo C&P.

"We must program carefully, defensively, and remain ever vigilant."

A Tu sie z w/w i z Panem zgadzam w pelni.
Zreszta tak wlasnie staram sie dzialac w programistycznej praktyce
Niestety nie da sie ukryc ze wsrod "mlodziezy" jest to coraz rzadziej 
spotykana
metoda. Ide, debuggery i inne takie jej nie sprzyjaja.
Moze to ze na Odrze czekalo sie na kompilacje np tydzien
(i dlatego program byl maksymalnei wycyzelowany) nie bylo takie zle :) ?

AK

Dnia Mon, 12 Jun 2006 09:57:06 +0200, Adam Karpierz skrobie:
> > Często mi się zdarzało co? takiego, że
> > konstrukcja interfejsu była mocno zmieniana pod wpływem
> > próbnych implementacji.

> Kurde Sektor.
> Mowimy o _ustalonym_ interfejsie.

Zgadza się, tylko problem w tym, żeby ten ustalony interfejs mieć.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Sun, 11 Jun 2006 21:53:54 -0500, A.L. skrobie:
> On Mon, 12 Jun 2006 01:01:02 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
>  
> >
> >Oczywiście nie twierdzę, że każda aplikacja jest testowana na absolutnie każdą
> >ewentualność. Recovery do błędów (głównie systemowych) testuje się tylko w
> >najważniejszych punktach, albo w przypadku bardzo krytycznej aplikacji (tzn.
> >dokładnie to w przypadku, gdy aplikacja "musi sobie poradzić nawet gdyby
> >system zaczął wariować" - to oczywiście skrajna rzadkość).
> >
> >Natomiast jest oczywiście tak, że aplikacja, zakładając że część systemowa nie
> >robi błędów, ma przechodzić dokładnie i wyłącznie te ścieżki przejścia do
> >jakich jest przewidziana i każda taka ścieżka jest sprawdzana (warianty
> >dobiera się względem pokrywania się stopni swobody i ich zależności). 

> Stowmi swobocy CZEGO?...

Stanów aplikacji.

> Panie Sektor, nawet jezeli Panska aplikacja to baza danych szlauchow
> i kaloszy dla Miejskiego Przedsiebiorstwa Kanalizacyjnego, to i tak
> nie da sie sprawdzic KAZDEJ sciezki.

Da się, tylko trzeba umieć. :)

> Za duzo tych sciezek, wie
> Pan... No i niech bedzie z 10 userow, i kazdy ma inny scenariusz
> poslugiwania sie aplikacja, i robie to rownolegle, to jak Pan bedzie
> testowal KAZDA sciezke?...

Tak, z tym tylko że nie każdą ścieżkę od "początku użytkowania" do "końca
użytkowania", tylko pomiędzy dwoma wyszczególnionymi punktami.

To, co jest tutaj istotne przed przeskoczeniem w danym punkcie z jednej
ścieżki do drugiej, to sprawdzenie stanów niestabilnych. W przypadku gdy w
danym punkcie mamy stan niestabilny, to trzeba zadbać o zablokowanie
możliwości wejścia w takie ścieżki, którym niestabilność tego stanu szkodzi.
Jeśli dany stan jest stabilny, to niezależnie od jego stopni swobody, z
założenia pójście programu dalej dowolną ścieżką daje deterministyczne
zachowanie.

W zasadzie zamiast "stan" powinienem użyć określenia "zmienna stanu"; to
konkretnie miałem na myśli.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Mon, 12 Jun 2006 05:43:52 +0200, "Aleksander Galicki" <no@no.com>
wrote:

>>On Mon, 12 Jun 2006 03:52:35 +0200, "Aleksander Galicki" <no@no.com>
>>wrote:
>>
>>>A tak zupelnie z innej beczki: mam takie brzydkie podejrzenie, ze te duze 
>>>projekty o ktorych pan pisze to takie bardziej robienie bugfixow i 
>>>enchancementow (dorzezbic tu kawalek, tanto troszeczke zmienic) niz
>>tworzenie 
>>>duzego systemu od poczatku.
>>>
>>
>>Ja tez, zwlaszcza w kontekscie sugestii Pana S. testowania
>>"wszystkich mozliwych sciezek wykonania"
>
>BTW: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-
>nearly.html
>
>prawie spadlem z krzesla jak to zobaczylem....
>

To jest wlasnie roznica miedzy "informatyka akademicka" a
"informatyka przemyslowa". 

A.L.

On Mon, 12 Jun 2006 11:21:08 +0200, "Aleksander Galicki" <no@no.com>
wrote:

>>> Pan uwaznie to czytal...?
>>
>>W miare uwaznie.
>>Co w tym takiego dziwnego ?
>>Malo to nawet samych algorytmow bywalo delikatnie mowiac
>>"nie dzialajacych zgodnei z zalozeniami" ?
>>
>
>Mnostwo pewnie. Ale ten przyklad jest jednak dosc spektakularny. W znanej
>niemal wsztstkim ksiazce znany spec rozwazal szczegolowo dosc prosty algorytm.
>Udowodnil poprawnosc tego algorytmu. Nastepnie napisal implementacje w C. Na
>jakies _20 liniek_.

Ta implementacja to nei byla implementacja tego programu dla ktorego
przeprowadzono dowod. Nie jest to zadne odkrycie jako takie.
Zaskakujace jest to ze to kogos zaskakuje.

Metoda "cut from textbook and paste" prowadzi wlasnei do takich
niespodzianek. 

A.L.

Dnia Mon, 12 Jun 2006 03:52:35 +0200, Aleksander Galicki skrobie:
> >Dnia Thu, 08 Jun 2006 04:17:34 +0200, Aleksander Galicki skrobie:
> >> To pewnie znak czasow, ale sledze z kilka(nascie) blogow ludzi, ktorzy wg
> >mnie 
> >> maja cos ciekawego do powiedzenia.
> >
> >> http://beust.com/weblog/archives/000392.html
> >
> >> Nie ze wszystkim sie zgadzam, ale wg mnie warte przeczytania. Zwlaszcza 
> >> smakowite kawalki z prezentacji Jeff'a Langr'a.
> >
> >No nie wiem. Na razie przeczytałem ten pierwszy, i jeśli ten gościu
> >rzeczywiscie ma coś ciekawego do powiedzenia, to najwyraźniej tego nie
> >zdradził.

> Panie Sektorze, ale sie pan odniosl do tylko jednego zdania.  Tylko tyle pan
> potrafil w tej notce przeczytac?

Tylko tyle mi się chciało przeczytać. Ale doczytam resztę; zapowiada się
ciekawie ;)

> Mnie np zainteresowal inny nieco temat. Temat 
> fanatyzmu niektorych proponentow TDD. Podejscie pt "take it or die" - albo 
> stosujesz sie do wszystkich wytycznych, albo twoj projet jest do dupy. Jesli 
> nie mozesz stosowac naszych rad, to twoje projekt jest do dupy. Albo 
> przedstawiania TDD jako jakiegos generalnego lekarstwa na wszystko - z 
> oslawionym juz stwierdzeniem ze testy = specyfikacja. 

Takiego podejścia zawsze byłem przeciwnikiem - ale jak zauważyłem jest to dość
typowe podejście u Amerykanów i różnych ludzi zafascynowanych amerykańskim
podejściem do człowieka, w którym wyróżniają się dwie istotne sprawy: pranie
mózgu i arogancja. Daleko tego nie trzeba szukać - ile razy czytało się np. o
różnych dziwnych zakazach w różnych "coding standards", gdzie goście zakazują
stosowania różnych "niebezpiecznych" konstrukcji, bo jakiś gościu stosując tą
konstrukcję coś kiedyś spartolił, albo stosuje się jedno z typowych podejść
menedżera, który nie lubi się przyznawać do swojej niewiedzy lub braku
umiejętności "dla mnie to jest nieczytelne".

Do tej właśnie kategorii spraw należy stwierdzenie "jeśli nie stosujesz się do
naszych wytycznych, to twój projekt jest do dupy". To się w zasadzie nie różni
od stwierdzenia "kto nie jest z nami, ten przeciwko nam".

> >Ja również jestem zdania, że co jest nietestowalne jest bezużyteczne. Co
> >więcej, argumentacja tego gościa (duże projekty, setki tysięcy linii kodu,
> >ścisłe terminy oddania, wielu developerów) nie przemawia do mnie zupełnie, bo
> >tak się akurat składa, że mam do czynienia w pracy z takimi właśnie
> >projektami, nasz proces nawet nie jest typowo Agile'owy, ale w to, że kod
> >powinien być wytestowany na każdą ewentualność nikt nigdy nie próbował
> >wątpić.

> Wie Pan, z takimi projektami jak Cedric Beust pan na pewno nie mial do 
> czynienia - bez urazy. Zanim Cedric'a nie zgarnal Google, Cedric byl lead 
> developerem kontenera EJB w BEA. To niestety zupelnie inna klasa projektow niz 
> cokolwiek produkowanego w PL. 

Możliwe :). Aczkolwiek nie bardzo mi się chce wierzyć, że "im większy projekt,
tym mniej się go da testować".

> A tak zupelnie z innej beczki: mam takie brzydkie podejrzenie, ze te duze 
> projekty o ktorych pan pisze to takie bardziej robienie bugfixow i 
> enchancementow (dorzezbic tu kawalek, tanto troszeczke zmienic) niz tworzenie 
> duzego systemu od poczatku.

I tak i nie. Zdarzały mi się projekty robione "od skracza", aczkolwiek
przyznam, że większość to było rozszerzanie istniejącego kodu. Ale szczerze
mówiąc nie widzę związku - na jakiej podstawie pan twierdzisz, że robienie
"enhancementów" to jest "dorzeźbić kawałek, tamto troszeczkę zmienić"?
Dorabiany ficzer niejednokrotnie pod względem dokładanego kodu i
funkcjonalności potrafi być często większy, niż cały system pod który się
podczepia.

A czym się przepraszam różni robienie dużego systemu od początku od dorabiania
ficzerów? Jedynie ilością pracy do wykonania. Każda praca musi być podzielona
na mniejsze, a w przypadku tworzenia systemu od zera istotna różnica zasadza
się nad wykonaniem "podstawowej części systemu". Reszta to dokładanie
kolejnych kawałków, które mają się wpasować w system.

I wszystkie obowiązuje dokładnie ten sam proces.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Mon, 12 Jun 2006 13:42:39 +0200, Adam Karpierz skrobie:
> "Aleksander Galicki" <no@no.com> wrote:

> > Mnostwo pewnie. Ale ten przyklad jest jednak dosc spektakularny.

> Tu sie zgadzam w pelni z Panem.
> Wiele uczacy.

Tu się również zgadzam, aczkolwiek błąd dla mnie nie powala na kolana.

To jest niestety integralna cecha wszystkich algorytmów, które pracują na
liczbach całkowitych o określonej wielkości - nie ma przeproś, tego typu
błędów jest wciąż w oprogramowaniu mnóstwo i przy operowaniu na mnóstwie
danych w końcu się okaże, że np. nie dodasz do zbiornika ośmiu miliardów
elementów, bo dana liczba całkowita nie ma takiej pojemności. I bujaj się.

> > I ta implementacja byla z prostym bledem, ktorego NIKT nie
> > znalalz przez 20 lat.

> Hm...
> _Nigdy_ nie zdazylo mie sie uzyc algorytmu "z ksiazki"
> bez sprawdzenia.

Słusznie. Co więcej, bezpieczne implementacje robi się zazwyczaj tak, że
określa się ramy, w jakich algorytm może pracować normalnie i operacje zostaną
wykonane poprawnie, w jakich trzeba przygotować się na korektę względem tego,
co zrobi procesor, a w jakich ten algorytm pracowac nie może i musi się
wywalić.

To nie jest moim zdaniem żaden błąd, to jest po prostu uproszczona wersja
algorytmu przewidziana do działania, na ograniczonym zakresie liczb. Jeśli
komuś się wydaje, że poprawka tego typu:

int mid = ((unsigned)left + (unsigned)right)/2;

czy:

int mid = ((long)left + (long)right)/2;

załatwi sprawę, to musi się jeszcze trochę nad sobą zastanowić.

Nie, w samym algorytmie błędu nie będzie. Będzie "trochę gdzie indziej". Jeśli
piszemy algorytmy na liczbach całkowitych o określonej pojemności, to algorytm
musi mieć określone ramy, w ktrych działa dobrze. Jak nie, to stosujemy
bignumy.

> Troche odbiegne od tematu:
> Powiem szczerze ze nigdy pozniej nie spotkalem (no z jednym
> wyjatkiem) ksiazki ktora by w taki profesjonalny sposob podchodzila
> do sprawy jak w/w.

Jeśli chodzi o Bentley'a, to się również zgadzam ;)

> > Nastepnie dobry programista (J Bloch) zaimplementowal ten algorytm na

> dobry programista nie implikuje bezbledny programista

Myślę wręcz, że "bezbłędny programista" to oksymoron ;)

> "We must program carefully, defensively, and remain ever vigilant."

> A Tu sie z w/w i z Panem zgadzam w pelni.

Też się zgadzam, ale to stwierdzenie jest zgoła banalne - praca inżyniera nie
polega na przenoszeniu rozwiązań z jednego miejsca w drugie, tylko na
stosowaniu poprawnych rozwiązań

> Niestety nie da sie ukryc ze wsrod "mlodziezy" jest to coraz rzadziej
> spotykana metoda. Ide, debuggery i inne takie jej nie sprzyjaja.
> Moze to ze na Odrze czekalo sie na kompilacje np tydzien
> (i dlatego program byl maksymalnei wycyzelowany) nie bylo takie zle :) ?

Cóż, tendencja do ułatwiania sobie życia temu nie sprzyja - ostatnio jak
trzeba było zbyt dużo czasu czekac na samo odpalenie kodu na docelowej
maszynie, co wydłużało cykl poprawki-kompilacja-weryfikacja, zrobiło się
host-testy.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Mon, 12 Jun 2006 07:49:11 -0500, A.L. skrobie:
> On Mon, 12 Jun 2006 05:43:52 +0200, "Aleksander Galicki" <no@no.com>
> wrote:

> >>On Mon, 12 Jun 2006 03:52:35 +0200, "Aleksander Galicki" <no@no.com>
> >>wrote:
> >>
> >>>A tak zupelnie z innej beczki: mam takie brzydkie podejrzenie, ze te duze 
> >>>projekty o ktorych pan pisze to takie bardziej robienie bugfixow i 
> >>>enchancementow (dorzezbic tu kawalek, tanto troszeczke zmienic) niz
> >>tworzenie 
> >>>duzego systemu od poczatku.
> >>>
> >>
> >>Ja tez, zwlaszcza w kontekscie sugestii Pana S. testowania
> >>"wszystkich mozliwych sciezek wykonania"
> >
> >BTW: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-
> >nearly.html
> >
> >prawie spadlem z krzesla jak to zobaczylem....
> >

> To jest wlasnie roznica miedzy "informatyka akademicka" a
> "informatyka przemyslowa". 

Niemalże wyjął mi to pan z ust, choć nie wiem, czy z tego samego powodu ;)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Aleksander Galicki wrote:
> Udowodnil poprawnosc tego algorytmu. Nastepnie napisal implementacje w C. Na
> jakies _20 liniek_. I ta implementacja byla z prostym bledem, ktorego NIKT nie
> znalalz przez 20 lat. 

Ale ten błąd tyczy się tylko języków z liczbami całkowitym o
ograniczonym zakresie. W takim Pythonie nic się nie stanie.

BTW. A pomysł na (low + high) >> 1 przedstawiony w tym blogu
     jest tak samo błędny jak (low + high) / 2.

w.

> BTW. A pomysł na (low + high) >> 1 przedstawiony w tym blogu
>     jest tak samo błędny jak (low + high) / 2.

Powiem, wiecej.
On jest generalnie bledny.
Nie w kazdym jezyku (tak jak w C/C++) jest zagwarantowane
ze liczby integer sa pamietane tak samo jak w C/C++

AK

"A.L." <alewando@fala2005.com> wrote in message

> To jest wlasnie roznica miedzy "informatyka akademicka" a
> "informatyka przemyslowa".

lepiej chyba tego ujac nie mozna  :)

AK 

On Mon, 12 Jun 2006 19:30:15 +0200, "Adam Karpierz"
<karpierz@NOOOOSPAAAAMpython.pl> wrote:

>"A.L." <alewando@fala2005.com> wrote in message
>
>> To jest wlasnie roznica miedzy "informatyka akademicka" a
>> "informatyka przemyslowa".
>
>lepiej chyba tego ujac nie mozna  :)
>
>AK 
>

Nie przyganiajac "informatyce akademickiej"... Owa "informatyka
akademicka" buduje i analizuje modele. Musi analizowac modele, bo
rzeczywistosc jest zbyt skmplikowana aby dalo sie pelna analize
pzreprowadzic. Ponadto, zbyt duzo realistycznych zalozen zaciemnialoby
istote sprawy.

To co jest naganne to nei sama "informatyka akademicka" a nie
rozroznianie miedzy owa "informatyka akademicka" a swiatem
rzeczywistym. No, ale to juz nie wina akademikow....

A.L.

Wojciech Muła <wojciech_mula@poczta.null.onet.pl.invalid> writes:

> BTW. A pomysł na (low + high) >> 1 przedstawiony w tym blogu
>      jest tak samo błędny jak (low + high) / 2.

Przedstawione jest (low + high) >>> 1, co jest poprawne.

(Semantyka >>> polegająca na reinterpretacji ujemnej liczby jako
dodatniej przez wzięcie jej modulo 2**32 albo 2**64 jest brzydka,
ale akurat w tym przypadku przydatna.)

Inna sprawa, że raczej bardziej prawdopodobne od przepełnienia w tym
miejscu, jest przepełnienie gdzieś wcześniej przy liczeniu rozmiaru
tablicy. A na 32-bitowych komputerach jeszcze bardziej prawdopodobne
jest to, że wcześniej skończy się pamięć niż rozmiar int.

"Adam Karpierz" <karpierz@NOOOOSPAAAAMpython.pl> writes:

> On jest generalnie bledny.
> Nie w kazdym jezyku (tak jak w C/C++) jest zagwarantowane
> ze liczby integer sa pamietane tak samo jak w C/C++

Mowa była o Javie, gdzie semantyka >> i >>> jest jednoznacznie
określona.

Jaki język z jakim odpowiednikiem tego zapisu masz na myśli,
gdzie coś tu jest niejednoznaczne?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

>On Mon, 12 Jun 2006 11:21:08 +0200, "Aleksander Galicki" <no@no.com>
>wrote:
>
>>>> Pan uwaznie to czytal...?
>>>
>>>W miare uwaznie.
>>>Co w tym takiego dziwnego ?
>>>Malo to nawet samych algorytmow bywalo delikatnie mowiac
>>>"nie dzialajacych zgodnei z zalozeniami" ?
>>>
>>
>>Mnostwo pewnie. Ale ten przyklad jest jednak dosc spektakularny. W znanej
>>niemal wsztstkim ksiazce znany spec rozwazal szczegolowo dosc prosty
>algorytm.
>>Udowodnil poprawnosc tego algorytmu. Nastepnie napisal implementacje w C. Na
>>jakies _20 liniek_.
>
>Ta implementacja to nei byla implementacja tego programu dla ktorego
>przeprowadzono dowod. Nie jest to zadne odkrycie jako takie.
>Zaskakujace jest to ze to kogos zaskakuje.
>
>Metoda "cut from textbook and paste" prowadzi wlasnei do takich
>niespodzianek. 

To jest trywializacja sprawy. Nie wiadomo czy scopy-pasteoweal czy tak
zapamietal. Ale nawet gdyby sam od poczatku pisal i tak mogl sie pomylic. I o
to w tym przykladzie chodzi - nawet w 20 linijkach mozesz popelnic blad,
ktorego ani testowanie ani przegladanie w kolko nie wykryje przez N lat. To
jest twierdzenie trywialne, ale nie dla wszystkich, wiec trzeba przykladow z
zycia zeby to unaocznic..


A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl

Marcin 'Qrczak' Kowalczyk wrote:
> Wojciech Muła <wojciech_mula@poczta.null.onet.pl.invalid> writes:
>
>> BTW. A pomysł na (low + high) >> 1 przedstawiony w tym blogu
>>      jest tak samo błędny jak (low + high) / 2.
>
> Przedstawione jest (low + high) >>> 1, co jest poprawne.

To ja teraz nie rozumiem: skoro przepełnienie występuje przy
sumowaniu (low + high) to już chyba nie ma znaczenia, co się
z tym potem robi - czy dzieli, czy przesuwa w prawo.

w.

Wojciech Muła <wojciech_mula@poczta.null.onet.pl.invalid> writes:

>>> BTW. A pomysł na (low + high) >> 1 przedstawiony w tym blogu
>>>      jest tak samo błędny jak (low + high) / 2.
>>
>> Przedstawione jest (low + high) >>> 1, co jest poprawne.
>
> To ja teraz nie rozumiem: skoro przepełnienie występuje przy
> sumowaniu (low + high) to już chyba nie ma znaczenia, co się
> z tym potem robi - czy dzieli, czy przesuwa w prawo.

Przepełni się najwyżej jeden bit, tzn. najwyższy bit wartości wyląduje
w bicie znaku. Operator >>> w odróżnieniu od >> traktuje bit znaku
właśnie tak jakby był najwyższym bitem wartości, czyli akurat robi to,
o co chodzi.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

"Aleksander Galicki" <no@no.com> writes:

[...]

> A tak zupelnie z innej beczki: mam takie brzydkie podejrzenie, 
> ze te duze projekty o ktorych pan pisze to takie bardziej robienie
> bugfixow i enchancementow (dorzezbic tu kawalek, tanto troszeczke
> zmienic) niz tworzenie duzego systemu od poczatku.

'Taaaka ryba' ;)

>> Mnie np zainteresowal inny nieco temat. Temat 

> fanatyzmu niektorych proponentow TDD. Podejscie pt "take it or die" - albo 

>> stosujesz sie do wszystkich wytycznych, albo twoj projet jest do dupy.
>Jesli 
>> nie mozesz stosowac naszych rad, to twoje projekt jest do dupy. Albo 
>> przedstawiania TDD jako jakiegos generalnego lekarstwa na wszystko - z 
>> oslawionym juz stwierdzeniem ze testy = specyfikacja. 
>
>Takiego podejścia zawsze byłem przeciwnikiem - ale jak zauważyłem jest to
>dość
>typowe podejście u Amerykanów i różnych ludzi zafascynowanych amerykańskim
>podejściem do człowieka, w którym wyróżniają się dwie istotne sprawy: pranie
>mózgu i arogancja. 

Fanatysm i glupota sa miedzynarodowe.

>
>> A tak zupelnie z innej beczki: mam takie brzydkie podejrzenie, ze te duze 
>> projekty o ktorych pan pisze to takie bardziej robienie bugfixow i 
>> enchancementow (dorzezbic tu kawalek, tanto troszeczke zmienic) niz
>tworzenie 
>> duzego systemu od poczatku.
>
>I tak i nie. Zdarzały mi się projekty robione "od skracza", aczkolwiek
>przyznam, że większość to było rozszerzanie istniejącego kodu. Ale szczerze
>mówiąc nie widzę związku - na jakiej podstawie pan twierdzisz, że robienie
>"enhancementów" to jest "dorzeźbić kawałek, tamto troszeczkę zmienić"?

To tylko 'statystyczne' ujecie sprawy, nie bede sie upieral przy tym 
slownictwie.

>
>A czym się przepraszam różni robienie dużego systemu od początku od
>dorabiania
>ficzerów? 

Oj, rozni sie. I to bardzo. Musi Pan wiedziec czym, skoro juz Pan to i tamto 
probowal. Chocby presja - w skrajnym przypadku z jednej strony - dorobienie 
kawalka do legacy system, ktory jest postrzegany jako zlo konieczne, a z 
drugiej - presja wprowadzenia duzego produktu na rynek z rozwinieta 
konkurencja. Statystycznie - rowniez zlozonosc (techniczna, organizacyjna, 
polityczna, biznesowa, whatever) nowego projektu jest znacznie wieksza niz 
zlozonosc 'ulepszenia'.

Nie chce mi sie wchodzic w szczegoly, ale dla mnie to sprawa oczywista: 
utrzymywanie systemu i tworzenie systemu roznia sie zasadniczo. (Rowniez w 
sensie przyjemnosci/satysfakcji z pracy. Tak bardzo, ze jak ostatnio szukalem 
pracy, moim pierwszym i najwazniejszym warunkiem bylo "to MUSI byc nowy 
system/produkt, zadnego maintenance, przepisywania, integracji itepe".)


A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl