Open/closed principle - zastosowanie na poziomie architektury aplikacji oraz metafory wizualne

"Kod powinien być otwarty na rozbudowę jak kwiat lotosu o świcie i zamknięty na zmiany jak kwiat lotosu o zmierzchu" - jako początkujący projektant natknąłem się kiedyś w jednej z książek na takie "Buddyjskie" wyjaśnienie Open/Closed Principle - jednej z zasad SOLID.

Jednak jak w praktyce zastosować tą zasadę? Czy aplikuje się ona jedynie na poziomie Object Oriented Design czy również na poziomie architektury aplikacyjnej?

W najnowszym artykule "Zarządzenie złożonością przez trójpodział logiki – Open/closed principle w praktyce" opublikowanym na łamach programistamag.pl przedstawiłem swoje przemyślenia na temat OCP, w których integruję:

• ODD, 
• podstawy podejścia funkcyjnego, 
• Building Blocks wchodzące w skład Domain Driven Design,
• architekturę na poziomie aplikacyjnym.

W artykule chciałbym zaproponować Wam swego rodzaju "framework mentalny", który pozwala zmierzyć się ze złożonymi problemami dzieląc logikę na 3 kategorie:

• stabilną - której kod relatywnie rzadko podlega zmianom
• domknięcia logiki - które nie polegają zmianom a rozbudowie
• wybór domknięć - zmiany enkapsulowane w fabrykach (zgodnie z regułą Uncle Boba: "instrukcje switch są dozwolone jedynie w czeluściach fabryk":)

Zatem jest to meta-model, który pozwala na tworzenie modeli problemów zgodnych z OCP. W artykule znajdziecie również propozycję 3 rodzajów wizualizacji graficznej OCP: jedno, dwu i trójwymiarową - w zależności od preferencji kognitywnych...

Artykuł do pobrania (jak zwykle całkowicie za darmo) tutaj: http://bottega.com.pl/artykuly-i-prezentacje

C4 - Zwinne podejście do odkrywania i dokumentowania architektury

W jaki sposób dokumentować architekturę systemu - z jednej strony tak, aby zawrzeć wszystkie potrzebne informacje, z drugiej zaś, aby nie przeładować dokumentacji szczegółami, które czynią ją bezużyteczną?

Pracując z zespołami podczas warsztatów architektonicznych rozpoczynam zwykle od "zadania na rozgrzewkę", którego treść jest krótka: "wyobraźcie sobie, że od jutra dołączam do Waszego teamu; narysujcie proszę architekturę systemu, nad którym aktualnie pracujecie aby szybko i efektywnie wprowadzić mnie w kontekst oraz abym wiedział  gdzie 'włożyć ręce'".

Jak widać treść nie doprecyzowuje o jaki rodzaj architektury chodzi (aplikacyjna, systemowa, wdrożeniowa, etc) oraz w jaki sposób należy to zrobić - po prostu "tak jak robicie to aktualnie w projekcie", a jeżeli tego typu aktywności nie są podejmowane, "intuicyjnie, jak byś to zrobił/zrobiła".


/*************************
Wiem, że zewnętrzny doradca, który chce 'włożyć ręce' w projekt to niespotykany okaz. Większość z nich to osobniki typu krokodyl - małe rączki, duża gęba (czytaj: nic nie robi, dużo gada).

**************************/

Typowe problemy, jakie pojawiają się podczas prób wizualizowania architektury oraz jeden ze sposobów radzenia sobie z takim krytycznym zadaniem jakim jest komunikowanie swoich pomysłów i strategicznych decyzji opisałem w najnowszym numerze programistamag.

Artykuł C4 - Zwinne podejście do odkrywania i dokumentowania architektury jak zwykle do pobrania (jak zwykle free) tutaj: Niezbędnik początkującego projektanta i architekta (zachęcam oczywiście do odwiedzenia empiku lub zakupu wersji elektrycznej całego numeru).


//===================================================

