@Nequrian:
Obawiam się, że wywołałeś wilka z lasu :D. Jestem amatorskim (niespełnionym!) copywriterem i dość szybko generuję tekst, więc przygotuj się na najgorsze...
Trochę przesadziłeś z tymi podziękowaniami, choć z drugiej strony milsze to niż inne często spotykane zachowanie: ktoś pisze w danym topicu dopóki ma problem, a gdy po 10 postach mu się w końcu pomoże, to nawet dwóch słów nie napisze (niekoniecznie podziękowań -- nie napisze nawet, czy podane rozwiązanie w końcu zadziałało!).
OK, najpierw jeszcze powiem, w jakim trybie kupuję sobie książki. Od razu zaznaczam, że nie musi on być dobry dla początkującego programisty. Ja może stary nie jestem, ale lekcje programowania brałem już w podstawówce i jednak gdzieś od tej (ponad?!) dekady cały czas coś klepię. W drugiej połowie szczególnie intensywnie, a od paru lat komercyjnie. Więc noobem nie jestem, choć z drugiej strony... z dopiero co uzyskanym "-nasto" letnim doświadczeniem (z czego większość to -- co prawda intensywna -- jednak niekomercyjna nauka) jestem dopiero programistycznym nastolatkiem!
Teraz robię tak, że gdy zaczynam korzystać z jakiejś technologii, to muszę się jej przede wszystkim nauczyć. Gdy jakiś język ma być moim głównym na najbliższych parę miesięcy, szukam wszelkich źródeł na jego temat. Skupiam się, by opanować i zrozumieć go naprawdę dogłębnie. Staram się dotrzeć do najlepszych programistów tego języka. Szczególnie tych, co (dobrze) gadają na konferencjach. Przykładowo, ostatnio poświęciłem się głównie JavaScriptowi. Być może najbardziej poważanym koderem jest Douglas Crockford. Na jego stronie domowej możesz znaleźć sporo fajnych artykułów. Na YouTube i gdzieś na stronach Yahoo! możesz znaleźć prowadzone przez niego
wykłady (bardzo fajne). No i książka: "JavaScript -- mocne strony". Używasz jQuery? Znajdź jego twórcę. Jest nim John Resig. Znajdź jego blog. Poszukaj jego wykładów. Ajax?
To spojrzyj w te książki, o których mówiłem.
Niestety, o dobre książki nie jest tak łatwo. Warto spytać bardziej doświadczonych pochłaniaczy książek, czy napisać na forum takim jak to. Ja Empik odwiedzam tak z raz na tydzień (mam blisko :P) i patrzę, co też nowego pojawiło się na półkach. Niestety sporo z tego to chłam. Otwieram książkę o Ajaxie i widzę skrypty JavaScript najeżone funkcjami i zmiennymi globalnymi. Otwieram książkę do PHP i widzę już na pierwszy rzut oka kompletnie niepoprawny HTML z layoutem opartym na tabelach (made in 1995). Ktoś niedoświadczony weźmie tę książkę, natomiast dla mnie to sygnały, że autorzy nie przywiązują wagi do tego, by cały używany przez nich kod był w miarę dobry. Nie zrozum mnie źle: nie wymagam, żeby HTML w książce do PHP był ultra-semantyczny i hiperlekki, ale pewne minimum dobrego stylu wypada zachować. Trzeba tu jednak uważać, bo nawet ludzie świetnie się znający na standardach czasem walną coś brzydkiego. O ile mnie pamięć nie myli, Crockford walnął na samym początku swojej książki taki mały szablonik HTML do wstawiania skryptów, napisany totalnie na odwal i niepoprawnie. Aż polski tłumacz w przypisie to skomentował (z drugiej strony fakt, że tłumacz to zauważył dobrze świadczył o tłumaczeniu).
W każdym razie jako że umiem już jako-tako programować, staram się zawsze opanować na "dobrym" lub "bardzo dobrym" poziomie technologię, z którą przychodzi mi pracować.
Bywa jednak tak, że mam w tym pewien zastój. Tzn. po opanowaniu danej technologii dość długo przy niej pracuje i nie dochodzi mi nic nowego. Czasem wybieram wtedy inną technologię, którą zawsze chciałem opanować, albo przypominam sobie taką, której już trochę zapomniałem. Ale ostatnio nie mogłem znaleźć satysfakcjonującej mnie książki z tych dziedzin, więc postanowiłem podszlifować moje ogólne umiejętności programistyczne. Czyli podnieść jakość mojego kodu we wszystkich językach programowania.
W tym wypadku, jeśli chcesz kupić DUŻO książek, to możesz zacząć od pozycji Pragmatyczny programista. Od czeladnika do mistrza (Andrew Hunt, David Thomas). To jedna z dwóch "legendarnych" pozycji, które tu wymienię. Książka ta uczy dobrych praktyk, czasami bardzo ogólnych. Zdarza mi się niemal cytować ją na forum. Parę dni temu ktoś tu założył temat, że jakaś funkcja w JS zwraca mu zły wynik. Jedna z zasad "Pragmatycznego programisty"? "To nie SELECT jest zepsute". SELECT to oczywiście przykładowa nazwa polecenia czy funkcji wbudowanej w język lub bibliotekę używaną przez tysiące programistów. Chodzi o to, że prawie na pewno ona działa OK, a błędu musisz szukać w Twoim kodzie.
Albo inna rzecz z książki, rzadko spotykana. "Pociski smugowe". Ludzie znają często pojęcie prototypów, ale raczej nie pocisków smugowych. Prototyp to kod, który realizuje pewną część funkcjonalności aplikacji, ale jest napisany na odpieprz. Taka makieta czasem się przydaje. Jeśli się sprawdzi, wywalasz go do kosza i piszesz to porządnie (bogatszy o wiedzę uzyskaną w trakcie pisania prototypu). Pociski smugowe działają inaczej. Chodzi w nich o to, że implementujesz jakąś małą funkcję aplikacji -- np. najmniejszy modulik. Ale implementujesz go od początku do końca, w dodatku porządnie. Możesz on dowolnie ewoluować, bo to niewielki fragment systemu. Gdy będzie już tak dobrze napisany i zaprojektowany, jak sobie życzysz, to nie wywalasz go -- tylko dopisujesz kolejne moduły, używając tamtego za wzór. Po tym pierwszym masz też już zwykle gotową architekturę aplikacji, moduły pomocnicze etc.
Inna zasada: używaj systemu kontroli wersji. Nawet do projektów, które robisz sam. Nigdy tego nie stosowałem, ale książka jest tak świetna, że uwierzyłem jej na słowo. Od teraz wszystkie projekty robię na moim małym, prywatnym SVN-ie (przechowywanym na zdalnym serwerze). Dzięki temu nie muszę latać z pendrivem gdy siadam do innego kompa, nie muszę też -- co czasem robiłem, a co jest żałosne! -- wysyłać sobie kolejnej wersji projektu na GMail. No i jak coś spieprzę i nie mogę znaleźć gdzie, to robię po prostu Revert, a system kontroli wersji odwraca zmiany, które dokonałem od ostatniego zapisania repozytorium.
Książka jest tak dobra, jak o niej piszą. Nie ma w niej dużo kodu. Są proste, doskonałe zasady. Są eksperymenty myślowe. Są ciekawe ćwiczenia wraz z rozwiązaniami. Gdy kupisz ją w miarę szybko, to będziesz od razu robił dobrze wiele rzeczy, które nawet doświadczeni programiści robią często źle.
Druga legendarna książka to Wzorce projektowe (Eric Gamma i trzech innych panów; i tak każdy na nich mówi "Banda czterech"). Do jej zrozumienia potrzeba pewnej wiedzy o programowaniu obiektowym -- musisz najpierw ogarnąć klasy: dziedziczenie, enkapsulację, polimorfizm i inne takie rzeczy. Książka jest chyba najbardziej znanym i być może jednym z najpełniejszych zbiorów tzw. wzorców projektowych. Wzorzec projektowy to dość uniwersalny kawałek kodu rozwiązujący pewną klasę problemów. Nie jest to jednak algorytm. Bardziej schemat postępowania, schemat klas (a czasem po prostu użycie jakiejś metody). To taki idiom, który każdy dobry programista powinien znać. Każdy wzorzec ma swoją
nazwę, więc łatwo się o nim rozmawia. Nie wiem, czy obecnie w ogóle wiesz, co to jest klasa, więc nie będę tu przytaczał przykładowych wzorców. Powiem jedynie, że spotkać je można praktycznie w każdej większej szanującej się aplikacji. Książka Bandy Czterech to najlepsze drukowane (a może nie tylko drukowane?) źródło informacji o wzorcach, jakie znam.
Trzecia książka, również rozpowszechniana przez WNT, nie uchodzi za legendarną... jeszcze. A moim zdaniem nie ustępuje dwóm poprzednim! To Refaktoryzacja. Ulepszanie struktury istniejącego kodu (Fowler Martin i inni). Opisuje mnóstwo przypadków złego kodu i mówi, jak sobie z tym radzić. Refaktoryzacja to właśnie ulepszanie istniejącego kodu. Częstą przypadłością kodu jest to, że z czasem staje się coraz gorszy. Coraz bardziej zaśmiecony. Zmieniają się warunki, wymagania, założenia. Do istniejącej hierarchii kodu doklejane są nowe gałęzie. Całość staje się czasem mało sensowna, bo gdy zaczynałeś pisać kod, to projekt systemu wyglądał zupełnie inaczej. Refaktoryzacja polega na tym, by często i gęsto zmieniać strukturę kodu, który napisałeś wcześniej. Tak, by był ładniejszy i logiczniejszy.
Podam tu przykład jednej refaktoryzacji wspomnianej w książce. Masz takie coś:
public float podajCenęCałkowitą() {
return this.liczbaSztuk * this.cenaJednostkowa
+ Math.min(this.liczbaSztuk * this.cenaJednostkowa * 0.1, 100)
- Math.min(this.liczbaSztuk * 0.02, 0.15) * this.liczbaSztuk * this.cenaJednostkowa;
}
Co robi ta funkcja? Nazwa sugeruje, że podaje cenę całkowitą. OK, ale jak to jest obliczane? Wyrażenie obliczające jest strasznie skomplikowane! OK, co bardziej ogarnięty programista doczepi do kodu komentarz (kawałek od "/" do "/" -- ignorowany przez program, przeznaczony dla innych programistów):
public float podajCenęCałkowitą() {
/* cena całkowita = cena towaru + koszt dostawy - rabat
*/
return this.liczbaSztuk * this.cenaJednostkowa
+ Math.min(this.liczbaSztuk * this.cenaJednostkowa * 0.1, 100)
- Math.min(this.liczbaSztuk * 0.02, 0.15) * this.liczbaSztuk * this.cenaJednostkowa;
}
OK, ale to jeszcze nie jest refaktoryzacja. Po jej przeprowadzeniu, komentarz okazuje się zbędny i sposób obliczania ceny widać od razu z samego kodu! Wystarczy zastosować refaktoryzację zwaną Wydzieleniem zmiennej tymczasowej (x3):
public float dajCenęCałkowitą() {
float cenaTowaru = this.liczbaSztuk * this.cenaJednostkowa;
float kosztDostawy = Math.min(cenaTowaru * 0.1, 100);
float rabat = Math.min(this.liczbaSztuk * 0.02, 0.15) * cenaTowaru;
return cenaTowaru + kosztDostawy - rabat;
}
W ostatniej (nie licząc klamry) linijce funkcji masz teraz bezpośrednio napisany wzór na cenę całkowitą, a wcześniej kod został podzielony na mniejsze i łatwiejsze do ogarnięcia kawałki. W książce znajduje się sporo takich refaktoryzacji. Oraz opisane są tzw. "brzydkie zapachy". Widzisz w swoim kodzie coś, co pachnie zachem X? To zastosuj refaktoryzację Y (która dalej jest szczegółowo opisana). Tej książki też nie polecam na sam początek, trzeba znać się już jakoś na programowaniu obiektowym. Ale jest rewelacyjna.
Czwarta "ogólna" ksiązka to JUnit. Pragmatyczne testy jednostkowe w Javie (Andy Hunt, Dave Thomas). Hę? Jak to "ogólna", skoro w tytule jest nazwa języka programowania Java i javowego szkieletu testowego JUnit? Ano tak to, że istnieje takie coś jak architektura XUnit. JUnit był pierwszy i był dla Javy. Ale mamy PHPUnit dla PHP. JSUnit dla JavaScriptu. I tak dalej. Wszystkie XUnity są zrobione na podstawie tej samej architektury.
A do czego służą? Do automatycznych testów oprogramowania. Niewielu nie-profesjonalnych programistów z nich korzysta, a szkoda. Zwykle, gdy napiszą program, to po prostu sobie klikają i np. wykonują 10 specyficznych kliknięć (kliknij na Nowy klient, wypełnij to i to pole, ..., kliknij na Dodaj...) aż znajdą błąd. Wtedy siadają do kodu i poprawiają go. Próbują odtworzyć problem klikając ponownie 10x i okazuje się, że ich poprawka niczego nie dała. To znowu coś zmieniają, znowu klikają 10x i tak dalej.
XUnit umożliwia pisanie automatycznych testów (choć sprawdzasz w nim mniejsze bloki kodu niż te wywoływane po paru kliknięciach!). Potem możesz te testy odpalić jednym kliknięciem i dostajesz albo tekst "OK", albo "!!! FAILURES !!!" wraz z listą wykrytych nieprawidłowości. Od razu widzisz, która funkcja działa nie tak, jak sobie założyłeś (i jak sprawdzasz w teście). Testy to podstawa np. refaktoryzacji. Książka niewielka i co prawda opisuje starszą wersję JUnita, ale całkiem fajna i poczytna. Uczy pisania dobrych testów.
Wreszcie (!!) przeczytałem ostatnio książkę Algorytmy, struktury danych i techniki programowania (Piotr Wróblewski). Bo uważam, że raz na ruski rok warto sobie przypomnieć, jak się pisało algorytmy sortowania (i te bardziej skomplikowane też). Ja akurat ostatnio za często ich w pracy nie piszę, ale nigdy nie wiadomo. A programista nie może się przerażać, gdy każą mu napisac jakiś bardziej złożony algorytm. Jeśli nie miałeś studiów informatycznych, to tym bardziej Ci się to przyda, bo nam to na studiach wbijano dość ostro do głowy (w przeciwieństwie do dobrych praktyk opisanych w innych przedstawionych przeze mnie książkach!). Nie wiem jednak, czy to faktycznie dobra książka o standardowych algorytmach, czy zaledwie przeciętna. Poprzednie czytałem na studiach.
Dobra, chyba już starczy, bo forum się wysypie.