Jest wiele podobnych [mb: do asm/cglib] tematów, których znajomość pomaga, ale nie będąc warunkiem koniecznym odkłada się je na półkę na bliżej nieokreśloną przyszłość. Możnaby mnożyć takich perełek bez liku, chociażby programowanie w języku funkcyjnym, albo nawet tak podstawowe jak wzorce projektowe
Zawrzałem. Jak, na wszystkie potwory Mordoru, ktoś kto pretenduje do poczytnego bloggera w obszarze Java EE, może pisać podobne rzeczy?!? (Dla sprawiedliwości dodam, że następne niecytowane zdania myśl rozwijają i nieco łagodzą). Po chwili zastanowienia zdałem sobie sprawę, że rzeczywiście nie trzeba znać wzorców, żeby programować, ale również:
- nie trzeba używać sztućców, żeby się najeść
- nie trzeba znać języka, żeby się komunikować za granicą
- nie trzeba myć zębów
- nie trzeba nosić czapki w zimę, a przy -30 kalesonów
- nie trzeba czytać książek
- nie trzeba się rozwijać
- nie trzeba..., nie trzeba..., nie trzeba...
Żadnej z tych rzeczy nie trzeba. I z pewnością widzimy ludzi, którzy ich nie robią. Od nie robienia tych rzeczy się nie umiera. Przynajmniej nie od razu. Żadna z nich nie jest, wspomnianym przez Jacka, warunkiem koniecznym. Pytanie tylko czy chcemy tak żyć?
[mb: po dyskusji z komentatorami i przemyśleniu sprawy doszedłem do wniosku, że ten akapit to o 1 most za daleko...]
co tobie żywemu na nic, tylko czoło zdobi,
a będzie ich gniotła niewidzialna,
aż zjadaczy chleba w aniołów przerobi
Wpis kończę parafrazą myśli przypisywanej Zamoyskiemu, Modrzewskiemu albo Staszicowi: takie będą systemy, jak ich programistów chowanie!
Pamiętaj, że nieznajomość wzorców nie oznacza, że się ich nie stosuje (tak samo, jak większość osób nie wie, że mówi prozą). Wzorce to tylko (albo aż) próba opisania, wystandaryzowania rozwiązań pewnych klas problemów. Nawet ich nie znając dążąc do czytelnego i łatwego w utrzymaniu, obiektowego kodu samemu się te rozwiązania wymyśli (bo często inaczej się nie da). Na długo przed ich opisaniem i nazwaniem one istniały i były używane.
ReplyDeleteZnajomość wzorców to bardziej kwestia możliwości skupienia się na pracy a nie wymyślaniu po raz n-ty koła (tylko, że trochę bardziej kanciastego)
Uważam, że Twoje przykłady z "nie trzeba" są bardzo nietrafione. Musimy rozróżnić funkcje "programista" i "projektant". Jeśli w firmie obowiązuje model pracy taki, że programista realizuje to co projektant wymyśli - wtedy programista nie musi znać wzorców (choć ułatwiłoby mu to życie). Poza tym zgadzam się z KosciaKiem - pewnie istnieją niezliczone nazwy na rzeczy, które robisz codziennie a tych specjalistycznych nazw nie znasz - można z tym żyć.
ReplyDeleteA od nieużywania szczoteczki do zębów można umrzeć ;) np. zabije nas współpracownik :)
Przedmówcy trafili w sedno, ale i ja swoje dołożę. Przede wszystkim wzorce projektowe to umowa, którą można zmieniać. Zmiany są wręcz wskazane ponieważ wzorce trzeba jeszcze odpowiednio do przypadku stosować, a nie lecieć wg. szablonu. Zresztą przytoczyłeś mocno nietrafione przykłady, które są prawdziwe tylko w naszej strefie kulturowo-klimatycznej.
ReplyDeleteNie o tym jednak chciałem. Można żyć bez wzorców, można tworzyć bardzo dobry soft nie znając wzorców. Dokładniej nie wiedząc, że sposób w jaki piszemy jest gdzieś opisany i formalnie nazwany. Bardzo dużo zależy tu od nauczyciela. Może on przedstawić problemy i rozwiązania w taki sposób, że nie mówiąc o wzorcach uczeń będzie ich naturalnie używał. Zresztą moim zdaniem jest to najlepszy sposób nauki. Popatrz, że języka najpierw się nauczyłeś, a potem poznałeś formułki i nazewnictwo poszczególnych elementów.
Wzorce projektowe umożliwiają nam pracę na zupełnie innym poziomie - zaczyna się inaczej myśleć o kodzie. Moim zdaniem to dużo więcej niż próba opisania tego, co robimy. Pewnie można dojść do takiej sprawności, tylko ile lat by to zajęło? 15? Trzeba "odkryć" dawno odkryte zasady projektowania obiektowego, następnie kolejne wzorce...
ReplyDeleteSkoro tak, to wyrazem profesjonalizmu jest raczej zapoznanie się z wiedzą, która na temat wzorców jest dostępna.
@koper - nawet jeśli programista realizuje to, co projektant wymyśli, to i tak pozostaje spora część kodu, który tworzysz poza projektem projektanta - nie wyobrażam sobie tak szczegółowego określenia "z góry", żeby programista mógł pracować bez choćby podstaw wiedzy o projektowaniu oo.
To się rozwinęła dyskusja. Fajnie! Sądzę, że znajomość wzorców sprawia, że o kimś możemy powiedzieć doświadczony, a przecież doświadczonych inżynierów programowania nie ma(my) wielu wokoło, nieprawdaż? Skoro programują, a nie znają wzorców, to tak mi się nasunęło, że nie jest to warunek konieczny. Ot całe rozumowanie.
ReplyDeletep.s. A skąd pomysł na "ktoś kto pretenduje do poczytnego bloggera w obszarze Java EE" - jak to pretenduje?! To nie jest mój cel, a raczej sposób na dotarcie do celu - wiedza, i to nie w miesiącach, ale tygodniach, czy dniach przez wyważone stwierdzenia na blogu :)
@koper
ReplyDelete"Musimy rozróżnić funkcje "programista" i "projektant". Jeśli w firmie obowiązuje model [taki] pracy (...)"
A jeśli nie? Z tego co widzę to coraz coraz częściej role projektant/programista są łączone. Gdzieś obok jest jakiś megaprojektant z większym doświadczeniem, który wyznacza kierunek implementacji, a programiście daje się dość dużo swobody.
@koziołek
"wzorce projektowe to umowa, którą można zmieniać. Zmiany są wręcz wskazane ponieważ wzorce trzeba jeszcze odpowiednio do przypadku stosować, a nie lecieć wg. szablonu"
Tak najbardziej. Cytując Alexandra
„Każdy wzorzec opisuje problem, który ciągle pojawia się w naszej dziedzinie, a następnie określa zasadniczą część jego rozwiązania w taki sposób, by można było zastosować je nawet milion razy, ZA KAŻDYM RAZEM W NIECO INNY SPOSÓB”
Tylko programistom (albo autorom książek) coś się pomieszało i zaczęli traktować UMLowy diagram wzorca jako dogmat, a nie jako szkic idei.
"Zresztą przytoczyłeś mocno nietrafione przykłady, które są prawdziwe tylko w naszej strefie kulturowo-klimatycznej"
A spodziewałeś się przykładów prawdziwych w każdym kontekście:)? Chciałem pokazać absurd per analogiam, że ten sam efekt można uzyskać wieloma sposobami, ale szeroko rozumiana jakość pracy może na tym ucierpieć
@Krzysztof Jelski
Podzielam w 100%
@Jacek Laskowski
"A skąd pomysł na "ktoś kto pretenduje do poczytnego bloggera w obszarze Java EE" - jak to pretenduje?"
Z tym "pretenduje" to przesadziłem. Chciałem napisać, że przy 600 użytkownikach/dzień to już w pewien sposób kształtuje się opinie i preferencje programistów jest to pewna odpowiedzialność.
Z drugiej strony:
"To nie jest mój cel, a raczej sposób na dotarcie do celu"
Rzeczywiście. Blog wyraża autora i obrazuje jego rozwój. Myślę, że autor powinien robić swoje, oddawać się swojej pasji, wtedy też najciekawiej się go czyta. Zatem cofam akapit o pretendowaniu.
Dla nas programistów wygodne jest traktowanie wzorców jako, parafrazując słowa przedmówcy "standardów rozwiązań pewnych klas problemów". Byłbym szczęśliwy gdybyśmy raz na zawsze skończyli z mitem, że wzorzec projektowy jest szablonem który wyciągamy z woreczka, sprawiamy, wypełniamy i wrzucamy w kod projektu. Sprowadzanie roli wzorców do sposobu na rozwiązanie projektowego problemu jest radykalnym uproszczeniem.
ReplyDeleteWedług mnie pierwsze i najważniejsze wzorce projektowe są częścią języka projektowego i tak powinno być rozpatrywane:
- służą do komunikacji intencji drugiemu człowiekowi (pośredniej - przez kod, bezpośredniej - przy projektowaniu tj. przy tablicy ;)).
- pozwalają budować język wzorców (pattern language), przez co możemy rozwijać/omawiać duże struktury projektowe i interakcje między nimi na bazie generycznych wzorców (Ciekawie piszą o tym Frank Buschmann et al. On Patterns and Pattern Languages jak i Michał Język wzorców).
Wolę - i będę się upierał, że to najlepsze podejście - traktować wzorce jako komunikaty z szablonem, niż szablony z dorzuconym komunikatem.
No i jeszcze to co skreśliłeś, a było ważne, to 'kieruj ich w jak najlepszą twoim zdaniem stronę'
ReplyDelete'Twoim zdaniem' - każdy prezentuje siebie i działa tak, jak jemu wydaje się to najstosowniejsze.
Możesz polemizować z praktykami autora, ale nie można założyć, że istnieje tylko jedyna słuszna droga :)