Autor wpisu: sokzzuka, dodany: 16.10.2011 12:47, tagi: php, javascript
Dewelopment w Javie fundamentalnie różni się od flow do którego jesteśmy przyzwyczajeni w przypadku aplikacji Pehapowych. Wynika to przede wszystkim z samej „natury” obu platform – PHP jest językiem interpretowanym, natomiast Java kompilowanym. Wobec tego, tworzenie, czy zmiana kodu wygląda zupełnie inaczej.
Jeżeli bym miał podsumować jednym słowem tworzenie kodu w PHP, to tym słowem było by „var_dump”. Pisząc jakiś kod, jesteśmy przyzwyczajeni do tego, że możemy go w każdej chwili zmodyfikować a potem sprawdzić efekty jego działania przy pomocy przywołanej wcześniej metody. Oczywiście są osoby, które w tym celu używają debuggera, jednakże jak wszyscy wiemy, są problemy z jego integracją z różnorakimi IDE i generalnie „var_dump” wydaje się być dość uniwersalnym narzędziem.
Pisząc w Javie, var_dump jest pierwszym z naszych pehapowych przyzwyczajeń, które powinniśmy schować do szuflady. Po pierwsze dlatego, że nie ma odpowiednika takiej funkcji w Javie, a po drugie dlatego, że var_dump driven development nie ma tam żadnych sensownych racji bytu. Dzieje się tak ze względu na czas jaki zajmuje deployment kodu – każda zmiana, jaką wprowadzimy w kodzie Javowym wymaga rekompilacji zmienionych klas i restartu serwera, co może trwać dość długo (np. w moim projekcie taka operacja trwa mniej więcej około 5 minut). Powstały oczywiście pewne solucje by temu zaradzić, takie jak np. podmienianie klas w trakcie działania serwera (Hot Swap), jednakże nie działają one we wszystkich przypadkach (jak dodanie, bądź usunięcie metody jakieś klasy).
Jak więc sobie radzić w takich warunkach ? Po pierwsze, musimy się zaprzyjaźnić z debuggerem. Wkrótce stanie się on naszym najlepszym przyjacielem, na którym będziemy polegać w każdej sytuacji. Debugger jest standardowo wbudowany w każde Javowe IDE, więc nie będziemy mieli żadnych problemów w korzystaniu z niego. Możliwości debuggera są naprawdę potężne i zaczynają się od przechodzenia kodu krok po kroku i podglądania wartości zmiennych, aż po zmianę ich wartości w locie oraz „cofanie się wstecz” w wykonaniu kodu.
Debuggera oczywiście najczęściej będziemy używać przy okazji poprawiania błędów. Jak natomiast sprawa się ma przy tworzeniu nowego kodu ? Tutaj z pomocą przychodzi nam dobrze znana, również z świata PHP technika Test Driven Development. Stosując TDD w kombinacji z debuggerem możemy dość skutecznie i szybko rozwijać nasz kod. Przy czym generalnie obowiązuje zasada, by raczej napisać jak najwięcej kodu przed jego testowaniem – nawet kompilacja testu, mimo, że jest to bardzo mała ilość kodu w porównaniu do całej aplikacji, którą depoloyujemy na serwerze nie jest natychmiastowa i chwilkę trwa. Jeżeli w tej chwili wyobraziliście sobie, że kompilujecie test tylko po to, żeby okazało się, że z jakiś głupich powodów nie działa, to mam dla Was dobrą informacje – dzięki statycznej naturze Javy, wszystkie „głupie” błędy zwykle podkreśli Wam na czerwono Wasz edytor, albo ostatecznie kompilator w momencie kompilacji.
Na koniec jeszcze taka mała uwaga odnośnie plików Javascriptowych. Zwykle bywa tak, że pliki źródłowe JS są częścią naszego Javowego projektu, w konsekwencji one również deployowane są na serwer wraz ze skompilowanymi klasamy Javy. W rezultacie, każda zmiana plików JS wymaga ponownego deployu projektu oraz restartu serwera co jak już wiemy – trwa dość długo. Na szczęście jak zwykle są na to sposoby . Po pierwsze, jeżeli tylko chcemy zmienić coś w JS do celów testowych, to wieść gminna niesie, że narzędzia deweloperskie Chrome’a pozwalają zmieniać Javascript „w locie”. Po drugie, w przypadku InteliJ Idea, istnieje opcja „update resources”, która podmienia tylko obrazki, js i inne tego typu pliki dość szybko, bez potrzeby restartu serwera.
Tym radosnym akcentem kończę ten artykuł i ogłaszam, że jest to już ostatni wpis z serii „Kierunek Babilon”, oczywiście dalej zamierzam pisać o PHP i Javie, ale już w trochę innym kontekście.