On 10/10/2011 05:57 AM, Andrzej Jarzabek wrote:
> On 09/10/2011 19:52, Wojciech Jaczewski wrote:
>> Andrzej Jarzabek wrote:
>>
>>> Nie omówić. Wypytać. Oczywiście będzie to obarczone jakimś tam błędem,
>>> ale raczej niewielkim.
>>
>> Zaintrygowała mnie ta odpowiedź.
>>
>> Uważam, że mi od jakiegoś czasu udaje się tworzyć nie-wywalające się
>> programy - oczywiście przy pierwszych uruchomieniach czasem się i wywalą,
>> ale po poprawieniu działają już dobrze. Dużo trudniej jest doprowadzić do
>> tego, aby każdy szczegół działał zgodnie z wymaganiami, niż do tego aby
>> program się nie wywalał.
>
> 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.

>
>> Jednak jedyne co mógłbym powiedzieć o "technice", jak to robię jest:
>> robić
>> najprościej jak się da i realizować wyłącznie tę funkcjonalność, która
>> jest
>> wymagana. Taka odpowiedź miałaby jednak taką wadę, że do takiej
>> odpowiedzi
>> każdy, niezależnie od doświadczenia i umiejętności, mógłby przygotować
>> się w
>> minutę, a jednocześnie: to co jeden uważa za program prosty, dla drugiego
>> może być programem bałaganiarskim.
>
> No ale jeśli kandydat powie coś takiego na rozmowie, to oczywistym jest
> kolejne pytanie, co konkretnie robi, żeby jego kod był prosty. Zeby
> podał jakieś konkretne przykłady ze swojej praktyki na przykład, albo
> odpowiedział na pytanie - jeśli funkcja ma realizować skomplikowaną
> działalność, jak ją napisać, żeby była prosta. Dwie do pięciu minut na
> odpowiedź dużo ci powie.

Dodam:
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,
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.

>
>> Jeśli możesz, to przedstaw, jakie wg Ciebie techniki się wykorzystuje
>> podczas robienia nie-wywalających się programów (wystarczy mi odnośnik do
>> jakiegoś tekstu). Powinny spełniać następujące kryteria:
>> - pomagać w osiągnięciu celu
>> - być czasochłonne w nauczeniu się (bo gdyby dało się jej nauczyć w
>> dzień-
>> dwa, to nie byłoby sensu selekcjonować kandydatów wg kryterium znajomości
>> tej techniki).
>> - ma być trudno o nich opowiadać, jeśli samemu nie umie się ich
>> wykorzystać.
>
> 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. 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ść.

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
ma garbage collection to unikanie leaków, jeżeli jest też,
testy, czytelność kodu, enkapsulacja, dzielenie problemu na mniejsze,
dbałość o odpowiednie sygnalizowanie błędów (nie BSOD ani "Exception:
Error Occured"), złożoność algorytmiczna (żeby test z 10 elementami
nie zajął 1/1000 tego co ze 100 elementami), komentowanie kodu,
nie robienie różnego rodzaju głupot (wbrew pozorom pewien problem
czasami, nie mówię o błędach), wzorce projektowe, o ile ktoś wie
jak ich używać (swoją drogą w C++ mówi się raczej o idioms),
RTFM jeżeli używa się funkcji systemowych i/lub bibliotek,
jak ktoś się bierze się za wątki, to musi mieć wyobraźnię
i znać zasady, umiejętność korzystania z języka w tym
z kompilatora i innych narzędzi, również
w celu unikania błędów - każdy język ma swoją specyfikę, na
przykład jeżeli chodzi o nie zainicjalizowane zmienne, type
safety, ostrzeżenia kompilatora, na czym można polegać,
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ć.

Do tego każda dziedzina, w tym język, ma swoją specyfikę,
o którą można zapytać.

>
> W ogóle to można jeszcze zwrócić uwagę na istotny aspekt całej sprawy: w
> pisaniu programów, które się nie wywalają, samo to, że napiszesz program
> i on się nie wywala to jest tylko wierzchołek góry lodowej. Bardzo
> istotne jest również to, żeby program napisany przez ciebie nie wywalił
> się jak inny programista zacznie wprowadzać w nim zmiany, być może długo
> po tym i być może nie mając do ciebie dostępu i nie mogąc cię spytać
> dlaczego jest tak a nie inaczej. Oczywiście nie da się napisać programu
> tak, żeby inny programista nie mógł wprowadzić do niego błędów, ale też
> 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 ;)

Edek