🚀 go-pugleaf

Witam

A.L. wrote:

>>Jeszcze raz podkreślam, dobrzy programiści tego nie potrzebują. A nawet
>>więcej czasem taka czy inna metryka pokaże złą notę, a kod będzie dobry,
>>bo będzie jakiś szczególny.
>>
> 
> Nie ma metryk pokazujacych JAKOSC kodu.

Nie ma metryk będących równoważnikamni jakości kodu, ale są metryki
wskazujące na totalne badziewia.

Do tego jak programiści są złośliwi, to i tak metryka pokaze wynik dobry, a
kod będzie zły.

Ale jeśli metryka pokazuje fatalne wyniki, to warto zobaczyć, czy tak
wyszło, czy to jest zamierzone. To się nazywa implikacja, czyli wynikanie w
jedną stronę.

W pełni się zgadzam że ocena jakości kodu jest bardzo trudna.

> To co pokazuja, nic wspolnego 
> z JAKOSCIA nie ma. No, chyba ze pan ma wlasna defincje jakosci.

No więc właśnie co to jest jakość kodu?

Czy klasa mająca 500 metod jest dobrze napisana? Czy klasa mająca 300 pól
jest dobrze napisana? A może implikacje idą dalej, napisana jest dobrze ale
projekt jest fatalny? 
  
>>Zgadza się. Pozostaje tylko ufać programistom, że będą dobrze pisać kod.
>>Ja generalnie ufam chyba, że się sparzę na czyimś kodzie.
>>
> 
> Nie ufa sie, dlatego tez sa na przyklad "peer reviews"

Ufać w sensie, że nie zakazdym razem walcuje się kod każdej osoby toolami.
 
> Niech Pan ignoruje rozne takei "doneisienia". Ja mam taka mala
> ksiazeczke: "Never Confuse a Memo with Reality". Bardzo madra. Odnosi
> sie tez do "rewelacji" ze stron webowych roznych "gurus".

No i?
 
>>Jeszcze raz podkreślam. Są sytuacje kiedy albo trzeba jakimś wspólnym
>>językiem opisać jakość kodu, albo kiedy programistom w firmie nie zależy
>>na jakości kodu.
> 
> No to prosze o propozycje takiego "wspolnego jezyka opisujacego jakosc
> kodu". Oraz definicje owej "jakosci"

Nie ma takiego ogólnego pojęcia jakości! Metryki implikują pewne sprawy
tylko w jedną stronę i to tylko w postaci postawienia hipotezy wadliwości,
czyli pada sugestia, aby przyjrzeć się czemuś dokładnie.
 
>>Nieraz w firmach jest tak, że kiedy zbliża się release i
>>pojawiają sie jakieś bugi, to łata się je byle jak byle program działał, a
>>poprawki "faktyczne" z refaktoringiem włącznie zostawia się na później -
>>kiedy "będzie spokojniej". Co oczywiście nie jest żadnym standardem w
>>programowaniu ale tak się zdarza z rzeczonym przemyśle softwareowym.
> 
> Pan tak programuje?... No to ja nic nie poradze. Ale ejzeli firma dla
> ktorej Pan pracuje tak wlasnie programuje, to proponuje zmienic firme.

Nie podaję nazw firm, które tak robią, bo są duże firmy z USA, mające
placówki w PL - nie ma potrzeby pokazywać kto jest zły, lepiej pokazać kto
jest dobry.

A tak na marginesie ja tak, ani tam (w tych firmach), nie pracuję - dla mnie
release nie przychodzi co miesiąc, czy co rok nie mam takich sztucznych
inklinacji.
 
> P.S> Przykald kretynizmu: jakis tam tool powiedzial ze "implementacja
> metody jest za dluga". Wiec zdecydowano sie rozbic wszystkie metody
> ktore mialy wiecej niz X linii na podmetody tak aby kazda nei miala
> wiecej niz 50 linii.

Zgadza się. Tak to jest przykład kretynizmu. I właśnie dlatego mówię o
implikacji w jedną stronę i o przyglądaniu się programowi, a nie sztucznemu
przywiązywaniu wagi do cyferek.

> Poniewaz "podmetody" musialy miec dostep do 
> lokalnej informacji w "metodzie glownej", kazda "podmetoda" miala po
> 20 parametrow mniej wiecej. I nei mogla byc uzyta inaczej jak przez
> wolanie z "metody glownej".

A nie można było pogrupować parametrów w klasy?

> Konsultatnt wizal $$$$$ (pieciocyfrowa suma) za "poprawienie jakosci kodu"

No to jest przykład prawdziwego kretynizmu - zgadza się.

Pozdrawiam.

Ps. Większość kodu matematycznego daje straszne baty wszelakim metrykom, ale
właśnie dlatego trochę wiadomo, gdzie taki kod się znajduje.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/