🚀 go-pugleaf

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