🚀 go-pugleaf

On Tue, 29 Nov 2005 17:26:37 +0100, "Grzesiek G."
<gruza@spamerom_nie.priv4.onet.pl> wrote:

>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.
>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.
>
>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 :-)).


Zawracanie glowy... Macie duzo czasu, widac....

A.L.

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

> 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.

> 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.

Poczytaj sobie o 'code smells'.

> Ale CC nie jest zapewne jedyną metryką, której należy się
> przyglądać. 

Ja bym stawiał właśnie na 'code smells'.

> W związku z tym poszukuję opracowania opisującego inne metryki 
> i wskazującego ich dopuszczalne wartości dla "dobrego kodu". 

Prawo Demeter, ktoś tu niedawno dawał linka do artykułu na ten temat.
Jest też trochę informacji w Wikipedii (hasło 'Law of Demeter').
Osobiście stawiałbym jednak na 'code smells'.

> Bardziej mi chodzi o dopuszczalne wartości, bo definicje nie 
> znanych mi jeszcze metryk sam sobie znajdę (chyba :-)).

Poczytaj sobie jeszcze o metodzie Goal-Question-Metric.  
Możliwe, że zaczynasz od d*y strony ;)

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

A.L. <wonlewando@grzegzulka.com> writes:

[...]

> Zawracanie glowy... Macie duzo czasu, widac....

Pomiary czasami się przydają.

A.L. napisał(a):
> On Tue, 29 Nov 2005 17:26:37 +0100, "Grzesiek G."
> <gruza@spamerom_nie.priv4.onet.pl> wrote:
> 
> 
>>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.
>>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.
>>
>>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 :-)).
> 
> 
> 
> Zawracanie glowy... Macie duzo czasu, widac....
> 
> A.L.
Czy to oznacza, że kodu nie należy refaktoryzować? A jeśli należy, to 
czym się kierować przy ustalaniu priorytetów (priorytetyzację stosuję, 
bo nie mam dużo czasu)?

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

On Tue, 29 Nov 2005 18:21:14 +0100, "Grzesiek G."
<gruza@spamerom_nie.priv4.onet.pl> wrote:

>A.L. napisa?(a):
>> On Tue, 29 Nov 2005 17:26:37 +0100, "Grzesiek G."
>> <gruza@spamerom_nie.priv4.onet.pl> wrote:
>> 
>> 
>>>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.
>>>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.
>>>
>>>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 :-)).
>> 
>> 
>> 
>> Zawracanie glowy... Macie duzo czasu, widac....
>> 
>> A.L.
>Czy to oznacza, ?e kodu nie nale?y refaktoryzowa?? A je?li nale?y, to 
>czym si? kierowa? przy ustalaniu priorytetów (priorytetyzacj? stosuj?, 
>bo nie mam du?o czasu)?

Wie Pan, kod sie refaktoryzuje z roznych powodow, ale po to zeby
zminimalizowac cyclomatic complexity, to pzrepraszam, ale oplulem kawa
monitor...

A.L.

On Tue, 29 Nov 2005 18:15:29 +0100, pdemb@gazeta.pl (Piotr Dembiñski)
wrote:

>A.L. <wonlewando@grzegzulka.com> writes:
>
>[...]
>
>> Zawracanie glowy... Macie duzo czasu, widac....
>
>Pomiary czasami siê przydaj±.

Czyzby Pan Kolega juz nabral wystarczajacego doswiadczenia
pzremyslowego zeby sie wypowiadac na temat "jak to sie powinno robic w
przemysle"?...

A.L.

A.L. napisał(a):
> On Tue, 29 Nov 2005 18:21:14 +0100, "Grzesiek G."
> <gruza@spamerom_nie.priv4.onet.pl> wrote:
> 
> 
>>A.L. napisa?(a):
>>
>>>On Tue, 29 Nov 2005 17:26:37 +0100, "Grzesiek G."
>>><gruza@spamerom_nie.priv4.onet.pl> wrote:
>>>
>>>
>>>
>>>>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.
>>>>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.
>>>>
>>>>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 :-)).
>>>
>>>
>>>
>>>Zawracanie glowy... Macie duzo czasu, widac....
>>>
>>>A.L.
>>
>>Czy to oznacza, ?e kodu nie nale?y refaktoryzowa?? A je?li nale?y, to 
>>czym si? kierowa? przy ustalaniu priorytetów (priorytetyzacj? stosuj?, 
>>bo nie mam du?o czasu)?
> 
> 
> Wie Pan, kod sie refaktoryzuje z roznych powodow, ale po to zeby
> zminimalizowac cyclomatic complexity, to pzrepraszam, ale oplulem kawa
> monitor...

