Andrzej Jarzabek wrote:

>> A podczas rekrutacji i tak nikt nie będzie w stanie tego ocenić, bo skąd
>> weźmie do zweryfikowania kod napisany przez kandydata, a będący
>> własnością firmy, z której kandydat odchodzi... więc raczej liczy się tu
>> dar przekonywania, wzmacniany przez doświadczenie w działce, którą akurat
>> rekrutujący sobie ceni.
>
> E tam, przecież pisanie kodu, który się nie wywala to przede wszystkim
> kwestia stosowania odpowiednich praktyk czy technik, o które jak
> najbardziej można wypytać. Sam kod jest zazwyczaj bezużyteczny do tego
> celu, bo jest wynikiem pracy kilku ludzi na przestrzeni jakiegośtam
> czasu.

Gdyby to było takie proste, że są do tego techniki, które można w pół
godziny omówić, to programista początkujący byłby w stanie robić tak samo
nie-wywalające się programy (a realizujące jakąś rzeczywistą
funkcjonalność), jak programista z doświadczeniem.

Tak samo zupełnie zbędne byłoby wypytywanie kandydata, czy te techniki zna,
bo po prostu w pierwszych dniach pracy dawałoby się mu broszurę informacyjną
na temat tych technik i problem rozwiązany.

do góry

On 06/10/2011 22:16, Wojciech Jaczewski wrote:
>
> Gdyby to było takie proste, że są do tego techniki, które można w pół
> godziny omówić, to programista początkujący byłby w stanie robić tak samo
> nie-wywalające się programy (a realizujące jakąś rzeczywistą
> funkcjonalność), jak programista z doświadczeniem.

Nie omówić. Wypytać. Oczywiście będzie to obarczone jakimś tam błędem,
ale raczej niewielkim.

> Tak samo zupełnie zbędne byłoby wypytywanie kandydata, czy te techniki zna,
> bo po prostu w pierwszych dniach pracy dawałoby się mu broszurę informacyjną
> na temat tych technik i problem rozwiązany.

Wiesz, jeśli ktoś twierdzi, że zna Pana Tadeusza na pamięć, to mając
przed sobą tekst (albo samemu znając na pamięć) będę w stanie bez
problemu w 5 minut zorientować się, czy mówi prawdę - co nie znaczy, że
w 5 minut można się Pana Tadeusza nauczyć na pamięć.

To jest oczywiście przykład skrajny, z programowaniem jest trudniej, ale
zasada jest ta sama. Weźmiesz takiego generała profesora i go spytasz o,
like, cokolwiek i już po 20 sekundach wiesz, że nic nie wie i nic nie
umie (chyba że zacznie narzekać na zdrowie, co na jedno wychodzi).

do góry

Andrzej Jarzabek <a...@g...com> napisał(a):

> On 06/10/2011 22:16, Wojciech Jaczewski wrote:
> >
> > Gdyby to było takie proste, że są do tego techniki, które można w pół
> > godziny omówić, to programista początkujący byłby w stanie robić tak sa
> mo
> > nie-wywalające się programy (a realizujące jakąś rzeczywistą
> > funkcjonalność), jak programista z doświadczeniem.
>
> Nie omówić. Wypytać. Oczywiście będzie to obarczone jakimś tam błędem,
> ale raczej niewielkim.
>
> > Tak samo zupełnie zbędne byłoby wypytywanie kandydata, czy te techniki
zna
> ,
> > bo po prostu w pierwszych dniach pracy dawałoby się mu broszurę
informacyj
> ną
> > na temat tych technik i problem rozwiązany.
>
> Wiesz, jeśli ktoś twierdzi, że zna Pana Tadeusza na pamięć, to mając
> przed sobą tekst (albo samemu znając na pamięć) będę w stanie bez
> problemu w 5 minut zorientować się, czy mówi prawdę - co nie znaczy, że
> w 5 minut można się Pana Tadeusza nauczyć na pamięć.
>
> To jest oczywiście przykład skrajny, z programowaniem jest trudniej, ale
> zasada jest ta sama. Weźmiesz takiego generała profesora i go spytasz o,
> like, cokolwiek i juĹź po 20 sekundach wiesz, Ĺźe nic nie wie i nic nie
> umie (chyba że zacznie narzekać na zdrowie, co na jedno wychodzi).
>

jestem w kiepskiej formie, ciagle napieprzaja mnie kosci i serce
(z winy konowałow nie musze dodawac), [[ a do tego kolejny konowal
(ja to mam pecha) dentysta partacz (mimo ze powtarzalem mu
zeby nie rozwiercal n razy ) porozwiercal mi partacko
zeba dowiercil sie jak nie powinien do korzenia i uszkodzil
mi przedni zab ]] retrybucja u diabła!