Zainteresowanych zgłębieniem tematu odsyłam do książki Software Architecture for Developers oraz artykułu, który kilka dni temu ukazał się na infoq.

Ze doświadczenia swego oraz zespołów, z którymi pracuję mogę podzielić się jednym rozszerzeniem do C4:  mianowicie w większych systemach Komponenty warto grupować w Moduły (czyli: Context Containers Modules Components Classes). Wewnątrz modułu komponenty "widzą" się wzajemnie, natomiast poza modułem jest widoczny jedynie podzbiór API np. w formie Fasady lub emitowanych zdarzeń (część zdarzeń, które pojawiają się wewnątrz modułu).

Materiały z konferencji 33rd Degree

Oto obiecane materiały:

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego - problemy, strategie, taktyki, techniki i narzędzia






Model jest wszystkim czego potrzebujesz (w aplikacjach biznesowych) - czyli czego nauczyłem się w ciągu 6 lat stosowania i nauczania DDD






Dodatkowo dla osób, które pytały o inne prezentacje:

Architektura Ports & Adapters
Wstęp do DDD: Domain Driven Design - A place for everything and everything in its place
Architektura CqRS: Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw

Projekt referencyjny: DDD & CqRS Sample Leaven


//==========================

Jak zwykle feedback odnośnie prezentacji mile widziany - może być na prv.

Mock czy Stub? Command-query Separation prawdę ci powie.

Testując jednostkowo sieć powiązanych obiektów, dążymy do ich testowania w separacji. Separację osiągamy dzięki stosowaniu różnego rodzaju „dublerów”.

Często bez zastanowienia stosujemy dublery typu Mock. Mocki są relatywnie pracochłonną techniką, która nie zawsze jest uzasadniona - czasem wystarczający jest Stub (Fowler o różnicy pomiędzy Mock a Stub: Mocks Aren't Stubs).


W najnowszym wydaniu programistamag.pl opublikowałem artykuł zatytułowany "Mock czy Stub? Command-query Separa-tion prawdę ci powie." przedstawiający pragmatyczną „reguła kciuka” oparta o paradygmat Command-query Separation, która daje prostą odpowiedź co do typu dublera, jakiego potrzebujemy w teście jednostkowym.

Artykuł tradycyjnie do pobranie (całkowicie darmowo) tutaj: http://www.bottega.com.pl/artykuly-i-prezentacje.

//=======================================

Dla niecierpliwych esencja reguły:

• metody typu query -> użyj Stub
• metody typu command -> użyj Mock

Cztery smaki odwracania (i utraty) kontroli: Dependency Injection, Events, Aspect Oriented Programming, Framework

W styczniowym wydaniu programistamag.pl ukazał się kolejny mój artykuł pt.: Cztery smaki odwracania (i utraty) kontroli: Dependency Injection, Events, Aspect Oriented Programming, Framework.

Tekst jest syntezą wieloletnich doświadczeń i przemyśleń na temat Inverion of Control. Kolejne techniki coraz to silniejszego odwracania kontroli (powiązanego z jej utratą) zostały opisane wg struktury:

• problem - jaki problem chcemy rozwiązać, po co w ogóle odwracamy kontrolę w ten sposób
• idea - ogólna idea zawarta w jednym zdaniu, która pozwoli uchwycić esencję
• motywacja - kiedy mogę zacząć zastanawiać się nad wprowadzeniem tej techniki
• zastosowanie - jakie są dodatkowe zastosowania (poza rozwiązaniem problemu) ew benefity uboczne/wyższego rzędu
• techniki - jakimi technikami implementacyjnymi mogę osiągnąć odwrócenie
• kiedy nie stosować - najważniejsze: gdzie jest granica stosowalności, na co uważać aby nie skończyć z syndromem "nakładania gaci przez głowę"

Artykuł do pobrania (jak zwykle całkowicie za darmo oraz bez rejestracji:) tutaj: http://bottega.com.pl/artykuly-i-prezentacje#receptury

Artykuł jest jednocześnie pierwszym z nowej serii: Receptury projektowe – niezbędnik początkującego architekta.

Intencją serii „Receptury projektowe” jest dostarczenie usystematyzowanej wiedzy bazowej początkującym projektantom i architektom. Przez projektanta lub architekta rozumiem tutaj rolę pełnioną w projekcie. Rolę taką może grać np. starszy programista lub lider techniczny, gdyż bycie architektem to raczej stan umysłu niż formalne stanowisko w organizacji.

Wychodzę z założenia, że jedną z najważniejszych cech projektanta/architekta jest umiejętność klasyfikowania problemów oraz dobieranie klasy rozwiązania do klasy problemu. Dlatego artykuły będą skupiały się na rzetelnej wiedzy bazowej i sprawdzonych recepturach pozwalających na radzenia sobie z wyzwaniami niezależnymi od konkretnej technologii, wraz z pełną świadomością konsekwencji płynących z podejmowanych decyzji projektowych.

Seria z kolei jest początkiem nowego działu w programistamag.pl: Laboratorium Bottega. W dziale tym będziemy publikować podejścia, rozwiązania i techniki, które stosujemy na co dzień w praktyce projektowej, podczas warsztatów i szkoleń oraz coachingu.

//==================================

Artykuł powstał niejako "na zamówienie" jednego z czytelników bloga. Temat był po prostu zbyt obszerny jak na posta.

Jeżeli ktoś chciałby "zamówić" jak temat to proszę pisać śmiało w komentarzach lub na priv: slawomir.sobotka w domenie bottega.com.pl

Nocna zmiana

Mój ojciec pracował niegdyś w trybie zmianowym (zmiana poranna, popołudniowa i nocna). Wynikało to wówczas z utrzymania ciągłości produkcji w fabryce i realizacji planów gospodarki sterowanej centralnie.

Bez obaw - nie zamierzam pisać o polityce i centralnym sterowaniu gospodarką:)

