Poznawanie nowych narzędzi programistycznych, bibliotek czy nawet platform to częsta konieczność w pracy kodera. Najczęściej jest to środek do osiągnięcia jakiegoś konkretnego celu projektowego, ale nierzadko możemy też zechcieć zagłębić się w nowe API dla samej przyjemności jego poznania. Jak się do tego zabrać? Są różne sposoby.
Możemy na przykład próbować jak najwięcej się o danej bibliotece dowiedzieć. W dzisiejszych czasach nie jest to trudne, bo standardem jest posiadanie dobrej (albo chociaż jakiejkolwiek ;]) dokumentacji. Ponadto wokół niemal każdej choć śladowo popularnej technologii natychmiast wyrastają internetowe społeczności, których dyskusje na forach (rzadziej już na grupach dyskusyjnych) mogą być również cennym źródłem informacji – zwłaszcza w przypadku wystąpienia problemów.
Postępując w ten sposób możemy zyskać bardzo szeroki i głęboki (jak morze :)) wgląd w funkcjonowanie danej biblioteki i jej strukturę, co może nam pomóc w jej użytkowaniu. Istnieje jednak szansa, że poprzez nadmierne skoncentrowanie się na opisach teoretycznych umkną nam ważne kwestie praktyczne.
Niejako przeciwną metodą jest jak najszybsze zajęcie się ową praktyką. W tym celu wystarcza zwykle przejrzenie różnorakich tutoriali (jeśli takowe są dostępne), a zwłaszcza dokładne przestudiowanie przykładowych fragmentów kodu. Zresztą eksperymentalne poznawanie nowej technologii może być wręcz kopiowaniem sampli, ich uruchamianiem, a następnie modyfikacją w celu zmiany sposobu działania, uelastycznienia lub poszerzenia o nową funkcjonalność.
Gdy w taki sposób zabieramy się do rzeczy, możemy szybko zobaczyć rezultaty. Jeśli jednak będziemy mieli pecha i pojawią się niespodziewane problemy, zaledwie pobieżna znajomość technologii może nam wydatnie utrudnić ich rozwiązanie. Poza tym takie kodowanie “na gorąco” wymaga nieporównywalnie częstszych wypadów na łono dokumentacji :)
Czasem zamiast dokumentacji wystarczy zajrzeć do źródeł. Jeżeli korzysta się z open source, przejrzysty kod jest o niebo lepszy niż każda dokumentacja. Na ten przykład: uczę się joomla! – zamiast czytać opis funkcji czy szukać info na sieci, lepiej zajrzeć do środka, wszystko jest ślicznie i porządnie napisane (plus trochę komentarzy) – nic więcej nie potrzeba, żeby zrozumieć o co kamon. Oczywistą oczywistością jest to, że jak się zaczyna to odrobina wiedzy teoretycznej jest przydatna.
Gdyby każdy projekt open source był “ślicznie i porządnie napisany (plus trochę komentarzy)”, to żylibyśmy w niemal idealnym świecie ;)
Ja bym czasem nawet zapłacił, gdyby taki typowy kod Open Source miał chociaż jedno zdanie komentarza mówiące co robi dany fragment i dlaczego/dlaczego tak. Oszczędziłoby niejednej godziny spędzonej nad lekturą i zgadywaniem, co autor miał na myśli.
Xion, myślę, że dobrą metodą jest złapanie “ogólnej idei” danego API z dokumentacji (oby ona na to pozwalała) – co to jest, do czego służy, dlaczego jest tak zrobione, jakie są najważniejsze koncepcje, ect., a następnie przejście do opisanej przez Ciebie części praktycznej :).