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ń.

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

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

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.