Jest to pytanie, które często sobie zadajemy - a przynajmniej instynkt samozachowawczy powinien je nam podsuwać co jakiś czas.
Zakładając, że programujesz w Javie oraz celujesz w systemy "korporacyjne" (jednocześnie pomijając dyskusję nad tym wyborem) masz do wyboru szereg kombinacji elementów typu: JEE, Spring, Swing, SWT, JPA, Hibernate, Seam, JSF, Tapestry, Wicket, GWT, Flex... (samych frameworków webowych będzie kilkanaście - nie licząc wynalazków typu krzak). Do tego dochodzi cała masa bibliotek - po kilka na każdy problem (xml, javascript, ajax, security,..). Nie zapominajmy o narzędziach, serwerach i najlepszym pretekście do toczenia świętych wojen - IDE.
Mało tego, nie ograniczajmy się tylko do Javy - książki typu "Pragmatyczny programista" zalecają przecież aby co najmniej raz w roku uczyć się nowego języka:)
Oczywiście, wiedzy nigdy za wiele. Teoretycznie każde nowe skojarzenie może potencjalnie poszerzyć horyzont, otworzyć gdzieś tam w zakamarkach mózgu nową furtkę, odblokować nowy sposób myślenia i zaowocować olśnieniem. Ale podejdźmy do problemu racjonalnie. Zakładając jednak, że czas na research mamy ograniczony musimy dokonywać wyboru - czym się zająć, co zgłębić, co przejrzeć a co pominąć. Tu pojawia się niestety paradoks wyboru grożący zawieszeniem niczym ten przysłowiowy osioł, któremu w żłoby dano.
Spróbujmy jednak spojrzeć z innej strony - poprzez analogię do władania językami obcymi: co jest ważniejsze, to ile znasz języków; a może raczej to czy chociaż w jednym z nich masz coś mądrego do powiedzenia? Albo od innej strony: czy poliglota władającymi 5 językami jest w stanie stworzyć sonet choćby w jednym z nich?
Nieustanne miotanie się pomiędzy kolejnymi dostawami świeżego mięcha (nowe frameworki i biblioteki) może powodować ciągłe dryfowanie na drugim (z pięciu) poziomie kompetencji. Permanentne przebywanie na poziomie advanced begginer zwykle kończy się paskudnym schorzeniem - onanizmem technicznym. Zjawisko to po raz pierwszy zaobserwowano na osobnikach z branży fotograficznej, którym to wydaje się, jakoby odpowiednio duża ilość megapikseli gwarantowała wykonanie dobrego zdjęcia.
Wracając do naszego kontekstu: czy biegła znajomość API 15 frameworków GUI ma wpływ na jego estetykę, ergonomię, usability, intuicyjność i poziom autystyczności?
Dlatego na pytanie "W co się bawić?" odpowiadam zawsze, że najważniejsze są pewne koncepcje, które można sobie zrealizować przy pomocy dowolnych narzędzi. Ważniejsze od platformy technologicznej są: rzetelna analiza (np oparta o archetypy analityczne), giętka architektura, sensowny projekt (np oparty o DDD i wzorce).
Zastanówcie się czy Wasza nowa zabawka na prawdę rozwiązuje jakieś problemy - poza tymi, które sama stwarza.
//=====================
W wolnych chwilach szperam w poszukiwaniu materiałów na temat Domain Driven Design i niestety zauważyłem pewną niepokojącą prawidłowość. Przeważająca większość z nich pochodzi ze świata .NET!
Aby było ciekawej pamiętajmy, że książka Erica Evansa zawierała przykłady w Javie;P
Zwróćcie też uwagę, że nowe teksty Martina Fowlera są poparte przykładami w C#!
Zastanawiam się, czy nie jest przypadkiem tak, ze środowisko Javowe jest cały czas na etapie onanizmu technicznego spowodowanego zalewem mniej lub bardziej udanych narzędzi, bibliotek i frameworków, które po prostu rozpraszają uwagę od kwestii na prawdę istotnych.
W środowisku .NET natomiast wybór jest zdecydowanie uboższy, ale może dzięki temu można szybko skompletować skrzynkę z narzędziami i przejść na kolejne poziomy kompetencji. Pozwala to szybciej dojrzeć do na prawdę istotnych aspektów wytwarzania softu i wreszcie oddać się radosnemu filozofowaniu na przykład na tematy DDD:)
12 komentarzy:
Witam,
Również doszedłem do takich wniosków, obserwując to co się dzieje w polskim światku javowym. Dla mnie oczywiste jest, że zastosowanie 10 bibliotek i 15 frameworków nie jest warunkiem wystarczającym, ani nawet koniecznym aby projekt informatyczny zakończył się powodzeniem. Większość programistów Javy (nie wiem jak jest w .NET) zdaje się nie podzielać takiego poglądu. Świadczą o tym chociażby tematy prelekcji na polskich jugach, gdzie próżno szukać informacji o metodykach, wzorcach i "takich tam", a pełno jest, jak to określił Sławek, "onanizmu technicznego" ;D. Do myślenia może też dawać taki, z życia wzięty fakt, że spotkania warszawskiego juga cieszą się znacznie większą popularnością niż spotkania warsaw design patterns study group.
Pozdrawiam
Maicek
Przeczytałem twój wpis i w sumie trudno się z nim nie zgodzić, chciał go skomentować ale jakoś nie wiedziałem co mnie gryzie ;-)
Odłożyłem problem do szufladki w mózgu, aby dojrzał, to czasami najlepsze rozwiązanie.
A więc ... najgorsze jest myślenie w kategoriach narzędzi, szkieletów, etc. Rozpoczynamy nowy projekt i na pierwszym planie stawiamy jaki szkielet użyć do www, a jaki do zapisu danych do bazy danych, i tak dalej. I zaczynamy naginać wymagania do zastosowanych narzędzi. Im bardziej jesteśmy zaślepieni danym szkieletem tym bardziej zmieniamy wymagania jaki otrzymaliśmy od klienta, a jeśli nie możemy tego zrobić (bo w sumie za co płaci klient?) to zaczynamy narzekać, że analiza do bani, projekt jest nudny, etc.
Nikt nie zastanowi się o co właściwie chodzi w projekcie, co jest jego celem, czy czasem te absurdalne wymagania klienta nie są tylko wymówką dla nas? Nie próbujemy ich zrozumieć, może zostały tylko źle sprecyzowane (zwłaszcza, gdy płaszczyzną dialogu jest język obcy dla obu stron). A czasami wystarczy rozpocząć projekt od modelu, danych i zrozumienia wymagań oraz celu projektu. I okaże się, że szkielet H do zapisu danych nie jest najlepszym rozwiązaniem, lepszym będzie napisanie własnej warstwy DAO albo użycie mniej popularnego szkieletu.
I mógłbym tak dalej, ale chyba rodzi mi się pomysł na artykuł ;-)
Pozdrawiam
--
Łukasz
http://www.lenart.org.pl/
Onanizm techniczny... Piękna nazwa.
Problemem współczesnego świata programistów są ograniczenia. Ograniczenia czasowe i finansowe. Oprogramowanie stało się produktem jak dajmy na to papier toaletowy. Wraz ze wzrostem komercjalizacji oprogramowania rosła presja na programistów by ci specjalizowali się w jednej technologii. Na spotkaniach JUGa omawiamy rzeczy, które w 99% przypadków mają jedno zadanie. Zwiększyć produktywność. Nie ma wielu wesołych odmóżdżaczy typu zabawy z LEGO. Po całym dniu wielu ludzi nie ma już siły by zaczynać coś nowego o ile nie muszą. W sumie ja też używam JavaFX tylko dlatego, że nie mam licencji komercyjnej na Flasha i musiałem zrobić kilka rzeczy.
Dałeś jednak do myślenia...
Podpisuję się obiema rękoma i nogami pod tym tekstem. Dokładnie do takich samych wniosków doszedłem. Wydaje mi się, że każdy programista javy (który ma już troszkę doświadczenia) powinien dojść do takich wniosków po próbie stworzenia przynajmniej w myślach zarysu własnego projektu, który spróbuje oprzeć na frameworkach w javie. Stanięcie przed wyborem frameworka do stworzenia GUI, pomocy dla warstwy biznesowej i trwałego zapisu danych może sparaliżować, a co najmniej doprowadzić do dużego bólu głowy. I tak naprawdę zanim się spróbuje zastanowić nad tym jak ma wyglądać serce aplikacji to zastanawiamy się który z miliarda frameworków wybrać ...
Dlatego uważam, że dobrze jest się rozwijać ponad tym - ucząc się wzorców, głębszego zrozumienia tworzenia ładnego projektu, technik wytwarzania oprogramowania, refaktoryzacji, a frameworki poznawać w zarysie (np. na spotkaniach juga) - a jak przyjdzie do tworzenia w danym frameworku projektu to wtedy będziemy poznawać jego szczegóły.
Stare dobre przysłowie: jeśli coś jest do wszystkiego to jest do niczego :-)
To jest tak naprawdę sprawa wyboru: czy chcemy sami tworzyć przemyślane ładne rozwiązania, a sensowne użycie frameworka to tylko dodatek odciążający pisanie dużej ilości kodu (powiedzmy że ta grupa będzie się nazywała filozoficzno-artystyczna ;-)), czy też chcemy być górnikami którzy chcą tylko odrobić chałturkę używając jak największej ilości frameworków, które w założeniu odrabiają za nas część myślową (ta grupa niech będzie górniczo-hutnicza ;-))
Pozdrawiam
Marek
Witam;
od wieków bywało tak, że na określoną ilość rrzemieślników przypadała jeden majster; na szczęście w informatyce jest jeszcze tak, że stosunek majstrów do rzemieślników jest większy niż w innych zawodach, ale stosunek tan zaczyna się przychylać w stornę rzemieślników;
przeraża mnie to, że rzemieślników zaczyna się zastępować pomocnikami rzemieślnika, a z rzemieślnika robi się majstra; obie te transformacje często bywają bolesne; bo informatyka to nie hutnictwo, że po przepracowaniu 5 lat można stać się majstrem; w branży IT by być dobrym majstrem potrzeba jeszcze iskry, a niektórym rzemieślnikom nigdy nie będzie dane zobaczyć tej iskry;
Pozdrawiam,
Arkadiusz Borek
Co do frameworków: z tego co jest za darmo w Internecie większość jest takiej sobie jakości, więc w praktyce wybór ogranicza się do kilku sprawdzonych (jak Spring, Hibernate, JPA, EJB, JSF, ...)
Jeśli koniecznie muszę użyć czegoś co jest wątpliwej jakości by samemu tego nie pisać, staram się to przykryć jakąś fasadą, by to zamienić na jakąś inną implementację w razie czego.
@koziolek
Nie wiem jak to jest z "czystym" Flashem, ale kompilatory i SDK do najnowszych technologii opartych na Flash Playerze (Adobe AIR i Adobe Flex) są open source, więc możesz ich używać właściwie do czegokolwiek ci się podoba.
Ale za dobre środowisko programistyczne (IDE) do tych narzędzi trzeba już niestety zapłacić.
Z JavaFX jest taki problem, że dopiero niedawno się pojawiło i ma sporo niedociągnięć, więc ja bym nie ryzykował użycia tego do czegoś większego. Zresztą nawet te dema ze strony JavaFX na na jednych komputerach działają dobrze a na innych tak sobie (coś mruga, muli, ...).
@iirekm, co do mulenia FX to prawda. Nie wygląda to jeszcze super.
Co do opensourcowego podejścia do Adobe Flex to nie wierzę, żeby Adobe było aż takie dobre. W zeszłym roku ścigali gościa za to że w witrynie o Adobe Air użył, w nazwie, słowa AirLines.
Oczywiście nie jest tak dobrze jak z Javą. Np. Flash Player chyba nie jest jeszcze open source, ale Flex SDK i Air SDK na 100% są (dokładnie: na licencji Mozilla Public License).
Co do reużywania nazw. Przykład z AirLines jest rzeczywiście żałosny. Ale standardem, nawet w licencjach open source jest to, że raczej nie powinno się się używać nazw zbyt podobnych do już istniejących rzeczy bez zgody autora tej rzeczy.
Przykładowo jeśli chcesz zbudować dystrybucję Linuksa opartą o Debiana nie raczej powinieneś użyć w niej nazwy zawierającej słowo Debian, bo jeśli coś w niej megaspieprzysz, będzie to negatywnie rzutowało również na twórców oryginalnego Debiana.
Dla przykładu Micro$oft wymuszał zmiany nazw nawet na tak niepozornych rzeczach jak: dystrubucja Linuksa Lindows teraz nazywa się Linspire, a C++-owa biblioteka wxWindows teraz nazywa się wxWidgets.
Ja zaproponuje prosty test na 'onanizm techniczny'.
>> Ile miałeś komórek do tej pory?
>> Ile z nich było ci naprawdę potrzebne?
>> O ilu z nich miałeś dobre zdanie gdy je zmieniałeś?
;P
Pozdrawiam.
@Lasu:
4
4
0
I jaka diagnoza?
@Sławek
Jeśli a,b,c to wyniki kolejnych pytań a moim zdaniem w miare dobry wzór na wynik(zakładamy, że 1 to max czyli brak onanizmu...) to:
((b+c) / (2*a))-a/100
uzyskałeś:
46%
ale to względna ocena ;P
i ustawiana tak żebym ja miał w miarę wysoki wynik ;P
a: 3
b: 2
c: 2
63%
Prześlij komentarz