On 10/11/2011 05:13 AM, Andrzej Jarzabek wrote:
> On 10/10/2011 19:08, Edek wrote:
>> On 10/10/2011 05:57 AM, Andrzej Jarzabek wrote:
>>>
>>> Zgodzę się, że to jest trudniejszy problem, ale to nie jest tylko
>>> kwestia umiejętności programisty. Zresztą samo "wywalanie się" to był
>>> skrót myślowy, możemy sobie rozszerzyć czy dodefionować pojęcie na
>>> nieprawidłowe działanie programu wynikające z błędu programistycznego, w
>>> przeciwieństwie do błędnego czy niedostatecznego sformułowania lub nie
>>> do końca zrozumienia wymagań.
>>
>> Skrajne podejście do sprawy: pisanie kodu to spełnienie wszystkich
>> ograniczeń, z czego jednym z ograniczeń są wymagania. To eksperyment
>> myślowy, ale też prawda.
>
> Mówiliśmy o tym, co należy do kompetencji programisty. Programista nie
> musi i zwykle nie będzie znał wszystkich wymagań, a w praktyce raczej
> rzadko się zdarza, żeby była specyfikacja wymagań, która jest kompletna,
> bezbłędna i jednoznaczna. Oczywiście sztka robienia programu tak, żeby
> był zgodny ze wszytkimi wymaganiami jest też istotna, ale rola
> programisty w tym wszystkim zależy od różnych rzeczy, na przykład od
> procesu, poza tym jest to proces iteracyjny, gdzie w danej kolejnej
> iteracji zazwyczaj się pisze program mniej lub bardziej nie spełniający
> wymagań itd. itd., to jest temat rzeka.

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.


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

[...]
>> [...] komentowanie kodu,
>
> 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. 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.

Edek