🚀 go-pugleaf

jarekr <jhratajski@popraw.literowki.pzcota.otne.pl> napisał(a): 

> Aleksander Galicki napisał(a):
> > 
> > Jarku, zajrzyj pod ww link i pozniej rzucaj sie c VI. Ten produkt oferuje cos
> > co jest dostepne za darmo i to lepiej zaimplementowane. 
> > Wszystkie rzeczy, ktore ten produkt potrafi wykryc - to rzeczy trywialne i
> > dotycza bardziej czytelnosci kodu, sprawdzanie konwencji skladniowych i takic
> h
> > tam. To wszystko jest np w Eclipse i np. w Checkstyle - za darmo i duzo
> > lepsze. Zreszta, te rzeczy sa na tyle trywialne, ze niczego nigdzie nie
> > uratuja - sa wiec malowartosciowe jakby. Ktos jeszcze za to kase chce
> > zgarniac? Cwaniactwo zerujace na naiwnosci (chcialem uzyc innego slowa).
> > O, popatrz na to "http://www.programmingresearch.com/images/qaj_eclipse.gif"
> > Co za mission critical uwagi: "Plese replace this literal string with a
> > symbolic expression." albo "Do not use tabs, layout may differ when viewing
> > this code wih another editor.". 
> > 
> > Kase chcesz za to zaplacic?! 
> > 
> 
> Napisałeś wcześniej:
> produkty dla Javy *tego rodzaju*.
> 
> Więc ja odczytałem - np. checkstyle, eclipse metrics itp. Myślałem, że 
> chodzi Ci ogólnie o *typ*.

Mi chodzilo o typ, ale nie sprecyzowalem o jaki. O narzedzia od wynajdywania
banalnych przeoczen i mierzenia banalnych metryk, ktore to narzedzia sie
sprzedaje za ciezkie pieniadze i udawaja ze maja sie do zapewnienia jakosci kodu. 
Mierzenie metryk ma jakis sens gdy sie ma 400kloc nieznanego produktu i 20 min
do znalezienia czy przypadkiem caly ten kod nie jest w jednej metodzie. Taka
potrzeba zachodzi jednak dosc rzadko. Do codziennego developmentu Twoje IDE
samo Ci powie: "ups, nie posprzatales po sobie i w kodzie jest deklaracja
zmiennej, ktorej nikt nie uzywa". Eclipse powie Ci to natychmiast, bo Eclipse
kompiluje szybciej niz piszesz kod.
Metryki zas przy normalnym developmencie nie sa potrzebne. Pozornym wyjatkiem
moze byc sytuacja gdy zatrudniles wlasnie 7000 obywateli Sri Lanki do
napisanie systemu billingowego i chcesz sprawdzic, czy aby nie pisza tego w
jednej wielokrotnie zagniezdzonej petli for. 

> Co do konkretnej instancji (QAJ) to się zgadzam - nie ma sensu kupować 
> (prawdopodobnie - nie czytałem wszystkich cech).
> 
> Tak czy siak w checkstyle, eclipse metrics też trzeba zainwestować na 
> konfigurację, nadzór itp.
> Wierzę, że zwykle warto. Ale jest to dobry temat na flejm.
> 
> 
> >>Poza tym w praktyce nigdy nie wiesz kogo zatrudniasz - ludzie potrafią 
> >>mieć dobre CV - a dopiero potem wychodzi, że programuja w BIOSIE 
> >>(autentyk z CV btw.) no i np. trzeba szybko dzieła zebrane takiego 
> >>delikwenta przeczesać (zwłaszcza jeśli potrzeba coś ocalić)
> > 
> > 
> > Od tego sa peer reviews. Na razie zadny tool tego nie zastapi nawet w 1%.
> 
> eeeeeee eee eee  - a kto zasponsoruje takie review?

Zalezy, jak moja firma zatrudnia graduates, to przez pierwsze 6 miesiecy owi
graduate wykonuja prace, za ktora nikogo sie nie charge'uje. I cokolwiek
wyprodukuja jest poddawane review osob z wiekszym doswiadczeniem. Firma wiec
placi za to - dlatego tez inwestycja w graduate jest bardzo droga inwestycja.
W przypadku normalnego developmentu placi za to klient. Aczkolwiek moze to byc
roznie nazwane w konkretnych kontraktach.


A.

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