No właśnie - pamiętacie? Potraficie z głowy napisać większość rzeczy, z którymi mieliście styczność (nie mówie tu np o podstawowej składni języka, C++ czy C# ale raczej jakieś bardziej skomplikowane rzeczy, algorytmy) czy zaglądacie - jak ja - do różnych poprzednich projektów? Bo troche mnie to martwi, że taki leniwy jestem i często sobie musze zaglądać i sprawdzać różne rzeczy. Czasem nawet po bzdury. Co prawda ja z programowaniem dopiero zaczynam (troche umiem ale nie mam zbytnio doświadczenia) ale ciekawi mnie czy leniwość umysłu dotyka też takich klepaczy kodu jak Wy :)
W jakimś wątku tu na forum czytałem, że czasem przy aplikacji o pracę sprawdzają jak ktoś umie programować. I jak to wygląda? Ma wtedy odcięty dostęp od internetu? Pisze w Visual Studio i używa podpowiedzi? Czy może każą mu pisać na kartce 8) ?
Ja opiszę jak to wygląda u mnie z perspektywy klepacza kodu w Delphi, któty nigdy do tej pory nie pracował i póki co nie pracuje jako zawodowy programista, więc nie wiem jak to może wyglądać w firmach. Jednak ja robię tak, że często zaglądam sobie do innych swoich kodów źródłowych, a ostatnio lubiąc pisac tylko w WinAPI często jak piszę jakiś projekt to poza IDE Delphi 7 lubię na szybko otwierac inne projekty w edytorze filemanagerza FAR który mam pod F4 w Total Commanderze i kopiować pewne fragmenty. Albo nawet kopiować do nowego katalgu poprzedni projekt, następnie tylko zmieniam nazwy, przerabiam plik wsadowy do szybszego buildowania i pakowania exeka projektu, później ślęczę nad poprawieniem oraz rozbudową okienek dialogowych w ResEd i na końcu siedze oraz przerabiam kod. Tak było jak tworzyłem swoje downloadery, do których link masz w mojej sygnaturce. Poza tym do FaceBooka, bo ten jest w VCL (także w VCL jest ten do RetroReaders, który obecnie nie działa z powodu sporych zmian w tym serwisie). Dopiero niedawno napisałem sobie osobny unit z najczęściej używanymi funkcjami oraz porcedurami do kodów w WinAPI aby użyć go póki co w bardzo małej ilości nowych projektów pisanych póki co dla siebie. Przyznam się, że jakby ktoś kazał mi klepać jakieś bardziej złożone programy od zera bez dostępu do Internetu a także swoich poprzednich kodów to bym miał spory problem, bo to spore utrudnienie, jeśli ktoś ma taki łęb, że jest w stanie spamiętać wszystko co do tej pory napisał, a do tego w wielu jęzkach - to na prawdę szacunek, ma niezłą pamięć. Jednak skoro w wielu tutaj ogłoszeniach o pracę piszą, że wymagana jest znajomośc angielskiego w stopniu pozwalającym na czytanie dokumentacji to rozumiem, że taką dostępną na MSDNie też wolno czytać w pracy. Można zablokować pracownikom "mordoksięge" aby nie próżnowali w robocie, ale dlaczego mieli by nie googlować za dokumentacją czy nawet gotowymi rozwiązaniami. Chociaż pewnie tak jak firmy czy HeadHunterzy boją się podawania tutaj konkretnych widełek płacowych w ogłoszeniach to tak samo mogą się bać swobodnego dostępu do Internetu w pracy dla swoich programistów. Jednak jak wspomniałem na początku ja jestem tylko amatorem. Niech inni się tutaj wypowiedzą to będziesz miał być może konkretniejsze informację od prawdziwch pr0 k13p4czy k0du ;) Ja stwierdzam, że się jak zwykle rozpisałem i pora pójść już spać.
Pamiętamy. Korzystanie z dokumentacji/tutoriali, czy buszowanie po googlach w celu znalezienia rozwiązania problemu, tylko spowalnia pracę. Jako, że jesteś początkujący to wydaje ci się, że tego jest dużo, ale nie jest tak źle. Zobacz ile znasz słów i jakoś je pamiętasz. To tak jak byś chciał z kimś pogadać i musiał co chwila zaglądać do słownika. Zapominasz tylko te rzeczy, których nie używasz. Jeżeli masz problem z pamiętaniem jakiś rzeczy to stosujesz zasadę grindu. Powtarzasz to sobie do znudzenia, aż w końcu zapamiętasz. Następnie powtarzasz dalej do permanentnego utrwalenia. Nie słuchaj leni, którzy ci będą wmawiać, że programowanie polega na myśleniu, a nie bezmyślnym klepaniu wyuczonych formułek. Wydajność pracy jest bardzo ważna, im będziesz szybciej pracował, tym więcej zrobisz. Im więcej zrobisz, tym więcej się nauczysz.
No przecież nie będę z pamięci pisał np. kodu, który pokazuje/ukrywa opcje menu użytkownika, albo kodu, który przetwarza bitmapę piksel po pikselu. Skopiuję ze wcześniejszego projektu i tyle.
Nie zgadzam się z 'Pamiętacie'. Pewne rzeczy się pamięta, te z których często się korzysta. Od innych jest dokumentacja. Warto mieć jakieś notatki, zakładki, przydatne fragmenty kodów pod ręką i do nich zaglądać w razie potrzeby. Czy kolega "Pamiętacie" zna wszystkie definicje funkcji, specyfikacje klas, struktur itp. na pamięć?
Pamiętacie napisał(a)
Pamiętamy. Korzystanie z dokumentacji/tutoriali, czy buszowanie po googlach w celu znalezienia rozwiązania problemu, tylko spowalnia pracę. Jako, że jesteś początkujący to wydaje ci się, że tego jest dużo, ale nie jest tak źle. Zobacz ile znasz słów i jakoś je pamiętasz. To tak jak byś chciał z kimś pogadać i musiał co chwila zaglądać do słownika. Zapominasz tylko te rzeczy, których nie używasz. Jeżeli masz problem z pamiętaniem jakiś rzeczy to stosujesz zasadę grindu. Powtarzasz to sobie do znudzenia, aż w końcu zapamiętasz. Następnie powtarzasz dalej do permanentnego utrwalenia. Nie słuchaj leni, którzy ci będą wmawiać, że programowanie polega na myśleniu, a nie bezmyślnym klepaniu wyuczonych formułek. Wydajność pracy jest bardzo ważna, im będziesz szybciej pracował, tym więcej zrobisz. Im więcej zrobisz, tym więcej się nauczysz.
Nie wiem skąd bierzesz te ludowe mądrości ;p Najgorsze to właśnie uczenie się na pamięć. Jak to mawiał jeden mój profesor - "idiota się na pamięć uczy ,nie informatyk ! " i miał racje. Ja osobiście znam jedynie składnie C/ASM/C++ i jak działa komputer. Gdy piszę w asm to wystarcza ze znam pareset rozkazów. W C to tylko składnia i biblioteki, a C++ używam w dialekcie CLI - znając C++ mam oględne pojęcie co w jakiej klasie jest, np. że pisząc w cmd z pewnością użyje czegoś z System.Console. jednak nie mam pojęcia co tam dokładnie jest bo i po co ? IS mi podpowie. Nie ma najmniejszego sensu uczyć się całego MSDNA na pamięć, chyba, że wybitnie nie masz co robic. Uczyć się kodu ? Pff.... po to są komentarze, a mając paredziesiat tysięcy lini nie jesteś wstanie zapamiętać wszystkiego, jak kod przechodzi w setki tysięcy i Ty sam go nie piszesz to i tak sie nie połapiesz z pamięci a za niekomentowanie to ci kumple z roboty jaja urwą. Algorytmów też na pamięć się nie uczyłem. Znam cel i ogólną idee i za każdym razem "wyprowadzam" sobie ów algorytm. Znaczy się są przypadki, że człowiek jedzie z pamięci, ale to takie podręcznikowe jak QS,Prim,Wyszukiwanie stringów Knutha ...
Dobra organizacja wiedzy jest wystarczajaca, wiesz gdzie co szukać i nie tracisz na to wiele czasu np wiesz gdzie masz już stworzony taki algorytm i albo go odkopiujesz albo trzymasz w jakiejś bibliotece. Znalezienie takiego algorytmu i ewentualne dostosowanie do potrzeb nowego kodu będzie na pewno szybsze niz pisanie tego z pamieci od poczatku.
Jeżeli chodzi o składnie/wywołania itd to dobre ide + podlinkowana dokumentacja powinny załatwić większość problemów.
Nie po to ktoś wymyślił rozdzielanie kodu na osobne pliki, obiektowość i dziedziczenie, żeby za każdym razem klepać to samo. Jak sobie napiszesz np. procedure do sortowania w miarę uniwersalną to jeb ją do jakiegoś unitu z utilsami a potem tylko dołączasz do projektu i masz gotowe. To samo np. z funkcjami do rysowania czy cokolwiek sobie napiszesz co możesz potem wstawiać do innych projektów. Osobna historia to własne komponenty, gdzie z czasem nawet zapominasz co się tam w środku dzieje i jak coś trzeba dodać zmienić to mimo iż sam to pisałeś to bez dokumentacji nie da rady. Z czasem nazbierasz sobie takich własnych bibliotek więcej i będziesz z nich tylko korzystał bez zastanawiania się co tam siedzi w środku.
BTW Co za debil wymyślił aby uczyć się na pamięć implementacji np. quicksorta. Jak znasz algorytm to jesteś go w stanie napisać w parę minut a jak nie znasz to na dobrą sprawę szybciej znajdziesz gotowy kod niż przyswoisz sobie algorytm a potem napiszesz własny kod.
Tak jak tobie mówiłem, zaraz będzie atak leni, którzy będą usprawiedliwiać swoje lenistwo. Pewnie też nie mają żadnych certyfikatów w stylu OCJP, bo to "bezwartościowe kucie na pamięć i nie uczy myślenia".
lukas_gab napisał(a)
użyje czegoś z System.Console. jednak nie mam pojęcia co tam dokładnie jest bo i po co ?
Ja wiem, że nie masz pojęcia, nawet nie chce pytać ile czasu na to straciłeś Read() blokuje ReadLine()
Widać twoje "wyprowadzanie algorytmów" nie przystaje do tak banalnych rzeczy jak czytanie z konsoli...
Pamiętacie napisał(a)
A to, że trzeba myśleć w programowaniu to banał.
to jest podstawa programowania a zapamiętywanie wszystkiego to głupota
Nieznajomość działania danej metody należy odróżnić od nieznajomości zawartości wszystkich klas. Co komu da pacierzowe poznanie gdzie co jest ? Przecież po to powstały hierarchiczne i intuicyjne struktury. Fakt - jak pokazał zalinkowany temat należy znać różnice między metodami, ale to tyle. Nawet nie potrzeba znajomości ich pełnych nazw - widząc ją poprzez eksploracje biblioteki ( intuicyjne zresztą ) przypominają się szczegóły działania. Poza tym nie mam kompletnie pojęcia dlaczego zestawiasz błąd w użyciu metody z algorytmami ?
ta jasne pamiętamy, niech ktoś zacznie kodować w notatniku w takiej javie/C# bez podpowiadania składni. Nie wierzę że ktoś jest w stanie chociażby poprawnie importować liby:P
Pamiętacie napisał(a)
Tylko naśmiewam się z tej postawy, że w sumie to pamiętać należy tylko składnie if/for i jakieś ogólniki o algorytmach, bo jak coś potrzeba to się znajdzie na wiki. Oczywiście, że nie da się pamiętać wszystkiego, bo to jest fizycznie niemożliwe, ale trzeba pamiętać bardzo dużo. Im więcej pamiętasz, tym wydajność twojej pracy jest większa.
Jeśli czegoś używam często, to automatycznie to zapamiętuję, i sprawdzać w źródłach już nie muszę. Nie będę się uczył na pamięć z książek czy dokumentacji, bo to jest dużo większa strata czasu niż doraźne sprawdzenie w nich czegoś, co akurat potrzeba.
Pamiętajcie napisał(a)
Im więcej pamiętasz, tym wydajność twojej pracy jest większa. A to, że trzeba myśleć w programowaniu to banał.
Ty to chyba w ComArch pracujesz. Zamiast klepać bezsensownie kod czasem warto POMYŚLEĆ nad problemem nawet dzień lub dwa i napisać to porządnie
Są 2 efektywne sposoby, żeby ułatwić sobie zapamiętanie, nawzajem się wspierające:
a) Dokładnie zrozumieć jak coś działa. Ja właściwie nie jestem w stanie zapamiętać mechanizmu jeśli go nie zrozumiem.
b) Jak wspomniał somekind, poprzez częste używanie
Nigdy nie uczę się na pamięć i nie robię nic w tym kierunku. Naklepałem wiele stron w życiu i do dziś nie potrafię napisać kilku pierwszych linijek XHTML-a (doctype, i jakiś bardziej zaawansowany head), ale wiem, że jak wpiszę na google "wiki xhtml" to od razu to znajdę.
Podobnie z programowaniem. Podobnie z programowaniem. Znam algorytmy, ale czasami i tak wolę je sobie powtórzyć. Czasami wystarczy zerknąć na wikipedię.
Zwykle staram się pisać każdy kawałek kodu od podstaw, ale to bardziej z faktu, że im więcej praktyki, tym lepiej. I po prostu zwykle mam na to czas.
Ogólnie to wiedzę staram się organizować w HashMapie, gdzie kluczami są zapytania do google.
No na pewno bardzo rozleniwia uzupełnianie składni w Visual Express. Czasem nawet nie pamiętam jak nazywają się obiekty w moich klasach, choć staram się pisać intuicyjnie i przejrzyście, ale po prostu przyzwyczajenie że wpisujesz kilka pierwszych liter i naciskasz kropkę lub enter i masz.
Natomiast nie jestem pewny czy częste używanie faktycznie tak bardzo pomaga w zapamiętaniu. Ogólny zarys jakiegoś działania pamiętam No ale często zaglądam do poprzednich projektów by nie męczyć się nad czymś co już dawno rozwiązałem. Tak samo jak z matmy wyprowadzimy sobie jakiś wzór na coś i potem chcąc obliczyć to coś to tylko podstawiamy do wzoru a nie wyprowadzamy od nowa.
Zdecydowanie nie ma najmniejszego sensu uczyć się na pamięć. Po pierwsze jeśli ktoś tylko i wyłącznie uczy się na pamięć i klepie kod w ten sposób to nigdy nie będzie potrafił sprawnie zmodyfikować kawałka kodu w danym algorytmie. To jest nawet jedna z metod sprawdzania na studiach czy student nie uczył się "pamięciówy" i np należy zaimplementować algorytm sortowania (chociażby taki prosty przykład), a przy sprawdzaniu przez wykładowcę prosi on o modyfikację kodu tak by kod "robił to i to". Jeśli ktoś uczy się na pamięć danych algorytmów, a ich nie rozumie to w życiu sprawnie nie wprowadzi modyfikacji.
Algorytm, czy zasadę działania danego elementu należy zrozumieć, a nie wykuć na pamięć. Jeśli ktoś zrozumie dany algorytm to w tym samym momencie raczej nie ma sensu mówić o zakuwaniu, bo po prostu dany algorytm napiszemy z głowy. Bez żadnych pomocy i bez żadnych problemów. Pisanie zaś algorytmu czy czegokolwiek innego tylko i wyłącznie z pamięci na zasadzie "wykucia" prowadzi nie tylko do błędów (bo dany klepacz nie potrafi poprawnie zmodyfikować kodu na własne potrzeby), ale też do frustracji i niepotrzebnego stresu. Co więcej implementacji co bardziej złożonych algorytmów jest ogromna ilość, jaki jest więc sens uczyć się ich na pamięć?
To samo tyczy się obsługi baz danych czy podobnych zagadnień. Od tego są dokumentacje. Baa jeśli ktoś wybierze drogę "wykuwania" może się okazać, że jego wiedza będzie przestarzała. (tutaj akurat nie mówię o algorytmach bo te są raczej długowieczne).
Od zapamiętywania kodu są odpowiednie programy lub nasze osobne źródła wiedzy, gdzie możemy przechować snippety lub co bardziej złożone fragmenty kodu.
Zawsze gdy uda mi się "dowiedzieć czegoś nowego" zapisuję to sobie do mojego prowizorycznego pliku, gdzie mam wszystkie kawałki kodów podzielone na rodzaje przeznaczenia. Jeśli zajdzie potrzeba, że muszę z czegoś skorzystać, a tego nie pamiętam zbyt dobrze to moje pierwsze kroki kieruję do właśnie owych "skrótowców" i sprawa załatwiona. Jest to sposób po prostu dobry, a zarazem odpowiedni w momencie, gdy rozumiemy dane zagadnienie. Jeśli zaś zagadnienia nie rozumiemy, a skorzystamy z kawałka kodu to **skutek będzie taki sam lub nawet gorszy od "wykucia na pamięć". **
Według mnie **wykuwanie na pamięć algorytmów **czy jakichkolwiek kawałków kodu to jak uczenie się encyklopedii na pamięć. Niby można, ale sensu w tym nie ma za grosz. **Sztuką jest zrozumieć dane zagadnienie, a nie je wykuć na pamięć **i powtarzać w kółko bo to nie prowadzi do niczego dobrego.
Na zapamiętanie danych implementacji lub algorytmów działa pozytywnie nic innego jak już powtórzony tutaj sposób:
- częste używanie
Pamiętajmy jednak, że wykucie na pamięć jest bez sensu bo to, że coś wykujemy nie oznacza, że to zrozumiemy.
**Słowa Alberta Einsteina:
* Każdy głupi może wiedzieć. Sedno to zrozumieć.
**
polaczek17v2 napisał(a)
Algorytm, czy zasadę działania danego elementu należy zrozumieć, a nie wykuć na pamięć. Jeśli ktoś zrozumie dany algorytm to w tym samym momencie raczej nie ma sensu mówić o zakuwaniu, bo po prostu dany algorytm napiszemy z głowy.
Nie zgadzam się. To, że trzeba algorytm zrozumieć to jest oczywistość. To jest łatwa sprawa. Bez zakuwania/ćwiczenia/treningu/grindu zwał jak zwał, zapomnisz to bardzo szybko. I na pewno tego z głowy nie napiszesz. To tak jak z uczeniem się matematyki. Najwięcej czasu zajmuje robienie zadań, które często różnią się tylko subtelnościami. Próbujesz przedstawić zakuwanie, jako bezwartościowy proces wykonywany przez idiotów. Myślisz, że na studiach medycznych wystarczy zrozumieć temat? Jest tona zakuwania. Ale tam chodzi o ludzkie życie i jeszcze nie można się opierdalać.
Medycyna jest specyficzna gdyż lekarze muszą reagować w czasie rzeczywistym. tak więc lekarz nie może pacjentowi z zawałem powiedzieć, żeby poczekał bo musi sprawdzić coś w internecie.
Nawet w przypadku lekarzy zakuwanie wszystkiego jest bez sensu.
W przypadku zawału sprawa jest oczywista. Jeżeli przypadek nie jest nagły, to wolę by lekarz sprawdził w internecie (w kompendium) niż polegał na własnej pamięci.
Bez zakuwania/ćwiczenia/treningu/grindu zwał jak zwał, zapomnisz to bardzo szybko
I co się stanie?
- Skończy się świat?
- Szef zwolni z pracy?
- Załamiemy się?
Czy może zamiast przerażenia w oczach na samą myśl o "zapomnieniu algorytmu", lepiej zastanowić się i pomyśleć:
- Skoro dany algorytm wyleciał mi z głosy to oznacza tylko tyle, że nie używałem go często. Po co w takim razie miałbym go pamiętać i przypominać? Przecież to jest strata czasu i energii. Nie ma najmniejszego sensu tracić cennego czasu oraz energii na coś co nam się nie przyda, jeśli zaś danemu programiście pewien algorytm się przyda to **wystarczy, że przeczyta on o nim cokolwiek chociażby na wikipedii (albo ogólnie wystuka go w google) **i ma wszystko podane na tacy. Nie tylko w momencie jego implementacji utrwali sobie wiedzę, ale też nauczy się czegoś co mu się faktycznie przyda. Z kolei programista uczący się "wszystkiego i niczego" jest po prostu przepełniony i przemęczony.
Spójrzmy na inną kwestię: Wzorce projektowe.
Czy są programiści, którzy uczą się ich na pamięć? Jaki jest sens wykuwania na pamięć danego wzorca? Przecież do każdego przykładu wzorzec można samemu odpowiednio przerobić, jeśli zaś będziemy korzystać ślepo utartą drogą to w ostateczności nasz kod będzie przestarzały, a często też - bezsensowny, ponieważ programista-zakuwacz idzie utartą drogą bez myślenia o tym co można by poprawić. Jeśli jednak nasz projekt idealnie nadaje się do danego typu wzorca to nie szkodzi, że nie pamiętamy jak on wygląda - dobry programista w takim przypadku nawet sobie to przypomni bo wzorce (i algorytmy) wynikają z logicznego myślenia, a w najgorszym razie wystarczy google lub nasze notatki. 2 minuty dosłownie wystarczą abyśmy wszystko wiedzieli.
Jest jeden warunek jednak: Programista zawsze musi wiedzieć o co chodzi. Jeśli nie wie to samo wygooglowanie problemu na niewiele się zda, bo pozostaje jeszcze potrzebny czas na zrozumienie problemu. Najczęściej jednak zdrowy na umyśle programista zna większość algorytmów, tylko musi sobie je przypomnieć. Nie ma najmniejszego sensu pamiętać tony algorytmów tylko po to,że : Może kiedyś mi się przydadzą.
Gdyby tak każdy robił to tak jak wspomniałem - każdy zakuwał by encyklopedię, bo może kiedyś się coś z niej przydać. Czy jednak ktoś tak robi? Czy byłoby to normalne?
**Podany przykład z medycyną przywodzi na myśl programistę pracującego pod lufą pistoletu wycelowanego w niego **- działanie pod wpływem stresu. Właśnie tak można opisać pracę lekarzy - działają pod wpływem stresu, więc muszą wiedzieć i znać wiele zagadnień na pamięć i z nich korzystać. Tam liczy się każda sekunda, więc nie ma czasu wygooglować problemu i poszukać rozwiązania.
Praca programisty wygląda jednak inaczej. Baa tutaj sprawa ma się tak, że dobry kod wymaga nawet dużo więcej czasu samego myślenia niż pisania. Nie ma sensu klepać kodu i algorytmów jak robot, gdyż to nigdy nie będzie ani odpowiednio wydajne, ani logiczne. Prawdziwy problem algorytmiczny wymaga rozwiązania - a to przychodzi wraz z logicznym myśleniem, a nie wyklepaniem problemu tak jak nas nauczono na uczelni, czy w innym miejscu. Programiście logicznie myślącemu, który natknie się na pewien problem od razu zaświetli się lampka, że coś takiego było i można to rozwiązać elegancko. Wystuka słowa kluczowe w google i znajdzie rozwiązanie bez problemu lub też napisze swoje rozwiązanie, a w razie konieczności może sprawdzić w google jak je poprawić i zwiększyć wydajność.
Nauczenie się na pamięć nawet ze zrozumieniem problemu jest po prostu nieefektywne nie tylko dla pracy programisty, ale też dla mózgu, który w ten sposób jest przepełniony niepotrzebnymi informacjami.
Ps:
A co do lekarzy jeszcze to przecież już od dawna jest głośno właśnie o tym, że wolą oni korespondować na forum np i omawiać pewien przypadek i upewnić się co do diagnozy, niż samemu wystawiać opinię. I bardzo dobrze. Lekarze też powinni sprawdzać swoją wiedzę, nie zawierzać jedynie na tym co pamiętają. Dobre jest to, że tak się dzieje. :)
BTW Co za debil wymyślił aby uczyć się na pamięć implementacji np. quicksorta. Jak znasz algorytm to jesteś go w stanie napisać w parę minut a jak nie znasz to na dobrą sprawę szybciej znajdziesz gotowy kod niż przyswoisz sobie algorytm a potem napiszesz własny kod.
przecież znać algorytm to tak jakby znać kod na pamięć: niekoniecznie w konkretnym języku programowania, a raczej „w głowie”.
Zresztą quicksort jest brzydki. Implementacja naiwna jest bardzo krótka i robi wrażenie, ale ma mnóstwo problemów, które jak zaczniesz łatać (mediana z trzech, pętla, odcięcie małych bloków, ograniczenie rekurencji) — a każda taka łata jest jak najbardziej uzasadniona, to robi ci się z tego introsort, a kod jest monstrualny.
No na pewno bardzo rozleniwia uzupełnianie składni w Visual Express.
Uzupełnianie to tak jak szybkie zajrzenie do dokumentacji. Po co mam otwierać pomoc czy patrzeć w internecie (albo do książki), skoro pod jednym klawiszem mogę mieć listę tego, co akurat w danej chwili jest dostępne?
Podpowiadanie kodu jest dobre. (automatyczne domykanie nawiasów itp. niekoniecznie, źle zaimplementowane wkurza. dobrze robi to QtCreator)
Jaki jest sens wykuwania na pamięć danego wzorca?
Jaki jest sens w ogóle uczenia się wzorców? Pisząc kod w jakimś języku czy pod jakiegoś frameworka trzeba pisać tak, jakby był dalszą częścią biblioteki, której używamy: podobna konwencja nazewnictwa, struktur danych itp.
Radosne stosowanie książkowych wzorców kończy się przekombinowanym, wolnym kodem, którego ktoś po nas nie będzie mógł ogarnąć.
A co do algorytmów — nie są tak często potrzebne jak się wydaje. Najważniejsze (sortowanie i wyszukiwanie) i tak są już gotowe we wszystkich możliwych środowiskach.
Dlatego wcale nie trzeba umieć sortować. Ale znajomość bardziej egzotycznych problemów może się bardzo przydać, ale rzadko.
IMHO nie ma potrzeby uczenia się czegokolwiek "na pamięć" poza pracy z narzędziem, którym się posługujemy w tym przypadku językiem programowania (nazwy klas, interfejsów, przestrzeni nazw). Samo zrozumienie i zapamiętanie istoty algorytmu wystarczy aby go odtworzyć. Jeżeli, ktoś nie potrafi napisać quicksort bez google to znaczy, że nie zrozumiał lub nie zapamiętał istoty tego algorytmu. W żadnym wypadku nie ma potrzeby wkuwania kodu. Podobnie jest z każdym innym algorytmem. Tak samo jest w przypadku wzorców projektowych, których z resztą zastosowanie w każdym konkretnym przypadku może wyglądać inaczej, więc "wkuwanie" odpada.
Też jestem przeciwnikiem uczenia się kodu na pamięć. Rozumiem działanie większości algorytmów - ale czemu nie miałbym ściągnąć kodu z googla? Owszem, w niektórych przypadkach wyznaję zasadę Not Invented Here, ale jeśli to ma być głupie sortowanie, do którego nie będą wprowadzane żadne zmiany, to po co mam klepać to samo kolejny raz? Strata czasu.
Wychodzi na to że jest jedne porządny 'Pamiętacie', a my wszyscy jesteśmy lenie :P
Uczenie się kodu na pamięć -- bez sensu. Konieczne jest zrozumienie. Jak najpełniejsze. Wtedy nie trzeba nic wkuwać, można sobie "wyprowadzić" kod jak wzór matematyczny.
Gdy fragment kodu jest duży i skomplikowany i jego "wyprowadzenie", tj. napisanie z palca, trwa za długo, to tym głupsze i zasobożerne byłoby wkuwanie na pamięć.
Reużywalność -- jak najbardziej. Cały czas wbija nam się ją do głowy. I dobrze: piszmy porządny, łatwy do ponownego użycia kod. Jeśli istnieje już dobre rozwiązanie, użyjmy go -- nie wynajdujmy koła na nowo.
W obrębie jednego projektu, kodu nie powinno się kopiować, bo byłoby to naruszenie DRY. Można jednak linkować i wykorzystywać klasy, obiekty, funkcje. Można je też zaciągać (ew. kopiując) z innych projektów, choć to rodzi pewne problemy. Jeśli skopiujemy kod z projektu źródłowego i autor kodu poprawi w źródle jakieś bugi, my nie dostaniemy tych poprawek. Jeśli zaś podlinkujemy do kodu źródłowego, to poprawki będziemy mieli na bieżąco, ale z kolei gorzej będzie, gdy interfejs się zmieni. Wtedy albo będzie lipa po naszej stronie, albo lipa po każdej stronie, gdy kulawy interfejs będzie zachowany ze względu na kompatybilność wsteczną -- przykłady można znaleźć w samym języku Java (typy generyczne!) i oczywiście w wielu innych miejscach.
Być może autorowi chodzi jednak o coś trochę innego. Coś, co miałem na początku mojej przygody z programowaniem (włącznie ze studiami), ale co mi w zasadzie przeszło.
Sytuacja: "coś kiedyś napisałem i to zadziałało, ale jest tak skomplikowane, że sam tego do końca nie rozumiem i cholernie bym się męczył, próbując to odtworzyć". Wiadomo, że odtworzenie 10 tys. linii kodu jest czymś nudnym i męczącym, ale mi chodzi o mniejsze fragmenty, na kilkadziesiąt czy małe kilkaset linii.
Zdarzało mi się niegdyś, że przebiłem się przez jakiś problem, nigdy tak totalnie do końca go nie ogarniając. Napisałem rozwiązanie. Kod, który niby rozumiałem, ale nie dogłębnie, nie od podszewki. Dlatego ciężko mi by go było odtworzyć.
Teraz tak nie mam. Nie lubię nie rozumieć czegokolwiek we własnym kodzie -- w pewnym momencie dotarło do mnie, że takie niepełne rozumienie jest po prostu niedorzeczne. Jednak, co by nie mówić, zdarza się bardzo wielu studentom informy i czasem nawet zawodowym programistom.
Ponieważ rozumiem dokładnie wszystko, co napisałem, nie mam problemu z napisaniem czegoś takiego od nowa. Poza tym, moje funkcje i obiekty są małe. Nie ma tam nic skomplikowanego. Turbo algorytmów pisać nie muszę. Piszę głównie w JavaScripcie, który ma bardzo ubogą "bibliotekę standardową". To język funkcyjny i środowisko w sporej części asynchroniczne. Używam na co dzień konstrukcji takich jak "promysy" (coś jak obiekty Future z Javy) czy monady (jak ktoś nie wie co to, a obił się o JS, to pewnie zna chociaż jQuery -- ono ma takie monadowe API ze stosem elementów i chainingiem). Używam gotowych rozwiązań, ale nie mam żadnych problemów, by rozszerzyć czy stworzyć od nowa podobne API samemu.
IMO sytuacja, w której nie chcemy czegoś napisać ponownie, bo boimy się, że tego do końca nie rozumiemy, jest niekorzystna. Natomiast niechęć do napisania czegoś z lenistwa, gdy wiemy jak to zrobić, ale nie chcemy się męczyć ze żmudnym robieniem wszystkich potrzebnych obejść (tak jak np. jQuery obchodzi błędy w implementacji różnych przeglądarek) -- to już jest normalne. I pożyteczne. Mówienie "mógłbym to zrobić, nie jest to dla mnie za trudne, ale jest bardzo żmudne, więc mi się nie chce -- więc wymyślę jak to obejść (choćby poprzez użycie gotowca)" jest bardzo zdrowe.
Tak naprawdę, nie wszystko musimy tak do końca rozumieć. Możemy używać jakiejś biblioteki i nie rozumieć, jak jest napisana. Wystarczy nam, że honoruje kontrakty. Umiejętność pracy w tym trybie jest dobra i przydaje się również, gdy korzystamy z "gotowca" napisanego przez... kolegę z zespołu. Musimy umieć pracować z czarnymi skrzynkami. Gdy zapewnimy modułowi takie i takie wejścia, to możemy oczekiwać takich i takich wyjść (programowanie kontraktowe!).
Zauważyłem jednak, że im dalej w las, im człowiek lepszy -- biegły w języku programowania, w różnych API, technologiach okołojęzykowych itp. -- tym częściej, widząc czarną skrzynkę, domyśla się implementacji. Bo przecież kolesie, którzy pisali tę czarną skrzynkę to nie kosmici. W pewnym momencie osiąga się przecież poziom zbliżony do tego, jaki mieli twórcy jakichś bibliotek (cóż, może to jest częściej prawdziwe "u mnie w JS-ie", gdzie poziom programistów jest generalnie nie za wysoki).
Czasami nie muszę zaglądać w kod, by mieć praktycznie pewność, jak został napisany, a czasami sobie zaglądam i sprawdzam, czy jest to zgodne z moimi oczekiwaniami. Lubię wiedzieć, jak coś działa. Ale nie polegam na tej wiedzy. Liczę tylko na kontrakty i nie używam wewnętrznych mechanizmów, które zresztą -- w dobrze zaprojektowanym kodzie -- nie powinny być dla mnie dostępne.
Co do "ściągania kodu z Google'a" to ja akurat mam do tego bardzo ostrożne podejście. Z konieczności. W necie pełno kodu script-kiddies, niewiele kodu na odpowiednim poziomie. Jak czegoś szukam, to raczej po specyfikacji języka. Ew. po bibliotekach, które mogę zaimportować (a nie: skopiować). Czasem jednak adaptuję jakiś znaleziony fragment kodu, ale od dawna najpierw muszę go zrozumieć, a potem najczęściej i tak jakoś refaktoryzuję.
Co do tego, jak jest na rozmowach kwalifikacyjnych... Ja akurat czasem prowadzę takie rozmowy.
Nie wiem jak gdzie indziej, ale w moim teamie naprawdę staramy się nie być gburami czy idiotami. Rozmowa = stres. Zwykle oznacza to gorsze myślenie, a także gorszą pamięć. Na to jest brana poprawka. W pracy codziennej stresu przecież nie ma -- atmosfera fajna, deadline'y rozsądne -- więc nikt odporności na stres nie testuje.
Tak, niektóre testy rozwiązuje się na kartce. IMO słuszne jest sprawdzanie testów kwalifikacyjnych w sposób bardzo... "rozmyty". Wspólnie z kandydatem, zadanie po zadaniu. Trwa to dłużej, ale pozwala kandydatowi się poprawić i zademonstrować umiejętność poprawiania swojego kodu, czy nawet uczenia się. Czasem dwa kolejne zadania dotyczą tego samego aspektu języka, tyle że pierwsze bada podstawy, a drugie jest bardziej skomplikowane. Zdarzało się, że ktoś oblał podstawy, bo ich po prostu nie znam. Wytłumaczyłem w paru zdaniach ten aspekt języka i kandydaci zaskakująco często sami wiedzieli, jak poprawić drugie zadanie.
Wykucie API na pamięć niemal nie jest sprawdzane, a nawet jeśli jest delikatnie "sprawdzane", to oblanie tej części testu ma marginalne znaczenie. Nie ma dla nas znaczenia, że napisałeś subnodes zamiast childNodes dopóki algorytm (nawet sam jego zamysł) się zgadza i jest dobry. Konkretne nazwy własności, funkcji, obiektów można sobie przecież wygooglać. Sprawdzanie wykucia na pamięć polega raczej na tym, że jest to rzecz opcjonalna, ale jeśli ktoś to ma wykute -- bo akurat przez ostatnie pół roku tego używał -- to jest to jakimś plusikiem. Nigdy mi się jednak nie zdarzyło, żeby mieć dwóch kandydatów a tylko jedno miejsce i by znajomość API zaważyła.
Samego języka trzeba się jednak nauczyć. Na szczęście nie rekrutuję programistów C++ ;). Wierzcie lub nie, ale u mnie w branży zaskakująco wielu kandydatów np. nie rozumie dziedziczenia prototypowego w JavaScripcie. Fakt, większość z tych osób nie uważa się za hardcore'owych JavaScriptowców, tylko bardziej HTML/CSS-owców lub programistów innego języka dopiero przechodzących na JS, no i dziedziczenie prototypowe jest rzadsze niż klasyczne, z Javy, ale... To trochę tak, jakby ktoś miał pisać w Javie i nie wiedział, czy gdy napisze samą deklarację class, to czy tworzy mu się w tym momencie jakaś instancja tego typu, czy nie. To przecież podstawy.
Niedawno ktoś na forum burzył się, że na teście z C++ pytali o przypadek, w którym w klasie MyClass była składowa MyClass myClassMember;. To nie są przecież hardkory, tylko rzeczy, które dla profesjonalisty powinny być w miarę podstawowe. Czasem testy dają nienaturalnie wyglądające fragmenty kodu, za które w repozytorium produkcyjnym dostałoby się w ryj ;). Ale te fragmenty w paru linijkach testują jakieś fundamentalne zagadnienie związane z językiem, np. z typizacją, konwersją, dziedziczeniem, aliasowaniem nazw.
Sam język wypada jednak znać przynajmniej w dużym stopniu (bo rozumiem, że C++'a ze wszystkimi quirkami implementacyjnymi nauczyć się w 100% po prostu nie da ;) ).