🚀 go-pugleaf

Witam

A.L. wrote:

> Nie wyobrazam sobie sytuacji gdy w NORMALNIE FUNKCJONUJACEJ firmie cos
> takiego byloby mozliwe. 

W NORMALNIE funkcjonującej to nie, ale są firmy, które się gdzieś śpieszą,
może to jakaś obsesja "Time to market", może manago chcą kosztem produktu
zafundować dyrektorowi prezent w postaci "releasu" na jego urodziny? Nie
wiem, nie jestem poinformowany o takich szczegółach.

> To nei ejst sprawa JAKOSCI KODU, to jest 
> sprawa JAKOSCI PROJEKTU ("design" zeby nie bylo watpliwosci).

Ależ Panie A.L. zgadzam się w 100%.

> Jezeli 
> organizacja firmy jest taka ze klase z 500 metodami mozna dopiero
> wykryc przy pomocy "tooli" gdy klasa juz zostala zaimplementowana, to
> ja bardzo przepraszam, ale jedyna rzecz na jaka firma zasluguje to
> bankructwo.

Tak powinno być, ale tak nie jest i jest mi z tego powodu przykro, ale firmy
mające duże finanse, mają bardzo dużą inercję więc zanim zbankrutują to
ujdzie im płazem nie jeden taki wyczyn.

> Przeciez w koncu sie robi jakis design? 

No tak. Dopóki nie przychodzi czas zwany "3, 2, 1 miesiąc do releasu" wtedy
liczba żądanych ficzerów potrafi nawet rosnąć, a koderzy piszą (szybko) bo
jak nie napiszą to kary pójdą od dołu a nie od góry. Który manago przyznaje
się do błędu - osobiście znam nie wielu. Natomiast znam takich, którzy
nawet ewidentne błędy własne topią w zarządzanym zespole.

> I to wlasnei na tym etapie tzreba wykryc ze klasa jest "za ciezka". 

Oczywiście.

> Jak jest za ciezka, i taki projekt przejdzie, to nie jest to wina
> developera a projektanta. 

Tak. Ma Pan rację.

> Ktorego tez ktos powinien kontrolowac.

Ale kto, kolega, który z nim pije wódkę i grają razem w golfa? W pewnym
momencie kończy się inżynieria i zaczynają się pytania tylko o kasę i tu
jest pole do popisu dla lewych projektantów, którzy wcisną gościom od kasy
każdy kit, a oni to łykną, bo jest lepiej pisać nowe ficzery niż poprawiać
bugi i refaktoryzować kod.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/