🚀 go-pugleaf

Dnia Tue, 07 Mar 2006 00:19:35 +0100, mgl skrobie:
> Muchomor wrote:
> > Uzywamy InForce (http://www.klocwork.com/products/inforce.asp).

> Korzystacie z tego z poziomu IDE?
> Czy podłączyliście może do automatycznego buildowania?

Jejku, co to za różnica.

> Heh, taka cena "dojrzałości procesu" ;). Zasłyszane: w pewnej dużej 
> znanej firmie z CMM 5 regularnie prowadzone są przeglądy kodu, 
> polegające na skrupulatnym czytaniu kodu przez trzy osoby linijka po 
> linijce w ustalonym tempie i zatwierdzaniu każdego wiersza z osobna. 
> Oczywiście tak dokładny przegląd kodu ma duży sens, jednak raz 
> zatwierdzony kod jest zamrażany i "odmrożenie go" do zmian jest 
> procedurą nieprzewidzianą w procesie ;). Dochodzi więc do sytuacji, gdy 
> ktoś pracuje z kawałkiem kodu, który ma już kilka lat i o którym nie ma 
> żadnej wiedzy, i nagle okazuje się, że dokumentacja danego interfejsu 
> jest zbyt mało wyczerpująca - nie wiadomo do końca, jak dane metody 
> rzeczywiście działają, a do kodu zbliżyć się nie można. Taki lajf, gdy 
> procedur pełno - skomplikowany proces na pewno nie ułatwia pracy ;)

Zgadza się.

W praktyce zaś, im bardziej dokładny proces, tym częściej się go obchodzi.
Taka zasada panuje zawsze i kto twierdzi, że udało mu się doprowadzić do
stuprocentowego wypełniania procesu, to jest po prostu naiwny.

A tak się składa, że mam kilkuletnią praktykę z firmą z CMM 5. I rzeczy, o
których kolega pisze są jedną wielką fikcją. Po pierwsze, przeglądy kodu są
prowadzone nie "regularnie", tylko po zakończeniu opracowywania (i najczęściej
też wstępnym przetestowaniu) określonej zmiany w kodzie. Po drugie, kodu nie
przegląda się linijka po linijce, tylko "funkcjonalnie"; czyta się, co kod
robi, opisuje się słownie intencję autora, określa się logicznie operacje,
jakie ma wykonać tak opisany kod.

A już twierdzenie, że kod jest zamrożony to jest dosłownie szurnięte. Kod
zamrożony? Jeżeli kod jest zamrożony, to znaczy, że nadaje się wyłacznie do
kosza. Niby jak do kodu potem mają być dodawane nowe ficzery? Zresztą, co tam
ficzery; w jaki sposób poprawia się błędy znalezione przez SST? Co więcej, jeśli
ktoś przypadkiem na inspekcji zauważy błąd, którego do tej pory nikt nie
wykrył, i to błąd, który nie został wprowadzony wraz z ostatnią poprawką -
poprawia się go również! Dotyczy to również niejasnych komentarzy, literówek w
komentarzach itp.

Inspekcja służy do zatwierdzenia zmian, ale wykrywanie błędów na inspekcji to
fikcja. Statystyki wykryć błędów przez inspekcje są mizerniutkie. I słusznie,
bo inspekcja ma się skupić na kwestii CZYTELNOŚCI kodu i jasności jego
intencji. Właśnie po to, żeby było łatwo później go modyfikować i wprowadzać
poprawki, w tym również poprawki błędów. Ma zabezpieczać również przed
przedostawaniem się do kodu głupich pomysłów. Nic więcej. Gdybyśmy po takiej
inspekcji "zamrażali" kod, to taka inspekcja byłaby w ogóle pozbawiona
jakiegokolwiek sensu.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(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"