Wielu programistów pracuje po nocach - niektórzy sobie to chwalą, inni przeklinają nie mogąc wyrwać się z tego programu dobowego. Mnie również się to zdarza.

Do tej pory myślałem, że są tego 3 (mniej lub bardziej) powszechnie znane przyczyny (które zapewne się nakładają na siebie):

1. doświetlenie szyszynki przez matryce naszych komputerów, co w efekcie rozregulowuje wydzielanie melatoniny
2. brak energii o poranku (a kumulacja wieczorem) spowodowany rozregulowaniem wydzielania kortyzolu - wynik diety opartej na węglowodanach
3. po prostu rozproszenie przez to co dzieje się dookoła nas (to zależy jeszcze od wyczulenia percepcji któregoś ze zmysłów)

Dziś w mailingu z linkedin dostałem linka do ciekawego artykułu: Why Programmers Work At Night, w którym to autor integruje całość:

• odnosząc się do pierwszeej przyczyny
• odnosząc się do przyczyny trzeciej: nazywa dwa rodzaje skupienia: ludzi zarządzających vs ludzi wytwarzających (coś wartościowego;) Ludzi zarządzający dzielą czas na odcinki, ludzie tworzący kreatywne połączenia muszą "załadować sobie kontekst" - ciekawe zwerbalizowanie tego co każdy jakoś tam intuicyjnie czuje
• podaje kolejną hipotezę: zmęczenia mózgu, która gdy się nad nią zastanowić ma "intuicyjny sens"

Kolejna hipoteza zakłada, że hiper-aktywność mózgu, która nie pozwala się nam skupić na jednej rzeczy i prowokuje do "skoków w bok"  (powszechnie znany problem) znika jeżeli mózg jest dostatecznie zmęczony. Daje to możliwość "załadowania kontekstu" i wykonania na nim operacji.

Zatem wieczorem, gdy jesteśmy już zmęczeni na tyle, że nie możemy się rozpraszać i możemy skupić się na jednym wątku następuje czas, gdy można zrobić coś sensownego:)

Szkoda tylko, że w artykule nie ma odnośników do badań:P

//=======================

