On Oct 11, 11:50 pm, Edek <e...@g...com> wrote:
> On 10/11/2011 05:13 AM, Andrzej Jarzabek wrote:
>
> Podtrzymuję swoją tezę w ten sposób: jak się podzieli problem na
> mniejsze, to zna się wymagania małych fragmentów. Chociażby dlatego,
> że samemu się podzieliło problem tak, że ten fragment ma robić to i to.
> Raczej o takie wymagania mi chodziło, niż o wynegocjowany z klientem
> dokument.

Nie będę z tą rezą polemizował. POwtórzę tylko, że z tym wywalaniem
się programu to był skrót myślowy, a praktyki, o których pisałem,
odnoszą się nie tylko do problemów niezawodnościowych, ale też do
innych sytuacji, gdzie program robi nie to co powinien z powodu błędów
programisty.

> > [...]
> > I: jeśli ktoś jest programistą z jakąkolwiek praktyką, ale bez
> > znajomości dobrych praktyk, ale dla dostania pracy przeczyta wszystkie
> > te książki i przygotuje się do odpowiadania tak, jakby stosował je w
> > praktyce, to potencjalnie jest bardzo dobrym programistą i cennym
> > pracownikiem.
>
> Sam z siebie? Wyobraziłem sobie sytuację, gdy potencjalny pracodawca
> mówi mi, "wie pan, przeczytałby pan może tę książkę..". Nie wiem,
> czy dobrze odczytałbym intencje :)

Odnosiłem się do tekstu o "samym czytaniu książek". Jeśli ktoś nie
posiada w praktyce umiejętności z tych książek, ale w ramach
przygotowań do rozmowy o pracę przeczyta je, żeby wyjść na bardziej
kompetentnego niż jest w rzeczywistości, i w dodatku faktycznie uda mu
się na takiego w rozmowie wyjść, to raczej dobrze o nim świadczy jako
o potencjalnym pracowniku?

> > A właśnie: spotkałem się z opinią, do której się przychylam, że jeśli w
> > kodzie potrzeba wielu komentarzy, to wskazuje to na problem z jego
> > strukturą, że raczej należy starać się pisać kod tak, żeby komentarz nie
> > był potrzebny.
>
> Ja chyba nie znam reguły. Najbliższym przybliżeniem tego, co wymaga
> komentarzy, to rzeczy nie oczywiste. No bo dobry kod sam się
> komentuje, tak się czasami mówi, ja komentuję to, o czym sam
> mogę zapomnieć za pół roku, bo jest podchwytliwe, albo się opiera
> na jakiejś konstrukcji.

Ogólnie to jakby rozszerzenie tej zasady, że dobry kod komentuje się
sam. W bardziej radykalnej wersji można powiedzieć, że komentarze są
evil. Że czasem jest to zło konieczne, ale za każdym razem, kiedy
widzi się potrzebę skomentowania kodu, należy się zastanowić czy
zamiast tego nie da się lepiej wyrazić tego samego w kodzie. Powiedzmy
masz licznik czegośtam w postaci inta, który musi być podbijany z
kilku różnych wątków, więc dodajesz mutex i komentarz, że ten mutex
służy do zabezpieczania licznika, który jest podbijany z kilku wątków.
A może zamiast tego lepiej zrobić klasę i nazwać ją ThreadSafeCounter,
to komentarz przestanie być potrzebny.

> W ogóle lubię komentować konstrukcje,
> podziały, idee, oraz takie podchwytliwe rzeczy jak zależność
> od czegoś zupełnie gdzie indziej, no i API, które IDE wyświetla
> wraz właśnie z komentarzami, a jak nie to są w jednym miejscu.
> Zazwyczaj moje pojęcie o tym co jest oczywiste a co nie pokrywa
> się z grubsza z pojęciem innych; co nie znaczy, że nie mam na koncie
> kawałka kodu, o którym po tygodniu sam nie miałem zielonego pojęcia
> jak działa i spędziłem więcej czasu niż wtedy jak to pisałem nad
> rozszyfrowaniem dlaczego on faktycznie działa. To było oczywiście
> nie i +=1, tylko odrobina matematyki i logiki, nic specjalnego, ale
> wystarczyło. I tam wybitnie brakowało komentarza.

Nie będę odnosił się do twoich przykładów, bo ich nie znam. Ogólnie,
bynajmniej nie chodziło o to, że ten sam kod bez komentarza będzie
lepszy niż z komentarzem, tylko że kod, w którym "brakuje komentarza"
często lepiej przepisać tak, żeby tego komentarza nie brakowało, niż
dodać do niego komentarz. Czy też powiedzmy od razu starać się go
pisać tak, żeby komentarz nie był potrzebny.

Nie uważam, że to jest jakaś złota zasada czy srebrna kula, ale jednak
zauważyłem, że często tak faktycznie jest: mam do czynienia z funkcją,
w której bez komentarzy trudno byłoby rozkminić jakiś istotny aspekt,
dzięki komentarzom jest to możliwe, ale jednak jest możliwe i byłoby
lepiej, gdyby te aspekty były wprost wyrażone w kodzie.