Właśnie próbuję usystematyzować swoją (nie)wiedzę. Czy jest coś złego w 
tym, że minimalizuję CC?
Może Pan podrzucić jakiegoś linka do sensownego podejścia do refaktoryzacji.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

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"

A.L. <wonlewando@grzegzulka.com> writes:

> On Tue, 29 Nov 2005 18:15:29 +0100, pdemb@gazeta.pl 
> (Piotr Dembiñski) wrote:
>
>>A.L. <wonlewando@grzegzulka.com> writes:
>>
>>[...]
>>
>>> Zawracanie glowy... Macie duzo czasu, widac....
>>
>>Pomiary czasami siê przydaj±.
>
> Czyzby Pan Kolega juz nabral wystarczajacego doswiadczenia
> pzremyslowego zeby sie wypowiadac na temat "jak to sie powinno 
> robic w przemysle"?...

Ktoś kiedyś te metryki kodu wymyślił i to nie po to, żeby 
na p.c.objects ktoś jakiemuś Dembińskiemu wytykał brak 
doświadczenia w wytwarzaniu oprogramowania.

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

[...]

> Właśnie próbuję usystematyzować swoją (nie)wiedzę. Czy jest coś
> złego w tym, że minimalizuję CC?

CC jest fajne, ale ja bym poszukał jakichś metryk nakierowanych 
na obiektówkę: liczby metod/klasa, głębokości hierarchii 
dziedziczenia, linii kodu/metoda, linii kodu/klasa etc.

Ale to wszystko zależy od tego, jaki _cel_ jest do osiągnięcia.
Minimalizowanie CC nie jest zbyt dobrym celem samym w sobie.

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

Sektor van Skijlen napisał(a):
 > 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.

Też bym stawiał na cyklomatyczna, tylko że to chyba nic nie znaczy 
(przynajmniej nikt w rodzinie nie wiedział).

 >
 >
 >>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.
 >

Na szczęście mam co robić i nie potrzebuję podkładki. Po prostu 
metrykami kodu zająłem się w czasie poświęcanym na naukę, a nie na 
pracę. Być może nie jest to najważniejsza rzecz (czyli po prostu 
błądzę), ale nie stać mnie na pójście prywatnie na jakiś kurs 
ukierunkowujący mój rozwój. Dlatego pytam się o rady bardziej 
doświadczonych.

 > 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ę.
 >

A jak wyeliminować konieczność spoglądania przez wprawnego programistę 
na kod napisany przez ćwierćprogramistę (bo to kosztuje). Zapuścić 
toola, który to zrobi automatycznie.

 > 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

Jasne, tylko jak stwierdzić, czy programista ma już to pewne doświadczenie?

 > 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.
 >
No właśnie - wiele tych rzeczy można zautomatyzować metrykami.

 > 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).
 >
Mimo wszystko przed ustaleniem własnych wartości warto poszukać, czy 
ktoś inny nie opublikował swoich ustaleń.

Dzięki za komentarz

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Dnia Wed, 30 Nov 2005 10:19:26 +0100, Grzesiek G. skrobie:
>  > 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.

> Też bym stawiał na cyklomatyczna, tylko że to chyba nic nie znaczy 
> (przynajmniej nikt w rodzinie nie wiedział).

Ano to jest druga cecha tak adoptowanych określeń.

Niewiele osób w Polsce np. jest ci w stanie powiedziec, co to znaczy
"generyczny". A jest to jedyne sensowne tłumaczenie angielskiego "generic";
nie ma żadnego innego określenia w języku Polskim, które by pasowało jako
odpowiednik, a określenia, które spotykałem to pasowały do tego jak balon do
kaktusa.

Cyklomatyczna to - tak na moje oko - oznacza mniej więcej "opisana po okręgu".
Ale też nie wiem, na ile takie wyjaśnienie ma sens.

>  >>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.
>  >

> Na szczęście mam co robić i nie potrzebuję podkładki. Po prostu 
> metrykami kodu zająłem się w czasie poświęcanym na naukę, a nie na 
> pracę. Być może nie jest to najważniejsza rzecz (czyli po prostu 
> błądzę), ale nie stać mnie na pójście prywatnie na jakiś kurs 
> ukierunkowujący mój rozwój. Dlatego pytam się o rady bardziej 
> doświadczonych.

