Z artykułu możemy się dowiedzieć dlaczego warto sprawdzać kod wykorzystując metodę inspekcji. Jakie istnieją rodzaje inspekcji (od najbardziej formalnych do lekkich związanych z XP i Agile) oraz czym się każda z nich charakteryzuje. Autor również przedstawia potencjalne korzyści płynące z inspekcji, popierając je danymi z takich firm jak choćby IBM.
Wszystko pięknie... jedyne co mnie zastanawia dlaczego takie podejście jest ignorowane przez większość firm?
Z całym szacunkiem dla Mariusza Chrapko nie odkrył on przysłowiowej Ameryki, te techniki zapewniania jakości zostały wypracowane już dobrych parę lat temu, jednak nadal nie są powszechnie stosowane (przynajmniej wśród firm z którymi miałem do czynienia). Chlubnym wyjątkiem jest Comarch w którym miałem okazję pracować, jednak nawet i w nim tylko w naszym projekcie (tak! "nasz" projekt jest lepszy niż "wasz" ;-) mieliśmy pair programming oraz code reviews (i to tylko do pewnego stopnia).
Parę tygodni temu, pod czas Code Retreat zapytaliśmy uczestników czy w ich firmach stosuje się programowanie w parach... 10 może 15 procent osób podniosło ręce do góry. Ja osobiście nie znam lepszego sposobu na usprawnienie komunikacji w zespole, wdrożenie nowych pracowników oraz zwiększenie jakości tworzonego oprogramowania.
Ciekawe skąd taka niechęć do inspekcji ?
Osobiście uważam, że inspekcje powinny być prowadzone nie tylko na etapie tworzenia kodu, ale od samego początku procesu SDLC, szczególnie przy projektowaniu architektury systemu.
Polecam wszystkim zapoznanie się z artykułem oraz podsunięcie go "pod nos" kolegom z zespołu. Dodatkowo link do http://softwareinspection.org/ - kiedyś widziałem prezentacje człowieka z tej grupy pod czas wirtualnego seminarium, mówiącą o wartości inspekcji kodu w procesie wytwarzania oprogramowania. Niestety teraz nie jestem w stanie jej znaleźć - może komuś się uda?
0 comments:
Post a Comment