🚀 go-pugleaf

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"