--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

> retrybucja u diabła!
>

http://www.youtube.com/watch?v=6mKtt7F0rPU


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Andrzej Jarzabek wrote:

>> Gdyby to było takie proste, że są do tego techniki, które można w pół
>> godziny omówić, to programista początkujący byłby w stanie robić tak samo
>> nie-wywalające się programy (a realizujące jakąś rzeczywistą
>> funkcjonalność), jak programista z doświadczeniem.
>
> 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ł.
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.

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

do góry

jeszcze moze dodam zeby nie bylo ze sobie 'przykadzam':
uwazam sie za programiste wzglednie cienkiego (z braku
oblatania i doswiadczenia) ale i tez wzglednie oryginalnego
(nie mam wbudowanego poczucia oryginalnosci ale widze to
jakby na zewnatrz, chocby po tym ze ludzie mniej niz ja
lapia o co chodzi w c ) Co jednak najgorsze rok temu
myslalem jakby znacznie glebiej i moja glowa byla
bardziej sklonna do lapania jakichs fajnych glebszych
spostrzezen; :-/




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

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.

do góry

> jakości pierwotnego kodu. Niby jest to oczywiste, ale myślę, że niejeden
> profesor kenobi by się przejechał na tym punkcie jak nic.

jesli za poprzedni programista wziac 'programisci winapi'
albi 'programisci iosa' albo najprawdopodobniej cokolwiek innego
(jakis spory program ktory mailbym nadbudowywac) to przypuszczam
ze tak jest /tj do pewnego czasu az grunt zostanie opanowany
liczonego pewnie w tygodniach lub dluzej/- i to wlasnie nazywam
'wysypkami na systemie' (mniej tu chodzi o same wysypki a
bardziej o optymalne rozwiazania i nie kluczenie)
- dlatego mowie ze pisanie bezblednych i szybkich progsow
na jednym nie rowna sie od razu pisaniu takich na drugim
o ile systemy do opanowania nie sa podobne albo bardzo
proste;

co do rekrutacji to ja jestem zwolennikiem normalnego
zatrudniania na 3 mce, popieram wszelkie pomoce pracodawcow
z mieszkaniem ew zaliczkami, swobodnymi godzinami pracy,
wyskokami na obiad i wolnymi dniami itd - jest w zyciu cos
takiego jak zasada wzajemnosci jesli ktos jest uparcie w
porzadku wg ciebie to trudno sie obrazic; ostatnio trafilem
na jedna firme ktora wprost oszukiwala - nie popieram takich
praktyk







--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Oct 10, 6:58 am, " " <f...@g...SKASUJ-TO.pl> wrote:
> > jakości pierwotnego kodu. Niby jest to oczywiste, ale myślę, że niejeden
> > profesor kenobi by się przejechał na tym punkcie jak nic.
>
> jesli za poprzedni programista wziac 'programisci winapi'
> albi 'programisci iosa' albo najprawdopodobniej cokolwiek innego
> (jakis spory program ktory mailbym nadbudowywac) to przypuszczam
> ze tak jest

Nie zrozumiałeś. Poprzedni programista to ty, a nadbudowywać miałby
ktoś inny.

do góry

Andrzej Jarzabek <a...@g...com> napisał(a):

> On Oct 10, 6:58=A0am, " " <f...@g...SKASUJ-TO.pl> wrote:
> > > jako=B6ci pierwotnego kodu. Niby jest to oczywiste, ale my=B6l=EA, =BFe=
> niejeden
> > > profesor kenobi by si=EA przejecha=B3 na tym punkcie jak nic.
> >
> > jesli za poprzedni programista wziac 'programisci winapi'
> > albi 'programisci iosa' albo najprawdopodobniej cokolwiek innego
> > (jakis spory program ktory mailbym nadbudowywac) to przypuszczam
> > ze tak jest
>
> Nie zrozumia=B3e=B6. Poprzedni programista to ty, a nadbudowywa=E6 mia=B3by
> kto=B6 inny.

robota tego programisty zalezy od tego programisty, co do
kodu to poki nie poznam platformy to ten kod nie jest za
specjalny ... dopiero z czasem sie poprawia, takie rzeczy sa
bardzo niejednoznaczne, np znalem jednego bardzo
poczatkujacego programiste ktory prawie nic nie wiedzial
tworzyl niesamowicie czytelny kod, innego ktory potrafil
podobno napisac kilkadziesiat ladnych aplikacji rocznie
ale jego kod MI SIE NIE PODOBAL (jakis bezosobowy nieczytelny
itd)



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry