🚀 go-pugleaf

Użytkownik "Filip Sielimowicz" <sielim@poczta.onet.pl> napisał w wiadomości 
news:dl86ej$hnh$1@news.onet.pl...

> A dokładniej chodzi o to, jaki profil osobowościowy powinien mieć 
> "inspektor": czy powinien bardziej
>
> przypominać kapo z grubym pejczem, który po prostu "lubi" znajdować błędy, 
> czy raczej jest to zajęcie
>
> dla dobrego ojca, który cierpliwie wskaże dziecku co i jak, nawet, jeśli 
> nie będzie dokładnie tłumaczył "dlaczego"
>
> (stad musi być dobrze umocowany w zagadnieniach projektowych, mieć szersze 
> spojrzenie na system) ?

A pytam dlatego, że akurat sam pełnie rolę "inspektora" i moja postawa 
zdecydowanie
bardziej przypomina "ojca". Natomiast mam wrażenie, że często oczekuje się 
ode mnie
postawy "kapo". Zastanawiam się, czy może rzeczywiscie powinienem bardziej
"uelastycznić" swoją postawę i swobodnie przeskakiwać między kapo a ojcem, 
czy raczej
należałoby rozdzielić jakieś funkcje - oddzielnie wsparcie technologiczne, a 
oddzielnie
konsekwentne rozliczanie z popełnianych błędów. 

On Sun, 13 Nov 2005 21:07:49 +0100, "Filip Sielimowicz"
<sielim@poczta.onet.pl> wrote:

>W artykule http://www.e-informatyka.pl/article/show/467#d0e358 pada taka 
>teza:
>
>"Powszechnie wiadomo, że przeglądy projektów i kodu są bardziej efektywne w 
>usuwaniu defektów niż testowanie."
>
 
Zawracanie glowy. Pewnie jakis uczony napisal papier.

A.L.

"Filip Sielimowicz" <sielim@poczta.onet.pl> writes:

[...]

> Zaciekawiło mnie to. Czy podzielacie ten pogląd ? 
> Ja sam prawdę mówiąc zaczynam się do tego przychylać, ale
> zastanawiają mnie ew. źródła takiej zależności. Czy chodzi 
> tu o zwykłą psychologię, że programista, któremu ktoś patrzy 
> na ręce bardziej się stara, niż gdy tylko ktoś bada widoczne 
> efekty

W testowaniu 'przechodzą' programistyczne potworki, które co prawda
działają poprawnie, ale są trudne w modyfikacji.  Inspekcje powinny
(chyba) takim potworkom zapobiegać.

W sumie to dopiero niedawno w inżynierii zainteresowano się tak 
na serio jakością kodu pod względem czytelności, zrozumiałości 
dla człowieka etc.

> jego pracy, czy bardziej chodzi o to, że programiści potrzebują
> realnego wsparcia od bardziej doświadczonych osób ?

Raczej wsparcia ze strony ludzi, którzy kontrolują rzeczy nie związane
z techniką i komputerami.  No i przyjaznego admina.

> A dokładniej chodzi o to, jaki profil osobowościowy powinien mieć
> "inspektor": czy powinien bardziej przypominać kapo z grubym
> pejczem, który po prostu "lubi" znajdować błędy, czy raczej jest 
> to zajęcie
>
> dla dobrego ojca, który cierpliwie wskaże dziecku co i jak, nawet,
> jeśli nie będzie dokładnie tłumaczył "dlaczego"

Ja bym stawiał na archetyp kolegi z roku :)

> (stad musi być dobrze umocowany w zagadnieniach projektowych, 
> mieć szersze spojrzenie na system) ?

IMO niekoniecznie.

-- 
http://www.piotr.dembiński.prv.pl

"Filip Sielimowicz" <sielim@poczta.onet.pl> writes:

[...]

> Zastanawiam się, czy może rzeczywiscie powinienem bardziej
> "uelastycznić" swoją postawę

Przeczytaj sobie jakąś książkę o asertywności.

Dnia Sun, 13 Nov 2005 21:07:49 +0100, Filip Sielimowicz skrobie:
> W artykule http://www.e-informatyka.pl/article/show/467#d0e358 pada taka 
> teza:

> "Powszechnie wiadomo, że przeglądy projektów i kodu są bardziej efektywne w 
> usuwaniu defektów niż testowanie."

Co za wierutna bzdura! Nie, nie przeczytałem, ale rzucanie takiego
stwierdzenia to jest bełkot, niezależnie od tego, jak bardzo chciałoby się to
udowodnić.

> Zaciekawiło mnie to. Czy podzielacie ten pogląd ? Ja sam prawdę mówiąc
> zaczynam się do tego przychylać, ale zastanawiają mnie ew. źródła takiej
> zależności. Czy chodzi tu o zwykłą psychologię, że programista, któremu ktoś
> patrzy na ręce bardziej sięstara, niż gdy tylko ktoś bada widoczne efekty
> jego pracy, czy bardziej chodzi o to, że programiści potrzebują realnego 
> wsparcia od bardziej doświadczonych osób ?

Raczej programiści potrzebują dostać po łapach za tworzenie potworków.

Kiedyś pamiętam, jak specjaliści od jakości zainteresowali się moją inspekcją,
w której na (załóżmy) 50 linii było 25 zgłoszeń. Dla nich sprawa była taka: no
jak to kurde, błąd w co drugiej linii?

To jest właśnie przykład, jaka jest różnica pomiędzy tym, co na inspekcji
widzą teoretycy, a co praktycy.