O różnicach w wewnętrznym modelowaniu czasu pisałem dawno temu.

A jak to jest w Waszym przypadku?

100 mandaysów za dodanie jednego checkboxa?!?

Standardowa scenka: spotkanie tak zwanego "biznesu" z tak zwanym "IT"; dyskusja nad "małą kosmetyczną zmianą" polegającą na "dodaniu jedynie małego checkboksa".

Na minach "IT" najpierw pojawia się grymas namysłu, a następnie ekspresja (nie mikro-ekspresja) zagłady i katastrofy. W wyobraźni ujrzeli trzęsienie ziemi, która kruszy katedrę, którą budują od x miesięcy/iteracji/cokolwiek. "IT" przełyka ślinę i odpowiada: "zajmie nam to 100 mandaysów".

Mina "biznesu":

Dalszy rozwój scenariusza może przebiegać różnie w zależności o relacji - czy mamy negocjacje klient-dostawca, dział biznesowy-dział it, itd.

Typową dziecinną techniką jest zaniżanie o połowę, ale IT już wie, że "oni zawsze zaniżają", więc defaultowo  zawyża, jednak biznes, wie, że "oni defaultowo zawyżają", więc zaniża 4-krotnie, itd... wszyscy traktują się nawzajem jak by druga strona była opóźniona.

W każdym jednak przypadku "IT" jest na przegranej pozycji. Podczas gdy "my" doskonalimy się we frameworkach, wzorcach i architekturach, "oni" zdobywają siódmy czarny pas w NLP i technikach manipulacji wszystkim czym da się manipulować...

Skąd bierze się takie niezrozumienie powagi zmiany?

Najprawdopodobniej obie strony mają w swoich umysłach inne modele mentalne problemu oraz jego złożoności.

Bywalcy konferencji oraz czytelnicy książek przyprawionych nutką Agile próbują posiłkować się metaforą "Długu technicznego", który został kiedyś zaciągnięty i oto nadeszła chwila, kiedy trzeba go spłacić. "Ale jaki dług, przecież działa!" - możemy usłyszeć w odpowiedzi.

Gdyby istniał wspólny model domeny problemu, wówczas każdy uczestnik projektu "czułby" intuicyjnie powagę zmiany. Ew. naiwne uproszczenia dokonywane z wielu (zwykle racjonalnych) powodów, mogłyby być dokonywane ze świadomością konsekwencji. Uświadomiony dług techniczny.

Dla przykładu: powyżej widzimy model budynku wydrukowany przez drukarkę 3D. Nawet osoba nietechniczna intuicyjnie poczuje, że "postawienie o tutaj (wskazuje palcem na dach) lądowiska dla helikoptera" będzie "nieco" kosztowne. Trzeba przecież znacznie rozbudować konstrukcję nośną albo jeżeli chcemy ją zachować wymienić słupy na tworzywo wykradzione z NASA;)

Spróbujmy osiągnąć taki poziom świadomości gdyby obie strony siadły do: a) rysunków technicznych, b) dokumentów wizji, przeczuć i życzeń zwanych czasem dumnie artefaktami analitycznymi.

Ten przydługi wstęp miał być zachętą do zapoznania się z ostatnim z publikowanej w programistamag.pl serii "DDD krok po kroku": Modeling Whirlpool – iteracyjny proces modelowania (dostęp jest całkowicie darmowy).

Modeling Whirpool jest zwinnym procesem tworzenia wspólnego modelu, który jest zrozumiały również dla Eksperta Domenowego oraz implementowalny 1:1 w kodzie źródłowym - żadnych poziomów abstrakcji, które tworzą luki semantyczne.

//====================================

W styczniowym numerze rozpoczynam nową serię: "Niezbędnik początkującego Architekta", wktórej znajdziecie systematyzację (mam nadzieję) wiedzy bazowej oraz kilka sprawdzonych receptur.

Zainteresowanych DDD i Modeling Whirlpool zapraszam na konferencję 33rd Degree - prezentacja i warsztaty.