fbpx

Po 33rd Degree ’13

9 komentarzy

  1. Bardzo dobra była Twoja prezentacja. Mam w zwiazku z nią pytanie, bo przedstawione zostały 4 książki stanowiące tzw. kanon. Jedną z nich były wzorce Gang of Four. A trzy pozostałe ?

  2. Hej, dzięki

    Poniżej książki, ale tak jak starałem się przedstawić: książki, książkami i warto jest znać, ale rozwijanie swojego doświadczenia jest ważniejsze:

    * Pattern-Oriented Software Architecture Vol 4 (i jako uzupełnienie Vol. 1, Vol. 2, Vol. 3), Praca zbiorowa
    * Patterns of Enterprise Application Architecture, Martin Fowler
    * Enterprise Integration Patterns, Gregor Hope

    A poza tym:
    * Essential Software Architecture, Ian Gorton
    * Server component patterns, Markus Volter
    * Domain-Driven Design, Eric Evans
    * Agile Software Requirements, Dean Leffingwell
    * Scaling Lean & Agile Development, Craig Larman
    * Beatifull Architecture, Diomidis Spinellis

    I na deser Lean Architecture Copliena

  3. Można się spodziewać, że za jakieś 2-3 lata ktoś napisze książkę: "Zadawanie pytań niczego nie zmieni – jak pracować z quasi-programistami po kursie NLP, którzy nie znają podstawowych technik i narzędzi inżynieryjnych oraz frameworków mentalnych":PPP

    Później pewnie ktoś zauważy, że nie każdy chce/może zadawać pytania i po pewnym czasie stopniowo znowu wrócimy do przed-agilowego rozdzielenia kompetencji: analityk biznesowy, analityk systemowy, architekt korporacyjny, architekt rozwiązań, architekt systemowy, projektant, developer, koder, tester, wdrożeniowiec. A później znowu ktoś zacznie odciążać, itd, itd, itd…

    Widzę tutaj analogię do sinusoidy ilustrującej skrajności w epokach literackich.

    A nie można by tak mniej faszystowsko, więcej naturalnego balansu i podejścia do indywidualnego człowieka oraz zastanowienia się co, kiedy i po co…

    Ale tutaj mamy znowu błędne koło, bo aby wybrać trzeba mieć z czego, czyli potrzeba doświadczenia. A jak go nie ma, to cóż czynić? Instynktownie ufamy komuś/czemuś co wzbudza zaufanie i próbujemy naśladować… z czasem zacznie wychodzić…

  4. @Sławek

    No, gdybyś był na prezentacji, to wiedziałbyś, że piszesz nie na temat i wbrew temu co mówiłem 🙂

  5. Zgadza się, bo właściwie impulsem do komentarza była poranna lektura artykułu z programistamag – założyłem (sugerując się tytułem), że treść była zbieżna.

    Więc może bardziej ogólny komentarz: skąd wiadomo, że coś czegoś nie zmieni, a co innego coś zmieni?

    Czy stoją za tym badania na większych próbkach i analizy czy jedynie "wewnętrzne przeczucia" (badania metodą naukową są potrzebne po to aby zweryfikować takie zdroworozsądkowe przeczucia jak to, że Ziemia jest płaska i krąży wokół niej Słońce)?

  6. @Sławek
    "Więc może bardziej ogólny komentarz: skąd wiadomo, że coś czegoś nie zmieni, a co innego coś zmieni?"

    Oj, drugiej części zdania to ja nie powiedziałem, ani też nie napisałem. W prezentacji mówiłem o priorytetach: (1) Najpierw świadomie buduj swoje doświadczenie projektowe (2) Potem korzystaj z narzędzi, technologii i tych frameworków mentalnych. Gdy tracisz te priorytet to też robi się z tego (jak ty to ujmujesz)…"zabawa" lecz nie technologiczny lecz na wyższym poziomie. W drugiej części artykułu opisaliśmy po prostu rozwiązania jakie obserwujemy. Nie wymyśliliśmy tego.

    "Czy stoją za tym badania na większych próbkach i analizy czy jedynie "wewnętrzne przeczucia"

    Takie same jak za wszystkimi tymi rzeczami, o których piszemy. Czyli najpierw mamy sformułowanie problemów, następnie sformułowanie hipotezy, potem informowanie o tym ludzi, a gdy się uznają, że te problemy występują u nich, to dopiero zaczynają się badania. O ile kojarzę to taka była ścieżka TDD. Jeśli na inne *-Driven* istnieją "naukowe" dowody, to chętnie poznam. W tej chwili mamy projekty, w których nasze podejście po prostu działa i problemy, które rozwiązało i widzimy w tym bardzo dużą powtarzalność. Czyli jest to mniej więcej tyle ile mieli ludzie o wielkich nazwiskach, a więc własne doświadczenie i priczing. Bez "badań" mogłeś zaufać im. Zaufaj i nam 🙂

  7. Dzięki za wyjaśnienie… chyba jednak na początku nie zadałem sobie trudu aby zrozumieć co autor (Ty) miał na myśli i z pychą podszedłem do tematu myśląc, że rzutem oka ogarnę czyjeś kilkuletnie przemyślenia, po czym zbuduję ich słomiany model aby z łatwością je obalić:PPP

    "szejm on mi"

    No ale dobrze, że miałeś szansę się wybronić. Inni autorzy jej nie mają…

    Ale na poważnie:
    1. cieszy mnie, że obserwuję zmianę stanowiska w stosunku do ostatnich postów: z ataku na x-Driven do "wchłonięcia" i taktowania jako podbudowy do produktu
    2. odnośnie ostatniego akapitu: gdzieś chyba ostatnio czytałem o możliwym błędzie w sytuacji gdy dokonujemy indukcji na podstawie ograniczonych próbek swych doświadczeń a później dokonujemy dedukcji poza te doświadczenia (brzmiało to sensownie)

  8. @Sławek
    "1. cieszy mnie, że obserwuję zmianę stanowiska w stosunku do ostatnich postów: z ataku na x-Driven do "wchłonięcia" i traktowania jako podbudowy do produktu"

    Cwaniak:)Nie było moją intencją krytykować DDD jako takiego, lecz "magiczne myślenie" o nim, które jak wiesz jest gęsto uprawiane; "no silver bullet" po prostu; oczekiwałbym zawsze wyraźnego podkreślania kontekstu: kiedy warto? kiedy nie? kto może? a kto zrobi sobie krzywdę? i że wbrew ambicjom nie wszyscy będą pisać core domain, lecz tylko wybrańcy:)

    "2. odnośnie ostatniego akapitu: gdzieś chyba ostatnio czytałem o możliwym błędzie w sytuacji gdy dokonujemy indukcji na podstawie ograniczonych próbek swych doświadczeń a później dokonujemy dedukcji poza te doświadczenia (brzmiało to sensownie)"

    Tu mnie masz:) Tak, to prawda, ale dyskusja na blogasku czy przy okazji artykułu rzuca mi więcej światła na słabe punkty tego co napisałem. Lepiej pomylić się na blogu niż na konferencji albo w książce.

  9. @1: ja wcale nie obserwuję żadnego magicznego myślenia wokół DDD czy BDD. Wokół TDD owszem, jakiś czas temu bywały takie "zjawiska". A z moich obserwacji w DDD czy BDD wchodzą głównie ludzie/zespoły/organizacje wręcz krytycznie nastawione do branży jako takiej, więc ich nastawienie jest raczej typu: "może coś z tego wykorzystamy i w jakimś stopniu się przyda".

    @2: no tak, każda dobra "technika" to miecz obosieczny, więc świadczy to tylko o Twoim kunszcie i dodatkowo umiejętności jej przedstawienia (mam na myśli ostatni artykuł w programistamag)