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.

Ja akurat pisałem o aspekcie niezawodności, bo on jest ściśle związany z
umiejętnościami programisty, a z drugiej mowa o dziedzinach, gdzie
często niezawodność ma duże znaczenie.

> Podziwiam ludzi, którzy mówią o prostocie i zawsze się zastanawiam,
> czy rozumieją. Każdy problem ma wiele błędnych ale prostych rozwiązań,
> w wielu dziedzinach przybliżony wynik nie spełnia wymagań. W zasadzie
> zgodnie z zasadą prostoty nie powinien istnieć skomplikowany kod,

Każde rozwiązanie ma też wiele sposobów wyrażenia, które mogą być
prostsze lub mniej proste (w zasadzie jeśli w tym kontekście ma być
jakieś przeciwieństwo prostego, to raczej lepiej niż "skomplikowane"
wyraża o co chodzi określenie "zagmatwane").

> a z empirycznych, moich przynajmniej, doświadczeń ze światem kod
> skomplikowany istnieje i ma się dobrze, a co najważniejsze działa
> i swięcie wierzę w to, że autorzy co jak co ale uprościli go ile
> się da i dalej się nie da.
>
> Dla mnie każdy, kto zaczyna od tekstu keep it simple jest lekko
> podejrzany. Co nie znaczy, że do wielu zadań się nie nadaje i że
> ja sam komplikuję sprawy bez powodu.

Powiem tak: pisanie kodu robiącego skomplikowane rzeczy tak, żeby był
prosty jest trudne i jest jedną z najważniejszych umiejętności
programisty. Niestety również jest to rzecz, którą ciężko sprawdzić u
kandydata na rozmowie.

Poza tym rzeczywiście samo pojęcie "prostoty" jest problematyczne -
czasem lepszy projekt wymaga np. dodatkowych klas, interfejsów, relacji
czy czego tam i intuicyjnie wcale nie można określić go jako "prostszy".

>> Jest sporo takich technik, i o ile jest kilka w miarę uniwersalnych
>> (abstrakcja, czytelność, w tym ograniczenie długości funkcji, code
>> reuse, unit testing), to sporo jest zależnych od technologii (MT, OO,
>> exception safety, konkretny język programowania). Co do tekstu, no to
>> jest sporo książek traktujących o tych tematach, od ogólnych typu "Code
>> Complete" Steve'a McConnella, "Refactoring" Martina Fowlera et al. Jeśli
>> chodzi o C++ to np. "Effective C++" Scotta Meyersa itd.
>
> ...ale i tak wszystkie to gówno, jeżeli ktoś tylko przeczytał te
> książki.

Zgadza się. Co więcej, można nie przeczytać wcale tych książek, a
wszystkie te rzeczy mieć opanowane. Ale przedpiśca chciał mieć namiary
na teksty, to ma.

A jeśli chodzi o sedno sprawy, to chociaż tych książek nie da się
przeczytać w pół dnia, to wydaje mi się, że nie będzie strasznie
problematyczne wyczajenie na rozmowie kwalifikacyjnej, czy ktoś te
książki "tylko przeczytał", czy zna problemy z praktyki.

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.

> Znam sporo osób, które przynajmniej jedną z powyższych
> zasad dość świadomie olewają, a to co piszą jest łatwe w rozszerzaniu,
> debugowaniu, utrzymaniu itd. Jest coś ze słowa "Art" w Programming,
> chyba nie chodzi o kreatywność.

Czemu nie, nikt nie twierdzi przecież, że wszystkie praktyki i techniki
powinny być zawsze i wszędzie stosowane.

> Techiniki, jest ich dużo: exception safety,
> w tym nie zostawianie otwartych plików, sprawdzanie różnych
> rzeczy w kodzie (inwarianty, proste null checki), jeżeli nie

Też w tym temacie: kiedy stosować assert.

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

> a na czym nie itd. itp., nie wiem czy cześciej nie jest problemem
> to, że ludzie padają na sprawach banalnych, niż na braku znajomości
> wyrafinowanych reguł, a o drobiazgi "wolno" pytać.

Ale też często padnięcie na sprawie banalnej jest wynikiem nie
zastosowania wcześniej wyrafinowanej reguły.

>> prawdopodobieństwo wprowadzenia później błędów jest mocno uzależnione od
>> jakości pierwotnego kodu. Niby jest to oczywiste, ale myślę, że niejeden
>> profesor kenobi by się przejechał na tym punkcie jak nic.
>
> W konkursach nie to jest najważniejsze ;)

Racja. W konkursach jest najważniejsze, żeby wypić litr piwa w sześć sekund.