Bo w powyższym kodzie ponad połowa zgłoszeń dotyczyła niejasnych komentarzy,
literówek w komentarzach, "nieładnych" nazw funkcji/symboli/zmiennych, źle
postawionej klamry itd.

> A dokładniej chodzi o to, jaki profil osobowościowy powinien mieć
> "inspektor": czy powinien bardziej przypominać kapo z grubym pejczem, który
> po prostu "lubi" znajdować błędy, czy raczej jest to zajęcie dla dobrego
> ojca, który cierpliwie wskaże dziecku co i jak, nawet, jeśli nie będzie
> dokładnie tłumaczył "dlaczego" (stad musi być dobrze umocowany w
> zagadnieniach projektowych, mieć szersze spojrzenie na system) ?

Nie rozumiem zupełnie. Jeśli inspekcje Fagana mają jakiś aspekt
psychologiczny, to tylko tyle: CZŁOWIEKU, DAJ SE LUZ.

Inspekcja ma znajdować DEFEKTY KODU. W najlepszym razie na inspekcji może
wyjść jakiś błąd logiczny (w mojej praktyce znajdowalność takich błędów nie
przekracza 30%, a znalezione błędy logiczne to może 1% zgłoszeń). Inspekcja ma
przede wszystkim zapewnić, że wszyscy potrafią ten kod czytać, zrozumieć jak
działa; kod zatem musi być po prostu czytelny i stosować się do coding
standards. I na to przede wszystkim inspekcja jest ukierunkowana.

Całkowitym nieporozumieniem jest traktowanie inspekcji jako sprawdzanie
jakości pracy developera. To bzdura! Zgłoszenie na inspekcji może dotyczyć
jakiegokolwiek fragmentu kodu! Nawet jeśli to jest jakiś fragment, który
został dostrzeżony jedynie PRZYPADKIEM, w kodzie, który w ogóle nie był
modyfikowany i istnieje od lat, WOLNO na dowolnej inspekcji dać zgłoszenie do
takiego fragmentu. Co prawda osobnym zagadnieniem jest to, kto ma to poprawić,
ale to nie zmienia faktu, że: INSPEKCJA MA POPRAWIĆ JAKOŚĆ KODU, A NIE
STANOWIĆ BAT NA PROGRAMISTÓW!

Jeśli błąd się prześlizgnie przez przez testowanie, to jest to wina tego, kto
opracowywał testy. I to wina niezaprzeczalna.

Jeśli prześlizgnie się przez inspekcję, no to trudno. Zawsze można powiedzieć,
że się przeoczyło, nie zauważyło, ktoś nie zwrócił uwagi, albo wydawało mu
się, że jest ok. Natomiast jak najbardziej można moderatora ścigać za
przepuszczenie kodu niezgodnego z coding standards bez wyraźnego opisania
przyczyny jego złamania.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ 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@pl.wp.spamu.lubie.nie.invalid> writes:

[...]

> Całkowitym nieporozumieniem jest traktowanie inspekcji jako
> sprawdzanie jakości pracy developera.

Właśnie.  Kluczowe jest zrozumienie, że każdy, nawet najlepszy
programista popełnia błędy.

On 2005-11-13 14:07:49 -0600, "Filip Sielimowicz" <sielim@poczta.onet.pl> said:

> W artykule http://www.e-informatyka.pl/article/show/467#d0e358 pada taka teza:
> 
> "Powszechnie wiadomo, że przeglądy projektów i kodu są bardziej 
> efektywne w usuwaniu defektów niż testowanie."
> 

A jakie sa w rzeczonym artykule kryteria efektywnosci? W odniesieniu do 
jakiego typu defektow?

Przeglady sa efektywne w wykrywaniu defektow takich jak analfebetyzm, 
lenistwo lub slepota.
To tez przydatne.

Co do powszechnosci - "Nie wiadomo tego powszechnie, ale zdania 
zaczynajace sie od "powszechnie wiadomo" nalezy ignorowac; w przypadku 
ich nagminnego wystepowania i\lub recydywy, ich autorow oddawac do 
psychiatryka lub pod sad polowy".

Piotr

Filip Sielimowicz (sielim@poczta.onet.pl) napisał(a):
>W artykule http://www.e-informatyka.pl/article/show/467#d0e358 pada
taka
> A dokładniej chodzi o to, jaki profil osobowościowy powinien mieć 
> "inspektor": czy powinien bardziej
> przypominać kapo z grubym pejczem, który po prostu "lubi"
> znajdować błędy,  czy raczej jest to zajęcie
> dla dobrego ojca, który cierpliwie wskaże dziecku co i jak, nawet,
> jeśli nie  będzie dokładnie tłumaczył "dlaczego"
> (stad musi być dobrze umocowany w zagadnieniach projektowych, mieć
> szersze  spojrzenie na system) ?

To chyba zależy od indywidualnego przypadku - charakteru
osoby kontrolowanej. Do jednych trzeba po dobroci bo
inaczej się blokują, ręce im się trzęsą itd, a do innych
trzeba z batem bo mają w d.. co się im tłumaczy.

-- 
Pozdrawiam
Miroo
Teoria względności: "Pracownik jest zbędny w firmie gdy prosi o
podwyżkę, lecz niezastąpiony gdy prosi o urlop" 

Filip Sielimowicz <sielim@poczta.onet.pl> napisał(a): 

> W artykule http://www.e-informatyka.pl/article/show/467#d0e358 pada taka 
> teza:
> 
> "Powszechnie wiadomo, że przeglądy projektów i kodu są bardziej efektywne w 
> usuwaniu defektów niż testowanie."
> 

Ależ bzdura...

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