🚀 go-pugleaf

Dnia Tue, 29 Nov 2005 17:26:37 +0100, Grzesiek G. skrobie:
> Chcąc ulepszyć przeprowadzam refaktoryzację. Aby określić priorytety 
> refaktoryzacji robiłem np. tak:
> 1. Badałem "Cyclomatic Complexity" (sorry, ale nie wiem, jak to się 
> tłumaczy na polski) kodu.

Złożoność cyklomatyczna. Najczęściej wystarczy znaleźć "łaciński" odpowiednik,
co w języku angielskim, zwłaszcza jeśli chodzi o formalne terminy, nie jest
trudne.

> 2. Zaczynając od najbardziej złożonych metod zaczynałem je upraszczać, 
> aż do osiągnięcia zadawalającej wartości CC.
> Jest to oczywiście opis uproszczony, bo celem refaktoryzacji nie jest 
> jedynie upraszczanie złożonego kodu.

Jeśli tak, to ty chyba naprawdę nie masz co robić, albo potrzebujesz podkładki
dla managementu.

Złożoność cyklomatyczną i wszelkie inne złożoności - jak z moich doświadczeń
wynika - robi się tylko i wyłącznie z jednego powodu: żeby mieć formalną
podkładkę do pokazania durnym ćwierćprogramistom, że ten kod, który napisali,
nadaje się najwyżej do podtarcia dupy. W bardzo dużych firmach (a ja w takiej
akurat pracuję) jest to wręcz konieczność, bo tłumaczenie niektórym matołom,
dlaczego kod powinni napisać inaczej, w sytuacji gdy wprawny programista po
prostu spojrzy na kod i widzi, że tak napisany kod jest o dupę rozbić, to
najczęściej jak grochem o ścianę.

Problem polega na tym, że ustalenia odnośnie tego, jak pisać kod żeby był
"ładny" (to znaczy, żeby był czytelny, przejrzysty, bezpieczny, łatwo
rozszerzalny itd.), najczęściej są płynne. Programiści z sensownym
doświadczeniem i z wyobraźnią potrafią taki kod zrobić bez żadnego sprawdzania
metryk, ani tym podobnych pierduł. Ci, którzy wyobraźni nie mają i są w stanie
napisać switcha na 2000 linii z jednym case'm na dwa ekrany, muszą być jakoś
przyciśnięci. Jeśli przypadkiem dany zespół składa się z samych takich
programistów włącznie z Technical Leadem, to bez takiej formalnej podkładki po
prostu nie ma możliwości zmuszenia ludzi do pisania trochę porządniej.

Oczywiście, że "in a perfect world", jak się to niektórym Amerykanom czasem
wyrywa, powinno się mieć na stanowiskach "decydujących" tylko takich
programistów, którzy potrafią pisać sensownie i z wyobraźnią (w grę wchodzi tu
nie tylko wyobraźnia, ale też doświadczenie i kreatywność, a nawet jeszcze
tzw. "współczynnik odporności na wiedzę"). Ale niestety w realnym świecie tacy
programiści nie mają realnego wpływu na tzw. władzę w tym, komu jaki projekt
się przydzieli. Awanse menadżerskie rozkładają się w poprzek tych
umiejętności, nie mówiąc już o tym, że większość "rasowych managerów" nie
odróżnia przecież kodu napisanego "ładnie" i "brzydko". Nie istnieje też
możliwość, żeby "lepszy" programista miał większy wpływ na menedżerów, niż
"gorszy", przynajmniej w mierzalnym ogólnie zakresie.

Więc żeby jakoś usankcjonować staranniejsze co nieco pisanie kodu, robi się
nieprzekraczalne metryki i obowiązek wykonania analizy złożoności wraz z
zaformalizowaniem wyników, co jest warunkiem zakończenia pracy nad zmianami w
kodzie i zaakceptowaniem tego przez system. Nie jest to najlepsza metoda
oczywiście, bo wcale spełnienie tych metryk nie oznacza, że ktoś napisał dobry
kod, ale jest to już lepsze, niż godzenie się na "wolną amerykankę" w kodzie.

Ręce mi tylko czasami opadają, jak czasami mówię ludziom: no tu i tu
przydałoby się to zrobić tak-i-tak (co dla mnie akurat było wręcz
oczywistością, że tak się kod powinno pisać - przeważnie chodzi np. o
podzielenie kodu na mniejsze funkcje, zrobienie funkcji użytkowych możliwych
do wykorzystania w kilku miejscach, czyli naprawdę rzeczy PODSTAWOWE!) - po
czym w najlepszym razie słyszę "O, no, w zasadzie to byłby dobry pomysł...". I
to słyszę od programistów, którzy niby mają ponad trzyletnie doświadczenie z
software engineering.

> Ale CC nie jest zapewne jedyną metryką, której należy się przyglądać. W 
> związku z tym poszukuję opracowania opisującego inne metryki i 
> wskazującego ich dopuszczalne wartości dla "dobrego kodu". Bardziej mi 
> chodzi o dopuszczalne wartości, bo definicje nie znanych mi jeszcze 
> metryk sam sobie znajdę (chyba :-)).

Nie wiem. Widywałem czasem ustalone dopuszczalne wartości i wydaje mi się, że
trzeba to raczej samemu wypraktykować (wątpię, czy ktokolwiek ci coś ntt.
podpowie, bo to jest, szczerze powiedziawszy, taka trochę wiedza tajemna).

Wszystko zależy od tego, jak duży jest projekt i ilu ludzi jest w to
zaangażowanych, jaka jest wielkość organizacji. Jeśli jest niewielka, to
naprawdę bawienie się w jakieś złożoności cyklomatyczne to zawracanie głowy.

Żeby było jasne - liczenie złożoności cyklomatycznej i innych podobnych metryk
to ma być tylko i wyłącznie bat na programistów, a nie narzędzia do
polepszania jakości kodu. Jeśli uważasz, że potrzebujesz bata na programistów,
to powinieneś się zaopatrzyć w odpowiednie narzędzia do tego celu (typu
Klocwork), tyle że to kosztuje spore pieniądze (jeśli nie masz takich zbędnych
do wydania pieniędzy, to najczęściej oznacza, że ci to narzędzie wcale nie
jest potrzebne).

Natomiast co do 'code smells', znalazłem pierwsze lepsze trafienie w guglu:

http://xp.c2.com/CodeSmell.html

I to nawet wygląda sensownie - ale mówię: jest to wciąż tylko PODPOWIEDŹ, na
co należy zwracać uwagę. A nie bezwzględny nakaz.


-- 
//  _    ___         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"