Nie no spoko ;)

Z tym to jest mniej więcej tak, jak z każdym toolem, również np. generatorami
kodu.

Albo, używając innego porównania: istnieje możliwość napisania absolutnie
doskonałego sprawdzacza ortografii, gramatyki i składni, możliwość sensownego
rozumienia zdań, również składania zdań ze strzępków informacji - ale chyba
nie powierzyłbyś maszynie napisania artykułu do gazety?

>  > 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ę.
>  >

> A jak wyeliminować konieczność spoglądania przez wprawnego programistę 
> na kod napisany przez ćwierćprogramistę (bo to kosztuje).

Kosztuje, owszem, ale robi się to, bo jak na razie jest to jedyny
najpewniejszy sposób na poprawę jakości oprogramowania. 

> Zapuścić toola, który to zrobi automatycznie.

To nie wyeliminuje problemu. Co więcej, tak naprawdę robi się jedno i drugie.
Tool pomoże ci tylko częściowo. I ma on pomóc na taką sytuację, gdyby w jakimś
zespole takiego sensownego programisty zabrakło, lub też nie miałby on wiele
do powiedzenia.

Jeśli mamy pewność, że taka sytuacja, jak powyżej, nie zajdzie, to ów tool
jest nam całkowicie zbędny.

>  > 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

> Jasne, tylko jak stwierdzić, czy programista ma już to pewne doświadczenie?

Ano właśnie. Co najgorsze, to doświadczenie nie jest mierzalne żadnymi
metrykami (a już zwłaszcza stosowanym przez rekruterów stażem pracy).

Teoretycznie najlepiej to by było mieć sensownych programistów, którzy by
oceniali innych programistów przed przyjęciem np. dając im takie zadanie:
dostaje się bardzo brzydki kod i trzeba go zrefaktorować wedle własnego
uznania (na zasadzie: przerób ten kod jak ci się podoba, tylko zadbaj o to,
żeby był zrozumiały i czytelny, oraz żeby można było go łatwo rozszerzać o
dodatkowe elementy).

I to wszystko byłoby pięknie, gdyby nie pewien problem: na jakiej podstawie
wyselekcjonować takich programistów, którzy by te wypociny oceniali, i kto
miałby to zrobić?

Inni programiści? To ich z kolei kto wybierze?

Management? Przecież oni nie odróżnią. A żeby odróżnić to potrzebne są
naprawdę wypasione umiejętności; zdolności organizacyjne, przykładanie się do
pracy, oddawanie "ładnie sformatowanego i obkomentowanego" kodu, posiadanie
jasno sprecyzowanego zdania nt. co jest czytelne, a co nie - to są wszystko
cechy całkowicie poprzeczne do umiejętności refaktorowania.

I niestety tu sprawa (mimo oczywistych różnic) jest bardzo podobna do
wybierania władzy w systemach demokratycznych. Również wspólne jest to, że
efekty widoczne są dopiero po dłuższym czasie, a związek sposobu tworzenia
oprogramowania z porażką lub sukcesem jego projektu ma się bardzo często jak
stąd do wieczności, albo jak postwienie jednej stopy siedem mil od drugiej.

>  > 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.
>  >
> No właśnie - wiele tych rzeczy można zautomatyzować metrykami.

Właśnie problem w tym, że niewiele.

>  > 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).
>  >
> Mimo wszystko przed ustaleniem własnych wartości warto poszukać, czy 
> ktoś inny nie opublikował swoich ustaleń.

Być może tak. Ja nie szukałem.

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

[...]

> Cyklomatyczna to - tak na moje oko - oznacza mniej więcej 
> "opisana po okręgu".

'złożoność zakręcona' ;)

witam,
poczytaj sobie to:
http://info.borland.com/techpubs/studio_java/studio_java1/tg_help/auditsmetrics/metric_def.html

Zauwaz, ze samo mierzenie kodu bez ich rozumienia i bez wyciagania
wniosków jest bez sensu.
CC jest metryka nieobiektowa - ALE - pozwala na wykrycie metod,
które slicznie dadza sie zrefaktoryzowac obiektowo - CC moze
wskazac metody, w  których jakis dewiant symulowal polimorfizm przy
pomocy np. setek if else tudziez switch/case. To sie da wyleczyc przy
pomocy techniki registration,  lub Visitor, albo null object - zalezy
od kontekstu.

pozdrawiam,
Belina.