Testy co to takiego?

Programiści bardzo często wydłużają sobie męskość wyzywając innych od idiotów i podając swój lepszy, krótszy i szybszy (ale niedziałający) kod [diabel]

No ja przepraszam bardzo, sam poszukaj to się przekonasz.

A ja zgadzam się z Jeffem Atwoodem i twierdzę, że wszyscy piszemy lipny kod. Ja na pewno. Nie żebym nie interesował się wzorcami projektowymi, testami, czy refaktoryzacją -- tak naprawdę jakość kodu (nie szybkość, jakość) to taki mój "konik". I z tą jakością nigdy nie udaje mi się tak dobrze, jakbym chciał. Mój kod jest "lipny" (no może przesadzam, ale po prostu nie jest wystarczająco dobry), ale to, że ja się do tego przyznaję, nie oznaczy, że i tak nie jestem lepszy od Ciebie :P ;).

Mimo dziesiątek tysięcy linii kodu doświadczenia, przeczytania raczej wielu książek i materiałów, wciąż robię kretyńskie błędy. I jestem przekonany, że większość osób tak ma.

FizzBuzz? Proszę bardzo, co mi szkodzi się skompromitować...

PHP. Nie pisałem w PHP od paru dni. Czy się udało za pierwszym razem? Nie.

W tych paru linijkach popełniłem dwa błędy:

1. Napisałem "$ i" zamiast "$i". Mogę się jedynie tłumaczyć, że nie chciało mi się odpalać serwera PHP, więc wklepywałem kod w pole w przeglądarce bez kolorowania składni.
2. Pętlę zrobiłem od 0 do 99 ($i < 100). Nie wiem, czy napisałem to odruchowo (zawsze piszę $i < n, a nie $i <= n, no i liczę od zera), czy nie doczytałem treści zadania.

Tak czy siak, dodatkowy czas spędzony na nauce algorytmów i tak by mi nic nie dał -- te i tak bym mógł zrobić. Może jestem beznadziejnym przypadkiem.

C++ w tym samym serwisie. W C++ nie kompilowałem niczego już dość długo. Chciałem być fajny i zrobiłem sobie zmienną pomocniczą typu std::string, którą dopiero na końcu chciałem coutować. To miało mi pomóc utrzymać zasadę DRY -- nie chciałem ani liczyć dwa razy, ani mieć dwa razy w programie ciągu "Fizz" czy "Buzz". Jakież było moje zdziwienie gdy okazało się, że "str += i" nie działa tak jakbym chciał ;).

Czasu w obu przypadkach nie mierzyłem, ale było to w granicach 3-5 min. Czekajcie, sprawdzę w JavaScripcie, w którym pisałem przez ostatnie dni, tym razem w normalnym edytorze.

Tu poszło szybciej. Obyło się bez błędów składniowych, ale nie bez zgrzytów. Napisałem odruchowo for (var i = 0; ...), ale skapnąłem się jeszcze przed odpaleniem programu. Okazało się jednak, że zapomniałem dodać separatorów i zrobiłem bezsensowne wyrażenia warunkowe, tj. nie if (i % 3 === 0), tylko if (i % 3). Nie wiem, nie pytajcie (i tak, poprzednie 2 razy godzinę temu zrobiłem te warunki dobrze).

Także IMO nie przejmujcie się, jeśli coś Wam nie wyjdzie od razu. Mimo że piszę lipny kod, to jednak uważam się za kompetentnego (i jakże skromnego!) kodera przynajmniej w tym JavaScripcie. A i tak zrobiłem tam parę głupich błędów. Choć może ja mam taką metodę, że najpierw myślę nad tym, jak coś zrobić, potem szybko to robię i nawet nie ogarniam kodu w poszukiwaniu oczywistych błędów, tylko sru -- kompilator/interpreter i jak coś wyjdzie, to poprawiam.

Nie jest to chyba specjalnym problemem, bo w JS zajęło mi to wszystko niecałe 2 min. Co więcej, wydaje mi się, że jak już się człowiek wczuje i klepie duże ilości kodu w ciągu, to literówek jest jakby mniej. Zawsze się zastanawiałem, czy kiedyś przestanę je robić -- po 200 000 LOC? Po milionie? Ale doszedłem do wniosku, że najbardziej prawdopodobna odpowiedź to: nigdy.

Dlatego tak pomocne są testy (jednostkowe/blokowe i inne). Nawet jak tu na forum pomagam przy prostym wyrażeniu regularnym, to przeważnie przepuszczę je przez chociaż prosty, automatyczny test. No i refaktoryzacja. Bez niej to dopiero mój kod by był g*****.

edit: Zrobiłem jeszcze w C z zegarkiem w ręku. Tym razem dla odmiany przejrzałem kod, znajdując i naprawiając jednego buga jeszcze przed uruchomieniem. Trwało to 2 min 12 sekund, czyli niby szybko, ale był to już czwarty język z rzędu, a algorytm wciąż prawie ten sam (choć zauważyłem, że zmieniam go odrobinę w zależności od języka).

Tak sobie myślę że te testy buzz to jednak porażka. Człowiek się stresuje bo skupia się na tej jednej rzeczy , a gdy to samo robi setki razy w programie to nawet nie zwraca na to uwagi. Tak samo jak z piłką nożną jeśli się zaczniesz zastanawiać jak ją kopnąć to na pewno ci się nie uda, albo z językiem obcym mówisz bo potrafisz a kiedy zaczynasz się zastanawiać nad gramatyką nagle wszystko się wali.

Ja natomiast zauważyłem że programiści dzielą się na 2 grupy , koderów i bardziej projektantów którzy jednak kodują . Ci pierwszy tworzą zawsze taki sam kod na wyuczonych założeniach przeważnie bardzo szybko , bazując na doświadczeniu . Zapamiętują jakiś algorytm i go po prostu aplikują bez stresu. Druga grupa natomiast wpierw zawsze zastanawia się nad projektem ... nawet jeśli to tylko algorytm tak jak napisał tutaj bswierczynski .

Ja natomiast zauważyłem że programiści dzielą się na 2 grupy , koderów i bardziej projektantów którzy jednak kodują . Ci pierwszy tworzą zawsze taki sam kod na wyuczonych założeniach przeważnie bardzo szybko , bazując na doświadczeniu . Zapamiętują jakiś algorytm i go po prostu aplikują bez stresu. Druga grupa natomiast wpierw zawsze zastanawia się nad projektem ... nawet jeśli to tylko algorytm tak jak napisał tutaj bswierczynski .

Moim zdaniem pierwsza grupa zna dobrze język i sobie swobodnie w nim radzi, natomiast druga zna ogólnie zasady programowania, jednak zdarzają jej się błędy techniczne.

Natomiast dzielenie kto kombinuje kto nie - samo kombinowanie nad zagadnieniem jest swego rodzaju projektowaniem rozwiązania, tyle że różnica jest w tym, że jeden skupi się na świetnym zakodowaniu gotowego algorytmu - i chwała mu za to, bo dzęiki temu kod jest często dosyć elegancki, i zaimplementowany w możliwie najlepszy sposób (lub też po prostu dobry bo nie ma ideałów), natomiast drugi będzie myślał o rozwiązywaniu konkretnych zagadnień, implementacje zrzucając na bok, często pisząc ją na siłę lub dając koderowi, koncentrując się na rozwiązaniu zadania. Oczywiście pewnie są i tacy i tacy, jednak to takie ogólne moje spojrzenie na temat ; )

Sorry za lekki OT.
Ktoś tu podrzucił link do http://devpytania.pl/. Na dole w stopce jest napisane: "Copyright © 2010 devPytania.pl". Po kliknięciu linku myślałem, że przeniosło mnie po prostu na http://stackoverflow.com/.

Czy to jest jakiś darmowy system do stawiania takiego serwisu? Czy może ktoś coś sobie skopiował. Albo oba serwisy mają tego samego właściciela? Strony są IDENTYCZNE.

Moim zdaniem pierwsza grupa zna dobrze język i sobie swobodnie w nim radzi, natomiast druga zna ogólnie zasady programowania, jednak zdarzają jej się błędy techniczne.

Ja nie piszę że któraś grupa jest lepsza bądź gorsza , pisze tylko moją obserwację.

Drogie dzieci, znajomość języka a programowanie to dwie całkowicie różne rzeczy...

tylko pytam napisał(a)

Sorry za lekki OT.
Ktoś tu podrzucił link do http://devpytania.pl/. Na dole w stopce jest napisane: "Copyright © 2010 devPytania.pl". Po kliknięciu linku myślałem, że przeniosło mnie po prostu na http://stackoverflow.com/.

Czy to jest jakiś darmowy system do stawiania takiego serwisu? Czy może ktoś coś sobie skopiował. Albo oba serwisy mają tego samego właściciela? Strony są IDENTYCZNE.

Nie robmy tu Off-topa. Oni sprzedaja swoj system obslugi.

deus. napisał(a)

Drogie dzieci, znajomość języka a programowanie to dwie całkowicie różne rzeczy...

Jeśli chodzi Ci o to, że zasady pisania programów w danym języku (tj. jego syntaktyka plus biblioteka standardowa) to jedno, a ogólne zasady programowania to drugie -- to zgadzam się w zupełności.

W ogólnych zasadach programowania fajne jest to, że jak już się człowiek którejś nauczy, to może ją stosować w prawie wszystkich poznanych językach. Co więcej, znajomość tych ogólnych zasad (podobnie jak znajomość konkretnych języków) pomaga uczyć się nowych języków. Weź np. kogoś, kto zna zasady programowania obiektowego i w ogóle tworzenia kodu wysokiej jakości i potrafi tworzyć/stosować różne algorytmy przenieś z Javy do C# (+.NET). Fakt, biblioteka standardowa C# jest zupełnie inna i rozległa, ale pomyśl po jakim czasie ten ktoś będzie mógł w C# pisać kod na poziomie. A jakim czasie pisałby taki kod koleś, który w C# robił już od dawna, ale nie wie co to wzorzec projektowy, a kod pisze czasami metodą CTRL+C CTRL+V.

Nie wszystkie ogólne zasady dotyczą jednak wszystkich języków. Np. silna czy słaba typizacja. Trzeba po prostu popisać w języku, który ma jedno czy drugie, by to obczaić (niby łatwo jest przejść z silnej do słabej typizacji, ale z drugiej strony nagle kompilator wyłapuje mniej błędów... teoretycznie). Albo programowanie funkcyjne. Przy przejściu z prawie każdego popularnego języka do JavaScriptu trzeba się go nauczyć. Z drugiej strony ja to w pełni zrozumiałem dopiero w... OCamlu. Chwila programowania w tym języku pozwoliła spojrzeć na to inaczej.

Moim zdaniem ważniejsza jest ogólna umiejętność programowania niż znajomość konkretnego języka. Wydaje mi się, że jakbym miał zacząć klepać kod w Rubym -- w którym praktycznie nigdy nie pisałem -- to po miesiącu by mi to jako-tako szło, szczególnie gdyby ktoś od czasu do czasu przejrzał mój kod i wytykał głupie niesprawności.

Z drugiej strony mam tak, że gdy piszę dłużej w jakimś języku to robię wszystko, by go poznać. Włącznie z pewnymi szczegółami działania kompilatora/interpretera tego języka. Często zajrzę sobie nawet do formalnego opisu składni tego języka. Gdy żadna konstrukcja nie może Cię zaskoczyć i gdy każdą możesz rozłożyć na czynniki pierwsze, to piszesz po prostu efektywniejszy kod. I szybciej rozumiesz kod innych.

Skoro ostatnio robię głównie front-end webdevelopment, to zadbałem o to, by poznać reguły parsowania HTML-a i CSS (włącznie z tym co się dzieje, gdy parser zobaczy błąd -- co zignoruje? czego nie?), przejrzeć wszystkie tagi i własności, a mieć w pamięci większość. Tak samo w JavaScripcie nie ma już chyba konstrukcji, która by mnie zaskoczyła. Mimo to w ciągu paru ostatnich miesięcy kupiłem parę książek i niech no policzę, ile ostatnich książek (pod rząd) NIE było o konkretnym języku czy technologii, tylko ogólnych zasadach... 4 albo nawet 5, bo jedna ma niby w tytule "JUnit", ale tak naprawdę jest ogólnym źródłem na temat testów jednostkowych.

Mam nadzieję, że to nie zostanie uznane za offtop, bo jednak są to przemyślenia dotyczące oceny umiejętności zatrudnianego programisty. Analizując napisany podczas testów kod oraz rozmawiając z rekrutowanym można odczytać sposób jego myślenia i ogólne umiejętności programowania. A nie tylko te w konkretnym języku.

W Stanach na przesłuchaniu w pewnej firmie 5 niezależnych ludzi mnie na spytki wzięło jeden po drugim. Każdy od czegoś innego.

Jeden od strony wizualnej, kazał mi narysować "jakiś ostatni projekt", a że wtedy trochę uczestniczyłem w tworzeniu nowego 4p, to narysowałem naszą stronę główną i omówiłem jego części.. dlaczego tu box, dlaczego tam menu.. jakbym sprzedawał produkt, całkiem ciekawe doświadczenie to było :)

Inny dał mi kartkę i kazał napisać w dowolnym (pseudo)języku funkcję odwracającą wyraz (abc -> cba), a potem wykorzystać tę funkcję do odwrócenia szyku wyrazów w zdaniu (ala ma kota -> kota ma ala) - taki test jak sobie radzę z wykorzystaniem już istniejącego kodu (przekształcenie w dwóch przejściach przez string).

A w Polsce.. raczej pytali co ostatnio zrobiłem, nie było żadnych wnikliwych pytań testowych.. może jakieś takie prostsze, których już nie pamiętam.

[edited]
ok, jak wszyscy to wszyscy ;-)

http://www.w3schools.com/quiztest/quiztest.asp?qtest=SQL napisał(a)

Result:
20 of 20

100%

Perfect!!!

Time Spent
5:05

bswierczynski napisał(a)

Mam nadzieję, że to nie zostanie uznane za offtop

Nie martw się, nikt nie czyta :P

20/20
czas 3:27
W tle leciało Creeping Death z LS:B&P.

SQL skończyło się na Kill'em All.

deus. napisał(a)

SQL skończyło się na Kill'em All.
true, true

... a pozniej to tylko komercja.

ja równe 4:00 :P

95% w 5:47, w tle leciało codzienne poranne karaoke sąsiada.

Demonical Monk napisał(a)

95% w 5:47, w tle leciało codzienne poranne karaoke sąsiada.

Nagrałeś je sobie i o północy dla przyjemności odtwarzasz ;> ?

Cześć.
Widzę,że temat się wydłużył.

Ja dodam moje 3 grosze:

Moim zdaniem testy u pracodawcy są bez sensu.
Po pierwsze określenie "Test z javy" może oznaczać albo test ze springa, hibernate'a, Strutsa, ale tego nie wiesz, bo sie przygotowałeś na jave, jak idziesz następnym razem, to pytają, czy klasa wewnętrzna zdefiniowana w metodzie niestetycznej musi mieć static, ok to powienienm wiedzieć, w końcu od roku mam SCJP, ale nawet w książce do SCJP jest napisane ŻE TAK SIĘ NIE PISZE OPROGRAMOWANIA, więc nie wiem, co te testy mają na celu.

Natomiast prawdziwie dobrym testem dla mnie jest zadanie domowe, polegające na napisaniu określonego programu w określonej technologii, wiadomo, że nikt nie pamięta wszystkiego, często sięga się po pomoc z google, jeśli kandydat w tydzień zrobi program, to ok, jeśli nie, to znaczy, że nawet z google'a nie umie korzystać i wtedy się go nie przyjmuje.

Pozdrawiam.

Ja miałem ciekawy test w jednej firmie. 0 pytań o język. Najpierw tylko rozmowa o poprzednim projekcie potem małe zadanie algorytmiczne (wyszukiwanie cyklów w zdegenerowanej liście).
Do domu dostałem kod do zrefaktoryzowania i skomentowania.

Black007 napisał(a)

Moim zdaniem testy u pracodawcy są bez sensu.
Po pierwsze określenie "Test z javy" może oznaczać albo test ze springa, hibernate'a, Strutsa, ale tego nie wiesz, bo sie przygotowałeś na jave, jak idziesz następnym razem, to pytają, czy klasa wewnętrzna zdefiniowana w metodzie niestetycznej musi mieć static, ok to powienienm wiedzieć, w końcu od roku mam SCJP, ale nawet w książce do SCJP jest napisane ŻE TAK SIĘ NIE PISZE OPROGRAMOWANIA, więc nie wiem, co te testy mają na celu.

sam jestes bez sensu, testy sa tak banalne ze malpa ktora przeczytala najglupsza ksiazke o danym jezyku/technologi jest w stanie to zrobic, a i tak wiekszosc ludzi na tym sie wyklada :P

Black007 napisał(a)

Natomiast prawdziwie dobrym testem dla mnie jest zadanie domowe, polegające na napisaniu określonego programu w określonej technologii, wiadomo, że nikt nie pamięta wszystkiego, często sięga się po pomoc z google, jeśli kandydat w tydzień zrobi program, to ok, jeśli nie, to znaczy, że nawet z google'a nie umie korzystać i wtedy się go nie przyjmuje.

dlatego niektore firmy, najpierw daja zadanie, pozniej zapraszaja na test a dopiero na koncu jest rozmowa o konkretach :P

Black007 napisał(a)

Natomiast prawdziwie dobrym testem dla mnie jest zadanie domowe, polegające na napisaniu określonego programu w określonej technologii, wiadomo, że nikt nie pamięta wszystkiego, często sięga się po pomoc z google, jeśli kandydat w tydzień zrobi program, to ok, jeśli nie, to znaczy, że nawet z google'a nie umie korzystać i wtedy się go nie przyjmuje.

Z zadaniem domowym jest ten problem, że możesz je zrobić niesamodzielnie i jestem przekonany, że wiele osób oddaje nie swój kod.

Rozwiązaniem tego problemu jest udostępnienie na rozmowie kwalifikacyjnej komputera ze środowiskiem i dostępnym helpem ale bez internetu oraz zadanie oprogramowania jakiejś funkcjonalności w ograniczonym czasie. Dzięki takiej formie rozmowy kwalifikacyjnej pracodawca dowiaduje się jak kandydat posługuje się językiem i środowiskiem oraz ma pewność, że jego praca jest samodzielna. Z kolei kandydat będzie mógł odszukać w helpie informacje, które wyleciały mu z głowy z powodu stresu czy z upływem czasu, nie będzie się również musiał przejmować brakującym średnikiem, literówką czy prostym błędem.

Co do zadań domowych/w firmie - z życia:

W pierwszym dniu pracy w Signatures Network (obecnie Live Nation) posadzono mnie przed kompem, dano źródła strony George'a Michaela i powiedziano: "dajemy Ci pełne 8 godzin, za które dostaniesz kasę tak czy siak - przerób galerię na tej stronie (PHP, JS) by była napisana obiektowo i z sensem. Wiemy, że nie zrobisz tego w całości - chcemy zobaczyć jak Ci pójdzie." (a kod był tam koszmarny, SQL przemieszany z HTMLem..).

2h zajęło rozeznanie się w strukturze plików i tym całym chaosie.. o szablonach wtedy tam nie słyszano.

Po 4 godzinach podszedł szefo technicznych, stwierdził, że podejrzał przez sieć co tam zdążyłem namodzić, rzekł, że jest w szoku z powodu postępu prac i wita mnie w swojej ekipie.

Z zadaniem domowym jest ten problem, że możesz je zrobić niesamodzielnie i jestem przekonany, że wiele osób oddaje nie swój kod.

Ja mam jednak wrażenie że w dzisiejszym świecie umiejętność korzystania z google a także w ogóle internetu jest nawet ważniejsza od umiejetności programowania. Tak jak tu ktoś kiedyś napisał że dla sprawnego programisty nauczenie sie nowych rzeczy z dokumentacji to nie jest problem.

Poza tym przecież pracodawca jak mi się wydaje nie zatrudnia programisty do pisania kodu ale do napisania kodu. Jeśli ktoś potrafi korzystać tylko z kolegi i to mu się opłaca to co to za problem ?

Pracodawca zatrudnia takiego typa, kolega wyjeżdża na wakacje, a pracodawca zostaje z pracownikiem, który bez kolegi sobie nie radzi.. tak teoretycznie

Wiadomo, każdy korzysta z pomocy czy to książek, sieci czy znajomych.. ale korzystanie a opieranie się na nich to dwie różne sprawy.

@offtop:
http://www.w3schools.com/quiztest/quiztest.asp?qtest=SQL
Ten test jakiś taki nie taki, miałem 80% w 7 minut a ostatni kontakt z SQL miałem jakiś rok temu, kiedy zrobiłem ze dwie bazy po jednej, małej tabeli w każdej, nie mające ze sobą nawet żadnej relacji :P Spodziewałem się testu gdzie taki noob jak ja będzie miał ze 20%.

Bo to sa pytania o podstawy podstaw. Wystarczy lekki kontakt praktyczny z SQLem, zeby taki tescik rozwiazac. Zgodnie zreszta z duchem odsiewania na banalnych pytaniach.

@up: W takim razie to ma sens, bo moja wiedza z SQL to rzeczywiście podstawy podstaw ;)

cepa napisał(a)

sam jestes bez sensu, testy sa tak banalne ze malpa ktora przeczytala najglupsza ksiazke o danym jezyku/technologi jest w stanie to zrobic, a i tak wiekszosc ludzi na tym sie wyklada :P

Wiesz co o gustach się nie dyskutuje więc nie będę się zniżał do twojego poziomu i nie powiem, że jesteś głupi, albo śmieszny, albo bez sensu.

sam jestes bez sensu, testy sa tak banalne ze malpa ktora przeczytala najglupsza ksiazke o danym jezyku/technologi jest w stanie to zrobic, a i tak wiekszosc ludzi na tym sie wyklada

[CIACH!] cepa. Nie każdy ma ochotę czytać książki po 1000 stron gdzie opisują każdy szczegół języka, nie mówiąc już o zapamiętywaniu tego. To się zwłaszcza tyczy programistów, którzy znają język X i przesiadają się na język Y. Takie kretyńskie pytania promują tylko ludzi, którzy jedyne co mają do zaoferowania do wykute na pamięć językowe kruczki (których i tak się nie używa) lub którzy siedzą całe życie w jednej technologii.