Programiści NIE mają problemu z komunikacją

Taka rozkminka.

Jakieś 17 lat temu dałem sobie wmówić, że programiści mają problem z komunikacją i powinni się szczególnie reformować w tym zakresie. Ostatnimi czasy pewne wydarzenie rzuciło mi nieco inne światło na tę kwestię, a było to tak...

Prowadziłem rozmowę z jednym programistą, który jak tylko mógł bronił się przed zesłaniem na szkolenie z komunikacji. Uparcie twierdził, że on nie potrafi się komunikować, nigdy nie potrafił, nie chce i nie będzie.

No, nie zmuszam - pomyślałem i już miałem zakończyć grilowanie biedaka, gdy moją uwagę przykuła pewna rzecz - obrączka na palcu.
- Masz żonę? - zapytałem
- Mam.
- Hmmm, ale to siłą ją zaciągnąłeś przed ołtarz? Porwałeś z domu?

Okazało się, że luba mojego rozmówcy dobrowolnie i bez żadnego przymusu dała się namówić na zamążpójście. Zdziwiło mnie to, po tym jak odmalował swoje kompetencje komunikacyjne.

- A macie dzieci, jeśli wolno spytać...?
- Mamy. Dwie córki.

I znów zdziwienie. Wyobraź sobie, że ten programista nie tylko rozmawia ze swoimi córkami, ale i bierze czynny i aktywny udział w ich wychowaniu.

Nie wiem jak Tobie, ale mnie po tym dialogu wszystko się przestało kleić. No, do cholery jeśli ktoś potrafi przekonać drugą osobę do zawarcia formalnego związku, to chyba potrafi się komunikować, nie?

Poza skończoną liczbą przypadków szczególnych, jeśli inżynier żyje w związku albo utrzymuje kontakty z rodziną, znajomymi, czy chociażby wspólnotą mieszkaniową, to spokojnie można założyć, że posiada podstawowy set kompetencji społecznych, które zapewniają mu przetrwanie.

Tak więc, ten cudowny kontrprzykład na zawsze pogrzebał tezę, że programiści nie potrafią się komunikować. O co więc chodzi z tą łatką, którą się nam przykleja? Otóż przyczyny leżą zupełnie gdzie indziej.

Uporządkowanie i praca głęboka

Programiści preferują pracę według określonego porządku. Wszystko to, co zaburza ten porządek jest postrzegane negatywnie.

Praca wykonywana przez inżynierów ma najczęściej charakter głęboki (chodzi o naturę rzeczy, nie o ocenę tej pracy). Oznacza to, że wymaga ona operowania dużą ilością szczegółów, dużego skupienia oraz skrupulatności.

Można zaryzykować stwierdzenie, że programowanie to nadawanie pewnego porządku danym, które są nieuporządkowane.

Odcięcie się od bodźców zewnętrznych sprzyja takiej pracy. Rozpraszacze i wrzutki z boku ją zaburzają. Łamanie porządku pracy jest odbierane jako bałagan. Powoduje też nieprzyjemne doznania w ciele. Serio!

Lejek sprzedażowy

Programiści są umiejscowieni niemal na samym końcu lejka sprzedażowego. Natomiast biznes jest niemal na samym początku tego lejka.

Aby do programistów trafił jeden temat do realizacji, po stronie biznesowej należy "obrobić" tych tematów z pięćset. Z tego powodu w biznesie czas upływa subiektywnie szybciej niż w IT - więcej się dzieje. W IT rozdłubujemy jedną rzecz do ziarnistości atomu, bo tak trzeba, aby ją porządnie zrobić.

Coś niespodziewanego

- O w mordeeeee! Nie przeczytaliśmy zapytania do końca! Zaoferowaliśmy coś, czego nie mamy!

Nie ma co się czarować, gdy się dużo dzieje, takie błędy się zdarzają. Będąc na górze lejka, biznes ma dużą ekspozycję na tego typu błędy. Niestety będąc na dole lejka, IT ma z takich błędów za***te koszty.

Bounded Context

Gdy pierwszy raz wybrałem się do mechanika z moim Suzuki Maruti '92, usłyszałem "bla, bla, blaa, osiemset trzydzieści", gdzie Maruti kosztował 1,3k.

Gdy grupa ludzi pracuje razem, zaczyna wykształcać się lokalna gwara branżowa. Upraszcza ona komunikację w grupie, utrudnia poza grupą.

Wnioski praktyczne

No, dzięks, że wytrwałeś aż do tego momentu, bo wnioski ww. refleksji są dość ciekawe:

1. Trudności komunikacyjne na lini BIZ-IT nie wynikają z tego, że ktoś (IT) jest mniej usklilowany miękko. Wynikają przede wszystkim z "architektury organizacyjnej", w której ludzie zostali umieszczeni
   
2. Analizowaną w poście "architekturę organizacyjną" można nazwać "klient-usługodawca". Jak długo będziemy ustawiać ludzi w relacji klient-usługodawca tak długo będą występować problemy komunikacyjne. I choćbyśmy ludzi przetrenowali miękko na wszystkie strony - nic to nie da. Problemy komunikacyjne są wpisane w relację klient-usługodawca, a nie w naturę poszczególnych ludzi
   
3. Z programistami jest wszystko w porządku - ich umiejętności miękkie są w normie. Zapewniam, że gdy programista idzie do mechanika samochodowego doświadcza tych samych trudności komunikacyjnych co osoba z biznesu odwiedzająca programistę
   
4. Należy zmienić priorytety. Zamiast wałkować 101 technikę udzielania feedbacku, należy reorganizować struktury współpracy tak, aby pozbyć się relacji klient-usługodawca
   
5. work in progress
   

Odpowiedź: 42

Świat IT jest pełen odpowiedzi...

• Jak pisać czytelniej? Dzielić algorytmy i metody na mniejsze kawałki. Pisali o tym McConnell, Beck, Martin.
  
• Jak radzić sobie implementacją złożonego procesu? Można wydzielić współpracujące ze sobą obiekty. Pisał o tym Meyer.
  
• Jak okiełznać złożoność domenową? Można zastosować wyróżnić bounded contexts itd. Pisali o tym Evans, Vernon, Dahan, Young i inni.
  
• Jak dokładniej testować? Pisać mniejsze testy skupione na konkretnym zachowaniu. To, akurat mówią wszyscy...
  
• Jak poprawić trafność oszacowania? Można dekomponować na podzadania. Pisał o tym McConnell.
  
• Jak ogarnąć mega złożone interfejsy UI? Podzielić ma mniejsze lepiej zarządzalne kawałki i skomunikować między sobą. Zrobili np. w robotlegs framework.
  
• Jak skalować agility? Zacząć od skalowania produktu i podzielenia go na mniejsze podprodukty. Mówili o tym Poppendieckowie.
  
• Jak poprawić swoją efektywność. Skupić się na mniejszej ilości spraw. To tłuką na konferencjach bez litości.
  
• Jak uniknąć kosztownego refaktoringu i mądrzej ogarnąć architekturę? Wydzielić odpowiednio małe microserives. Mówił o tym Young.
  
• itd.
  

Wymienione odpowiedzi są pożyteczne, ale chyba gdzieś umknęło pytanie. Otóż podstawowym pytaniem, z którym boryka się uniwersum IT jest pytanie o granulację. Ile to jest mało, ile dużo, a ile odpowiednio?
Jaki serwis będzie OK, a jaki za duży? I w jakim stopniu zależy to od kontekstu?

Kłopot w tym, że żadne z wymienionych odpowiedzi, ani chyba też żadne, które znamy, nie adresuje tego podstawowego pytania.

Twórz wartość, zamiast ją kupować

Tym razem o finansach - tak dla odmiany.

Jakieś dziesięć lat temu wkręciłem się w temat zarządzania finansami osobistymi, oszczędzania, inwestowania, itd.
Straciłem trochę pieniędzy i o to przedstawiam mój własny, krwią i łzami nawożony wniosek: Twórz wartość zamiast ją kupować.

Z książek czy kursów na temat finansów poznałem strategie inwestowania o różnych poziomach zarąbistości.
Wszystkie one mają jedną rzecz wspólną - KUPUJ!

Każą kupować obligacje, akcje, fundusze, kruszce, ziemię, monety, ubezpieczenia, obrazy, wino albo zwierzaki, a od czasu do czasu wrzucić coś na lokatę. Ostatecznie chodzi o kupowanie z nadzieją na wzrost wartości, który jak wiem z własnego doświadczenia, bywa, że nie nadchodzi.

A teraz będzie jeb z dzidy i mój kontrprzykład. Napisałem parę książek.
Do tej pory czytelnicy kupili ich 5905 (papierowe, ebooki i wypożyczenia). Moje łączne koszty na ich przygotowanie to ok. 2300zł, które poszło na obrazki do książek i na okładki. Z oczywistych względów nie wyceniam poświęconego czasu.

Biorąc do obliczeń wyłącznie honorarium autorskie, mój "wynik inwestycyjny" wynosi 751%. Jeśli dodatkowo dodałbym do zysku wartość usług, które sprzedałem za pomocą tych książek, trzeba by zacząć dopisywać kolejne zera. W dodatku ta liczba może tylko wzrosnąć.

Który doradca inwestycyjny tyle gwarantuje?

Programista to wymarzony zawód, który pozwala na niczym nieograniczone tworzenie wartości. Twórz ją!

A Word on Motivation

Don't blame people, avoid punishing them, empower people, let them to Drive themselves, motivate people positively. Have you heard about this stuff? I have a lot. Basically I agree, but...

A friend told me a story. His is the owner of some organization from the IT industry. Once the organization cooperated with dishonest supplier who hadn't paid the VAT tax related to their businesses for couple years. (in Poland VAT tax is the way how the sate sicks up the poorest subjects, but it's another story).

During the tax control they obviously discovered the trick an punished the supplier. As a consequence of the case weak invoices were mandated to be removed from the accounting system. Technically there was no business between my friend and the supplier. But my friend deducted VAT tax, so Tax Office request him to refund it. Two million Polish zloty (it's over $500k) in 14 days...well, this is the law.

But he survived, found the win-win solution with Tax Office. Was he motivated positively? I don't think so.

When I think about my business carrier (it has took 7 years since I started our company) I went through lots of fuckups. There was: tiny organization, little bit larger one, almost bankruptcy, UE project with a lot of madness around, we were cheated by a salesman we trust and so on and so forth.

When some investor was unsatisfied because of project one blamed personally me, I was refused so many conferences I even remember, when we started DevCastZone.com I received heaps of emails from frustrated users with many reasons: err 404, to slow, to expensive, I expected something else and so on and so forth.

You know, for the last eight years I was motivated mostly negatively by the environment I worked in. Really! Of course there were days, workshops, coaching sessions when I met attendees needs and it was fucking awesome. These days are like a pearls - they are worth to challenge every single day.

Despite all these things I sill have fun at my work. Actually thanks to these events I achieve all stuff in my work: businesses, books and articles written, presentations made, friends. So, what the hell the idea with positive motivation??

Bug-Driven Development

- Ale tego nie było w specyfikacji.
- Ok, ale to przecież oczywiste, że powinniście to zrobić.
- Jak to oczywiste?
- No, kurcze...

Niezliczoną ilość razy z pewnością słyszałeś powyższy dialog.
Chyba wciąż chodzi o to samo - o niedostateczne sprecyzowanie wymagań, a potem o zepchnięcie odpowiedzialności. Przyczyny wspomnianego stanu rzeczy są znane i maglowane wciąż na nowo: trudności komunikacyjne, brak czasu, brak zaangażowania klienta itd, itp. Pewnie chodzi o to, że z wymienionych powodów wymagania nie zostały dobitnie i jednoznacznie sformułowane.

A jeśliby tak ustawić sposób współpracy, że brutforsowo wymusi jednoznaczne formułowanie wymagań? który nie będzie polegał na dobrej woli i chęci zaangażowania, ale po prostu uniemożliwi sformułowanie niejednoznacznych wymagań? I tu jest właśnie miejsce dla Bug-Driven Development :)

No, wyobraź sobie następującą scenę:

Zaczyna się rozmowa z PO na temat nowego sprintu
- Skończyliśmy! - krzyczy uradowany Zespół
- Jak to? Pokażcie!

Zespół z namaszczeniem odpala przeglądarkę, na której widać...białą przestrzeń.
Zmieszany PO jąka - Ale tu nic nie ma...
- Jak to nie ma? - odpowiada pewny jak McGyver siebie Zespół.
- No, nie mogę się zalogować.
- Ok, mamy pierwszy bug - zespół skrupulatnie notuje coś na kartce.
- Czekaj, wrócimy za dziesięć minut.
- ?? - odpowiada PO.

Po chili grupa programistów wpada do sali spotkań.
- Już mamy! - wrzeszczą uradowani.
- Czyli co?
- Jak to co? Soft dla Ciebie! Co z tobą, Łosiu?

Odpalają przeglądarkę z pięknym ekranem logowania. PO z nadzieją w oczach loguje się do systemu i....
- Aaaa! $^!@#&(!
- Czy coś nie tak? - pytają z zaciekawieniem programiści.
- A gdzie panel użytkownika, do cholery!!

Na to szczęśliwy jak nigdy dotąd SM:
- Ok, chłopaki mamy drugiego buga!, spadamy.
Po czym rzuca przez ramię, do oniemiałego PO.
- Pół godzinki i jesteśmy, buźka!

i tak przez najbliższe cztery tygodnie.


To tak, pół żartem, pół serio, ale czuję, że coś w tym jest :)

Haft krzyżykowy, kaligrafia, jazda na rowerze

Znajomy umieścił na FB wycinek z CV, które zawierało sekcję "Zainteresowania" jw.
Uświadomiłem sobie, że sam wpadłem tę durnotę wymyśloną przez nie wiem kogo, ale wciąż nakręcaną przez pseudoporadniki kariery. Wyróżnij się! Za wszelką cenę!

No, bo co to są właściwie te zainteresowania albo hobby? Czym ja się interesuję? Diabli wiedzą, chyba wszystkim. Ale tak nie wolno napisać, bo w podręczniku stoi napisane, że jak coś jest do wszystkiego, to jest do niczego... Niech no się zastanowię. Teraz większość czasu spędzam z rodziną, zmieniam pieluchy albo przetaczam piłkę z jednego końca pokoju na drugi, parę lat temu całymi dniami czytałem książki, jeszcze parę lat wstecz grałem na elektryku covery Metliki aż do opuchnięcia nadgarstka. Gdzie są te zainteresowania? Co mam wpisać w cv, żeby nie wyszło banalnie?

No, to może co lubię? Lubię marchewkę na przykład. Czasem poczytam, czasem pobiegam, czasem pójdę do kina, czasem upiekę chleb, czasem bloguję, czasem w zimie jeżdżę na nartach, lubię naprawy domowe i pielenie ogródka, lubię prowadzić szkolenia i spotykać się z klientami, lubię grzebać w legacy code, lubię porządki. A najbardziej chyba lubię wieczory, gdy w bilansie dnia wychodzi mi, że dobrze wykorzystałem swój czas.

Tak więc wychodzi na to, że nie mam jakiś szczególnych zainteresowań. Czujne oko rekrutera z pewnością poznałoby się na mojej płytkiej i nieciekawej osobowości i żadnej pracy pewnie bym nie dostał. Następnym razem wpiszę sobie: trzyletni pobyt w klasztorze i służbę w Legii Cudzoziemskiej.

Wydaje mi się, że termin "zainteresowania" i "hobby" wymyślili Ci, którzy mieli to nieszczęście, że nie znosili tego, czym się na codzień zajmowali. Gdyby lubli to, co robią, to nie musieliby wymyślać "hobby", żeby odreagować. Po za tym aktywność każdego z nas jest zbyt bogata, zmienna w czasie, żeby ująć ją w trzy (czyt.: magiczna liczba zainteresowań w cv) pozycje zainteresowań.

Wydaje mi się, zainteresowaniem każdego zdrowego człowieka jest..."życie", podejmowanie aktywności, które sprawiają, że wieczorem czujesz, że "to było TO", cokolwiek owo "to" dla Ciebie oznacza.

Zatem mam taki wniosek: jeśli masz hobby, na które nie masz czasu - zmień zajęcie. Poważnie! Po co się męczyć i dodatkowo robić to, czego się nie cierpi? Spraw, aby twoje obecne "hobby" stało się Twoim głównym zajęciem. To nic innego jak kierowanie sie maksymalnym Business value. O to chyba chodzi, no nie? A potem w sekcji "hobby" w swoim cv wpisz: "Moje życie" :)

Wiedza odpływa z organizacji

Nie wiem, czy kryzys rzeczywiście był, czy go nie było, ale widzę skutki plotek o kryzysie. Departamenty IT dostały bana na zwiększanie kosztów stałych, czyli na zatrudnianie programistów. Backlog rzadko kiedy się skurczył, więc aby sprostać wymaganiom biznesu zastosowano najbardziej narzucające się rozwiązanie outsourcing.

Outsourcing jest ok, bo nie zwiększa kosztów stałych organizacji, lecz powiększa koszty projektów i jako taki jest widoczny w innej kolumnie arkusza kalkulacyjnego. W skutek tego "finansowego" zabiegu niby mamy programistów, ale ich nie mamy. Proste? :) No, na tym poziomie abstrakcji, to wszystko wydaje się proste i korzystne. Przyjrzyjmy się implementation details.

Skąd organizacja outsourcuje programistów? Ano od ousourcera, tylko że nie nazywają się już oni programistami lecz konsultantami i kosztują odpowiednio więcej. Excelowa kolumna kosztów projektu jest bardziej elastyczna niż kolumna kosztów stałych, więc w czym problem? W tym, że taki outsourcing ma swoje zasady:

• Konsultanci wykonują większość prac programistycznych
• Etatowi programiści nadzorują pracę konsultantów
• Jeśli dla konsultanta przez pewien czas (np. tydzień) nie można znaleźć zajęcia to trzeba go zwrócić do puli
• Konsultanci działają na zasadzie stateless, więc jeśli znów potrzebujemy konsultanta, to dostajemy nie poprzednio zwróconego, lecz pierwszego wolnego

W skutek w/w praktyk etatowi programiści przestają programować, a zaczynają "zarządzać". Właściwie to ich główne zadania polegają na:

• przyuczaniu konsultantów i nadzorowaniu ich pracy
• routowaniu maili między biznesem a konsultantami i ew. zewnętrznymi podwykonawcami
• przygotowywaniu dokumentacji wynikającej z procedur organizacyjnych, których początki są tak stare, że chyba już skamieniały
• analizowaniu logów systemowych, gdy coś się wywali

Gdy przez dwa i więcej miesięcy nie rozwijasz kodu systemu, nad którym pracujesz, to zagadnienia, które wcześniej były oczywiste powoli zasnuwa mgła niepamięci. Dzień po dniu niepostrzeżenie zaczynasz wkraczać na orbitę około systemową z perspektywy której hurtownia danych i hurtowania makaronów to prawie jedno i to samo. Wszak i to i to jest hurtownią.

Utrzymujący się taki stan rzeczy ma następujące skutki:

• Konkretna wiedza systemie, jego architekturze, problemach w kodzie migruje od programistów etatowych do konsultantów
• Rotacja konsultantów sprawia, że wiedza techniczna w ogóle odpływa z organizacji
• Nikt nie jest odpowiedzialny za rozwój architektury, która zaczyna dryfować
• Dla podkreślenia: nie, etatowi programiści nie zajmują się architekturą (choćby nawet takie były początkowe ustalenia) bo niby co to oznacza? rysowanie umli? etatowi programiści zajmują się organizowaniem zajęcia dla konsultantów
• Jakość kodu zaczyna się dramatycznie obniżać
• Dryfowanie architektury sprawia, że z każdą funkcjonalnością coraz trudniej dodawać nowe i modyfikować istniejące
• W pewnym momencie pojawia się osobliwość, czyli taki moment, w których za pomocą metod inżynierskich, architektury nie da się już naprawić; o czym pisałem trochę tutaj

Nie oddawaj core własnego biznesu

Z perspektywy organizacji, która nie jest softwarehousem takie postępowanie ma sens. Tworzenie oprogramowania nie jest core biznesu, więc spokojnie można je oddać komuś do podwykonania. Mam jednak wrażanie, że próbuje się z jednej strony mieć marchewkę i zjeść marchewkę. Z jednej strony chcemy sami tworzyć soft, aby móc go dostosowywać i być elastycznym (kolejne po "architektura") słowo-wytrych. Z drugiej strony chcemy outsourcować, aby zapłacić za to jak najmniej. Ostatecznie wydatkujemy więcej za kiepski produkt.

Przeciwdziałanie

Można przeciwdziałać odpływowi wiedzy z organizacji przestrzegając pewnych zasad. Oczywiście nie jest to tak banalne jak poniższe sformułowania. Najtrudniejsze jest przecież wdrożenie i konsekwentne trzymanie się n/w wytycznych. O następujących rzeczach warto jednak pamiętać:

• zatrudniaj konsultantów na długo i nie zwracaj ich do puli, gdy przez kilka dni nie mają nic do roboty
• dbaj, aby konsultantów było nie więcej niż etatowych programistów
• etatowi programiści pełnią tymczasowe role teamliderów w miniprojektach powoływanych na wdrożenie konkretnych funkcjonalności
• teamliderzy implementują jakąś część ticketów (tak, wiem, że kiedyś twierdziłem inaczej, ale złagodziłem nieco to zdanie
• dbaj, aby działał nazwany proces rozwoju architektury, czyli podczas dostarczania, można realizować itemy techniczne

Ostatecznie idealnym rozwiązaniem jest wyodrębnienie core domain i w jej rozwój zaangażowanie etatowców, a supporting domains oddanie do konsultantów bądź podwykonawców. W tym przypadku, prócz samej analizy może pojawić pewien NP-trudny problem: core domain nie ma albo nie istnieje ona w takiej postaci, aby wymagała by prac programistycznych. Słowem nie ma sensu utrzymywać zespołu programistycznego. Ups! Przymierzam się do wpisu nt. analizy domen, chwilowo godzina jest zbyt późna:)

Nowy rok, nowy Michał:)

Po głębokich przemyśleniach doszedłem do wniosku, że myśl Hanibala Albo odnajdziemy drogę albą ją zbudujemy, która dotąd była moim mottem i firmowała też poniekąd ten blog, już do mnie nie przemawia:) Teraz zaczynam kolejny etap sponsorowany przez hasło: Bądź obecny, weź to, co jest i rób to, co mówisz

DDD checklist

Gdzieś mi przemknął taki test ma to, czy DDD na sens w Twoim projekcie:

JEŚLI: Myślisz o swojej aplikacji jako o warstwach
I JEŚLI: Na samej górze jest zawsze web
I JEŚLI: Na samym dole jest zawsze baza danych
TO: Nie masz do czynienia z czymś takim jak "domena"
TO: DDD jest Ci niepotrzebne

[update: 28.02]
JEŚLI: Wyobrażasz sobie architekturę swojej aplikacji jako "stos"
I JEŚLI: Na samej górze tego stosu jest zawsze web
I JEŚLI: Na samym dole tego stosu jest zawsze baza danych
TO: To prawdopodobnie dziedzina, którą informatycznie wspierasz nie jest zbyt złożonna
TO: Wprowadzenie Domain Model za pomocą DDD będzie nieadekwatne do potrzeb i zbyt kosztowne

Ponieważ uwielbiam metafory, szukałem jakiejś trafnej historyjki dla tego kejsu i przyszło mi do głowy coś takiego:

Serce: Słuchaj, Mózg, czy armata to dobra broń?
Mózg: Hmmm, no bardzo dobra...jeśli chcesz zdobyć Fort Knox, ale jeśli chcesz po prostu przetrzepać skórę paru cwaniakom, to powinieneś zastanowić się nad czymś tańszym.

Obiektowo orientowana pogoń za własnym ogonem

W tym poście. Sławek napisał komentarz:

W tym wszystkim brakuje mi jednej rzeczy, bez której refaktoryzacja przypomina szalony bieg z tasakiem. Refaktoryzacja do czego? Nie do wzorców, nie do SOLID, nie do Clean Code...

Do postaci, która oddaje zrozumienie problemy (dziedziny). Z moich obserwacji tego właśnie brakuje, ten i problem w pewnych klasach systemów próbuje rozwiązać DDD.

(...)


Zacząłem odpisywać i się rozpisałem, wiec przerzucam do posta.

A wiecie, że w systemach a'la Oracle Forms, bez obiektowej warstwy aplikacyjnej, rzadko występują problemy właściwe systemom, w których się tę warstwę wepchnęło? Z pewnością widziałem mniej systemów niż niektórzy z czytelników, trochę jednak widziałem, i takich i takich.

Nie trzeba zastanawiać się nad rozszerzalną (czy to cokolwiek sensownego znaczy?) architekturą, bo architektura jest mocno narzucona; nie trzeba kombinować jak uzyskać możliwość szybkiego wdrażania, bo mamy to prawie out of the box.

Programiści PL/SQL raczej nie narzekają na jakość kodu, wydajność, złożoność przypadkową i intencjonalną. Radzą sobie. Czasem nawet dziwią się, że w OO-świecie są tego typu problemy. Już słyszę obiekcje, że OOP nadaje się do dużych systemów. Akurat te największe, z którymi miałem do czynienia, były db-centric.

Być może ludzie wymyślili DDD, frameworki (sygnalizowałem to wcześniej) inne takie tam tylko po to, aby poradzić sobie z problemem, który sami wygenerowali wymyślając OOP. Po co więc brnąć w coś i rozwijać metody, skoro to coś samo w sobie zostało oparte na niewłaściwych (zbyt skomplikowanych) założeniach?

Dalej, logiczna prostota (i idące za tym ograniczenia) technologii typu Forms, sprawia że łatwiej skonkretyzować oczekiwania użytkowników. Dlaczego? Bo technologia z góry narzuca, co jest dozwolone, a co nie jest i nie pobudza fantazji zbyt wieloma opcjami do wyboru. Może i działa to nieco odwrotnie: oto już IT nie "modeluje" świata biznesu, lecz daje biznesowi parę formatek, nazwy pól, a biznes sobie projektuje co i jak ma działać.

Co właściwie, wymienione na początku DDD próbuje rozwiązać (mowa tu o tej części książki, w której mamy bloki budujące)? DDD chce stworzyć koncepty, dzięki którym będzie można łatwiej opisywać rzeczywistość i jednocześnie przekładać ten opis na model obiektowy. Trochę nadużywamy słowa "model". Model to model - opis działania rzeczywistości taki jak np. poniższy. Same prostokąciki, strzałki, napisy itd. Tak jak na rysunku.



Teraz ten model można przenieść do świata IT na wiele sposobów. Można za pomocą obiektów (co robi DDD), można przełożyć na związki encji, nawet na pliki - wszystko jedno. DDD to tylko narzędzie do przekładania modelu do IT w jakiś specyficzny sposób. DDD to tylko jedna możliwości. Czy aby na pewno OOP jest najprostszym sposobem na przenoszenie modelu do IT?

Prócz standardowego trójkąta projektu, zespół podlega jeszcze jednemu ograniczeniu: kompetencje programistów. Gdybyśmy w każdym zespole mieli samych Ericków Evansów, to w warstwę aplikacyjną, OOP, DDD można wchodzić w ciemno. Najczęściej jednak raz na jakiś czas zdarzy się jakiś "quasi-Evans", a większość to jednak Janowie Kowalscy.

Jakiś czas temu, 60-letni uczestnik szkolenia Wzorce Projektowe. Powiedział: "Nie bardzo rozumiem, po co te wszystkie klasy? Kiedyś to, co się pisało, trzeba było porządnie nazwać i to zazwyczaj rozwiązywało problemy" I o to chodzi: grunt to prostota.

Megasoftwarecraftsmanshipper

Pojawił się nowy rodzaj programisty:

megasoftwarecraftsmanshipper - podchodzi do odziedziczonego kodu z wyższością ocierającą się o pogardę; z kpiącym uśmiechem patrzy na nazwy zmiennych, design, stan testów; sam dla siebie jest największym autorytetem; podstawowymi narzędziami poprawy jakości czyjegoś kodu jest naprzemienne stosowanie wyśmiewania i poniżania; megasoftwarecraftsmanshipper to powiernik i głosiciel Prawdy objawionej przez Święte Community; według najnowszych badań postawa taka jest objawem choroby zwanej megasoftwarecraftsmanshippentem

A więc jest nadzieja! Można to leczyć! Zebrałem kilka receptur ozdrowieniowych, więc jeśli znasz jakiegoś megasoftwarecraftsmanshippera, to koniecznie poleć mu jedną z nich, bądź nawet wszystkie. Skutków ubocznych nie stwierdzono.

Receptura Szczepana i Bartka

Szczepan Faber i Bartosz Bieńkowski w swoim wystąpieniu nt. TDD dają następującą recepturę: "musicie pozbyć się swojego Ego". Dalej wyjaśniają, że chodzi to pozbycie się zdradliwej myśli, że "mój kod jest najlepszy". Zaleca się powtarzanie tego rozumowania na głos rano i wieczorem.

Receptura Lequiera

który rzekł: "Gdy się wierzy, że posiadło się prawdę, trzeba wiedzieć, że się w to wierzy, a nie, że się to wie". Na podstawie tej światłej myśli zaleca się rozważanie następującego zdania: "Konwencja kodowania, architektura, frameworki, język programowania to tylko moje przyzwyczajenia i moje ulubione podejścia. Sprawdzają się w bardzo określonych kontekstach, a poza nimi się nie sprawdzają. Wszystkie inne alternatywy mają tyle samo sensu co te, wyznawane przeze mnie". Oczywiście powtarzamy rano i wieczorem.

Receptura percepcji błędu

Jeśli coś nie działa, w pierwszej kolejności szukaj błędu we własnym kodzie. Zadawaj sobie pytanie: "Co mogłem zrobić albo czego nie zrobić, że to przestało działać?" Rano i wieczorem to dawka minimalna. Optymalna to: przy każdorazowym wystąpieniu błędu.

Receptura "To ma sens"

Megasoftwarecraftsmanshipper przede wszystkim powinien sobie tak głęboko, że aż do szpiku kości uświadomić, że ludzie którzy stworzyli kod odziedziczony naprawdę NIE byli kretynami. Dla wielu megasoftwarecraftsmanshipperów będzie to trudne do zaakceptowania, ale jeśli tylko założą, że "istniała racjonalna przyczyna, dla której ten kod wygląda tak a nie inaczej, że ci którzy go napisali zrobili wszystko, co mogli w sytuacji w jakiej musieli pracować", to być może zaczną zauważać, że: była jedna doświadczona osoba, która dostała "darmowych" (obecnie już chyba nie:)) studentów, kod został przeportowany 1:1 z jakiegoś egzotycznego języka, to jest poprawiona wersja, która wyglądała jeszcze gorzej, itd. Megasoftwarecraftsmanshipper może wtedy zacząć uświadamiać sobie, że "to naprawdę ma sens"!

Cytat miesiąca

Źródło: Wikipedia

Bardzo często zainteresowania takie obracają się obecnie wokół komputerów do tego stopnia, że zespół Aspergera nazywany jest w krajach zachodnich "geek syndrome", czyli chorobą maniaków komputerowych. Spowodowane jest to tym, że komputery zostały stworzone z myślą o składowaniu i przetwarzaniu informacji, co jest ulubionym zajęciem ludzi z tym zespołem

Nowy czelendż

Postanowiłem spróbować czegoś nowego. Będę prowadził zajęcia na studiach podyplomowych na kierunku Komunikacja i sprzedaż w branży IT w Uczelni Łazarskiego w Warszawie. Mój przedmiot to Zbieranie i analizowanie wymagań klienta. Szczególnie niecierpliwie czekam na pracę z resztą wykładowców. Uczelnia zgromadziła naprawdę doborową kadrę - górna półka coachów i trenerów biznesu działających na naszym rynku (mb: rzecz jasne mam na myśli swoich współwykładowców). Ciekawe jak będzie? :)

Craftsmanship nie dla wszystkich?

Big szacun dla tych, co wrzucają po 2 posty dziennie. Ja opierałem się wyrzutom sumienia aż do tej pory. Chyba właśnie regularność i rytm są tu kluczowymi rzeczami. Wiele razy przychodził mi pomysł na wpis, ale odkładałem na później. Pomysł tracił na wyrazistości, blakł, aż całkiem zupełnie znikał. No nic, pożyjemy zobaczymy.

Nawiedziło mnie następujące przemyślenie czy Craftsmanship jest dla wszystkich? Jeśli mówimy o ciągłym doskonaleniu warsztatu to jak najbardziej. Jako myśli filozoficzna i reguła życia zawodowego jest warta rzetelnego praktykowania. Zmieńmy jednak punkt widzenia i wejdźmy w buty szefa działu developmentu.

Ilu minimalnie czarodziei potrzebuję?

Umiejętności kosztują. W doświadczonego osobnika, który ma wysoko rozwinięte cechy pożądane u adepta Craftmanship
trzeba dużo zainwestować. Zupełnie naturalnie przychodzi do głowy pytanie, czy wszyscy programiści muszą być świetni.
Z całą odpowiedzialnością muszę powiedzieć, że nie. Tu niestety rządzi ekonomia. No i rozkłady statystyczne. Jeżeli na dwudziestu programistów przypada jeden czarodziej, który będzie strzegł ładu i składu w architekturze, to zespół spokojnie da sobie radę. Jeszcze raz bez ogródek: nie wszyscy programiści są tyle samo warci, nie we wszystkich warto w równym stopniu inwestować, można zadowolić się określoną liczbą ludzi przeciętnych albo nawet słabych i ile tylko będą potrafili napisać to, co im się każe. Jeśli w kilkusetosobowym dziale uda się zebrać powiedzmy 6-8 osobowy dream team, który wymyśli superrozwiązanie każdego problemu, to reszta tłumu może spokojnie robić swoje.

Jak uniezależnić się od kodera?

Kiedyś przy jakieś okazji powiedziałem "nie da się programisty zastąpić skończoną liczbą studentów; to tak jakby prezesa chcieć zastąpić skończoną liczba konsultantów". Trzeba uściślić tę opinię "nie każdego programistę można zastąpić skończoną ilością studentów". Tych pojedynczych najlepszych pewnie nie, ale znakomitą większość jak najbardziej. Potrzeba tylko, aby niezastąpieni tworzyli takie architektury, przygotowywali takie półprodukty, takie frameworki, w których nie trzeba za wiele myśleć, wystarczy kodować. W ten sposób można już traktować większość programistów jako wymienny zasób. Doprowadzenie do tej sytuacji to kwestia odpowiedniej strategii, czasu i pieniędzy.

Bezpańscy czeladnicy

Trzymajmy się dalej tej perspektywy. Za Craftmanship idzie zapomniany już niestety model Mistrz-Czeladnik. Uczeń szukał swojego mistrza, u boku którego praktykował. Myślę, że wielu programistów nie ma od kogo się uczyć. Albo nie spotykają na swojej drodze wystarczająco kompetentnych i cierpliwych mistrzów albo wtłoczeni w rolę wymiennego kodera, włóczą się od firmy do firmy. Tacy właśnie bezpańscy czeladnicy. Zdobędą trochę doświadczenia to tu to tam na własnych błędach, nie mając nikogo u boku kogo wskazał by im kierunki rozwoju i doradził.

No, na czarno dzisiaj trochę. Ale tak mnie dopadło:)

Inspiracja fantasy

U jednego z lubiących mnie na facebooku znalazłem cytat z jednej z najlepszych sag fantasy jakie czytałem. Mowa rzecz jasna o Sadze o Wiedźminie. Cytat pochodzi z dzieła Jaskra, w którym wyjaśnia czytelnikowi, na czym polega prowadzenie działań wojennych.

Poznałem w życiu wielu wojskowych. Znałem marszałków, generałów, wojewodów i hetmanów, triumfatorów licznych kampanii i bitew. Przysłuchiwałem się ich opowieściom i wspomnieniom. Widywałem ich schylonych nad mapami, rysujących na nich różnokolorowe kreski, robiących plany, obmyślających strategie. W tej papierowej wojnie wszystko grało, wszystko było jasne i wszystko funkcjonowało we wzorowym porządku. Tak być musi, wyjaśniali wojskowi. Armia to przede wszystkim porządek i ład. Wojsko nie może istnieć bez porządku i ładu.
Tym dziwniejsze jest, że prawdziwa wojna - a kilka prawdziwych wojen widziałem - pod względem porządku i ładu do złudzenia przypomina ogarnięty pożarem burdel.

Pomyślałem złośliwie, że gdyby zdefiniować następujące zmienne:

• marszałek, wojewoda, hetman, triumfator, wojskowy := menadżer
• wojna, bitwa := projekt
• wojsko, armia := zespół projektowy

to sumie też ma jakiś sens...

Planowanie to nie problem

To miał być długi, pracowity wieczór. Nazbierało mi się sporo zadań do wykonania. Gdy tylko drzwi hotelowego pokoju za mną się zamknęły, przystąpiłem do działania według najlepszych prawideł sztuki planowania. Komputer zostawiłem w spokoju dla uniknięcia rozproszeń. Czystą kartę zapełniała powoli acz konsekwentnie rosnąca lista tudusów. Lista to została następnie starannie przepisana na nową kartkę, w już posortowanym według priorytetów porządku.

Tak uzbrojony, włączyłem notebooka i rozpocząłem działania. Pomyślałem, że zerknę co tam przed wyborami. Nic nowego. Ok, zabieram się do pracy. Ponieważ najpierw musiałem odszukać mail na podstawie, którego mam coś tam opracować - odpalam TB. Zaraz po uruchomieniu klienta poczty, automatycznie ściągają się czekające maile. No, tylko rzucę oczkiem....O, siostra przysłała mi przepis na zupę dyniową. Hmm, że niby ja mam to gotować? O, Grzesiek odpisał na facebooku. O, ktoś ma dla mnie ofertę pracy...ups nie, tam już pracowałem. Kurcze, ten mail to mnie wkurzył, muszę odpisać, bo nie zdzierżę!

Ok, jeszcze tylko załączę piosenkę na rozpęd i już się zabieram do pracy. Odnajduję na youtube stary teledysk Ronniego Dio. Naprawdę, koleś miał głos jak dzwon. Szkoda, ze zmarł. Kiedy to było? A, 16 maja..o wtedy, kiedy urodziny mojej siostry. Tak na marginesie o co chodzi z tą zupą dyniową? Jeść mi się zachciało. Jedno jabłuszko tylko, bo wieczór. Na noc jeść nie zdrowo. Nightwith - włączę cicho. O, ciekawe czy są jakieś nowe wtyczki do foobar2000. Zaraz zaraz, która godzina. Północ? A moje zadania? Szlag!

Zadania dryfują

Już nie raz łapię się na tym, że planowanie to bułka z masłem w porównaniu z konsekwentnym podążaniem za planem. Obstawiam, że gdyby nawet najmizerniejsze plany były realizowane w 100%, to osiągalibyśmy znacznie więcej niż obecnie. Kłopot w tym, że zaraz po przystąpieniu do działania, naszą uwagę przykuwa wiele rzeczy, które wywołują serię skojarzeń, które to z kolei kuszą nas do zajęcia się wszystkim tylko akurat nie tym, czym planowaliśmy się zajmować.

Ktoś mi kiedyś powiedział, że przedmioty "wysyłają" do ludzi oferty. Przedmioty starają namówić Cię, abyś z nich skorzystał, wszedł w interakcję. Ładna metafora i chyba oddaje istotę rzeczy. Największym wrogiem dotrzymywania terminów (zakładam, ze sensownych :)) nie jest wcale nieumiejętność planowania, lecz nieumiejętność realizowania planu. Cierpimy na chroniczny brak umiejętności skupienia się i utrzymywania skupienia, choć dawni belfrzy z twardą trzciną w łapie powiedzieliby, że to brak samodyscypliny.

Wielokrotne powtarzanie opisanego na wstępie schematu prowadzi do nawyku silnego jak u mitycznego psa Pawłowa. Po jakimś czasie okazuje się, że po prostu nie sposób zacząć pracy bez godzinnego onetowego rytuału.

Weź pigułkę

Przyczyna tkwi chyba w pigułkowatej mentalności otaczającego świata. Zewsząd wmawia się nam, że istnieją proste rozwiązania na wszystkie problemy. Wcale nie potrzeba pracy nad sobą, wyrzeczeń, poświęcenia. Wystarczy wziąć "pigułkę"np:. przeczytać książkę, która odkrywa sekret, pójść na szkolenie, gdzie wleją nam wszystko do głowy albo pić ziółka i chudnąć 5kg/tydzień. Ostatnio nawet widziałem w TV reklamę, której sens można oddać następująco: "żryj do woli, jak się rozchorujesz to weź pastylkę X i żryj dalej".

Nie inaczej jest z planowaniem i wykonywaniem zadań. Karykaturalnie wykrzywiając powiedzenie "chcieć to móc" wmawia się nam, że po zastosowaniu sprytnych tricków, poradzimy sobie z każą ilością zadań. Gdyby wyobrazić sobie dobę jako koło, to każde z jego wycinków oznacza część doby przeznaczoną na coś.

Przeciętny człowiek ma zajęte całe koło, bo zawsze coś tam robi mniej lub bardziej aktywnie. A tu nagle każą nam sprawić, aby kąt pełny miał więcej niż 360 stopni. Brutalna prawda jest taka, że aby zacząć coś robić, coś trzeba przestać robić albo czegoś robić mniej. To nie żadne hokus pokus, tylko zdrowy rozsądek.

Niestety zaczynamy wierzyć w taką pigułkowatą naturę rzeczywistości. Zaczynamy oczekiwać, że można coś osiągnąć bezkosztowo, że można zjeść ciastko i mieć ciastko jednocześnie. Efektem nie jest jednak natychmiastowy i oszałamiający sukces lecz frustracja, miernota i rozczarowanie.

Terapia

Leczenie z nadmiernego pobudzenia otaczającym światem, które sprzyja rozproszeniu i odciąga od tego, co rzeczywiście należy zrobić, jest możliwe.
Wydaje mi się, że warto zacząć od paru praktyk ograniczających wspomniane oferty przedmiotów:

• Zadania zaczynaj od pierwszego na liście. Nie od RSS, newsów, maili itp. (wrzucanie RSSów do listy się nie liczy:))
• Wyłącz komunikator, klienta poczty i włączaj je tylko w ściśle ustalonych porach (wiem, że to czelendż, ale warto spróbować)
• W kliencie poczty wyłącz automatyczne odbieranie poczty przy starcie i co 10 minut
• Z umiarem stosuj smartfony. Naprawdę nie musisz być on-line non stop.
• Jeśli już koniecznie musisz poczytać newsy zrób to na końcu listy zadań, nie na początku
• Słuchanie muzyki podczas pracy nie jest takie dobre jak się o tym mówi; Jest ok przy prostych powtarzalnych zdaniach. Jeśli zdania wymagają kreatywności, to angażują prawą półkulę mózgu, tą samą co muzyka. Zatem Twoje zadanie konkuruje o zasoby fooobarem2000
• Jak najszybciej zamykaj zadania i jak ognia unikaj zostawiania ich rozgrzebanych i niedokończonych. Lepiej jest mieć 50% czegoś konkretnego niż 100% świetnych niezrealizowanych pomysłów

Dług techniczny, opcja call czy lokata długoterminowa?

Standardowy kłopot z refaktoryzacją: my chcemy, a z góry leci głośnie NIE! Łaj? W moim odczuciu są dwie główne przyczyny. Pierwsza wynika z definicji. Skoro refaktoryzacja, to "ulepszenie wewnętrznej struktury oprogramowania, bez zmiany jego funkcjonalności", to skoro nie dodaje funkcjonalności, a zatem nie dodaje wartości biznesowej, a zatem nie pozwala efektywniej zarabiać, a zatem nie warto jej wykonywać. Podsumowując - kasa.
Drugi problem jest związany z przekonaniem, że jak już refaktoryzować, to rewolucyjnie i musi to zająć mnóstwo czasu. Skoro czasu to i pieniędzy. Za drogo i nie warto tego robić. Znów kasa. Nie zbłądzę zbytnio, gdy stwierdzę, że tarcia o refaktoryzację obijają się o pieniądze.

Kłopot z metaforami

Aby zdobyć choć trochę posłuchu u biznesu community wykombinowało jak na razie dwie metafory: Długu technicznego oraz (najświeższa) Niezabezpiecznonej opcji typu call.
Gdy się w nie wczytać, to każda z nich mówi mniej więcej coś takiego: Pamiętaj biznes-ludku, że jak nie będziemy refaktoryzować, to stanie się COŚ strasznego!. Obie metafory odwołują się do rzeczy, która jak nam się zdaje, najlepiej do biznesu przemówi, czyli do pieniędzy.

Dług techniczny mówi: zabraniając refaktoryzacji zaciągasz duże zobowiązanie, w kolejnym wydaniu rollujesz ten dług kolejnym długiem, i kolejnym, i kolejnym. W końcu zbankrutujesz i klops.
Niezabezpieczona opcja call mówi: nie pozwoliłeś na refaktoryzację, nabyłeś najbardziej ryzykowny instrument finansowy we Wszechświecie. Jedyne co możesz robić, to się modlić.

Skoro te metafory tak dokładnie wyłuszczają konsekwencje zaniedbywania jakości kodu, to dlaczego nic się nie zmienia? Nieco światła rzuca na to psychologia społeczna, wg której bardziej preferujemy natychmiastową gratyfikację niż długoterminowe korzyści oraz bardziej obawiamy się nieprzyjemności bliższych i namacalnych niż odległych i nieco abstrakcyjnych.

Podsumowując, twierdzę, że obojętność na prorefaktoryzacyjne błagania ma następujące przyczyny

• korzyść z refaktoryzacji jest zbyt odroczona w czasie
• korzyść z refaktoryzacji bardzo trudno wykazać jest w pieniądzach
• zaniedbanie refaktoryzacji ma negatywne skutki w bliżej nieokreślonym kiedyś; a dopóki programiści mogą ratować projekt, to go ratują; czasem bardzo długo
• robienie tak, "aby działało" ma szybkie odczuwalne korzyści

Powyższe fakty sprawiają, że na refaktoryzację przychodzi zgoda, gdy już w zasadzie jest za późno. I wtedy to już na prawdę jest od cholery roboty.

Lokata długoterminowa

Dobitna metafora dla refaktoryzacji powinna charakteryzować się następującymi cechami:

• korzyści można łatwo wyrazić w pieniądzach
• korzyści finansowe są szybko odczuwalne, powiedzmy w perspektywie tego samego albo najbliższego wydania

Zauważmy, że jest to metafora pozytywna. Dług techniczny oraz opcja call były metaforami negatywnymi w takim sensie, że straszyły tym, co złego się wydarzy jeśli nie będziesz grzeczny. Nasza nowa metafora jest sformułowana pozytywnie, bo pokazuje korzyści jakie uzyskasz, gdy będziesz się dobrze sprawować.

Szukałem tego typu metafory również w świecie finansów (no, bo dlaczego nie?) i znalazłem ja w postaci lokaty długoterminowej. Korzystając z tej metafory można w stronę Biznesu perorować, że:

• refaktoryzacja jest jak wpłata pieniędzy na lokatę, już po pierwszym okresie rozliczeniowym następuje kapitalizacja odsetek i otrzymujesz swój procent
• im dłużej oszczędzasz tym więcej zyskujesz
• żeby osiągnąć maksymalną korzyść musisz wpłacać regularnie
• jeśli zerwiesz lokatę, właściwie tracisz większość zarobku
• no i w przypadku refaktoryzacji nie ma podatku Belki:), same korzyści!

A jak pokazać korzyści finansowe?

Tu popuszczam trochę wodze fantazji. Można spokojnie założyć, że na refaktoryzacyjnej lokacie odsetki procentują razem z początkowym kapitałem. Weźmy sobie zatem wzorek:

gdzie: V - obecna wartość, V0 - początkowy kapitał, r - stopa procentowa, n - liczba okresów rozliczeniowych.

No, to teraz spróbujmy zinterpretować wzór w kontekście refaktoryzacji. Vx - liczmy dalej w pieniądzach, n - liczba iteracji, a r? Skoro finansowo odpowiada to zyskowności (potencjałowi wzrostu kapitału?), to co jest tego odpowiednikiem w projekcie? Mam feeling, że coś z jakością kodu, ale nie bardzo wiem co.

Poza wzorcami projektowymi

To jest odległa kontynuacja artykułu Język wzorców.

Nie pamiętam już u kogo, ale wyczytałem, że jedną z przyczyn powstania wzorców projektowych, było rozwiązanie różnego rodzaju bolączek technologicznych albo bolączek konkretnych języków programowania. Zacząłem się nad tym zastanawiać. I tak:

• Null Object - bo w C++ referencja musi być zainicjowana; wyeliminowane przez Java, C# (nieścisłość, @see Komentarz pod postem Chrisphera Daniela)
• State - bo implementacja maszyny stanów oparta o tablicę wskaźników do funkcji oraz serię switch/case
jest dość trudna w utrzymaniu
• Interpreter - jaki tam wzorzec;)? sposób na parsowanie ustrukturyzowanych gramatyk i tyle; wyeliminowane przez tony bibliotek narzędziowych
• Flyweigh - bo nie ma kasy na więcej pamięci
• Command - w C# wykoszony przez delegaty (mam na myśli ten kontekst użycia, w którym robimy execute(), a nie przechowujemy komendę, aby ją potem handle() )
• Właściwie wszystkie wzorce opisane w Core J2EE Patterns i PoEAA - zastąpione przez biblioteki, frameworki i technologie

Czym zatem są wzorce projektowe? Mówi się, że rozwiązaniami typowych problemów. Rozwiązaniami, które wg Alexandra, można stosować za każdym razem nieco inaczej (nieco inna implementacja), ale otrzyma się poprawne rozwiązanie konkretnego problemu. W porządku - może postęp technologiczny modyfikuje tylko implementacje wzorców, lecz idea zostaje podobna. Może jednak nie - czy w wzorzec zamknięty w wszytywne API biblioteki wciąż jest wzorcem, czy tylko zwyczajnym narzędziem pomocniczym?

Jak powstają?
Skąd się biorą i jak powstają? Istnieją trzy elementarne zasady postępowania, które prędzej czy później doprowadzą do dobrego rozwiązania obiektowego:

Przestrzegaj opodwiedzialności

Jeśli nie potrafimy czegoś nazwać, to prawdopodobnie nie rozumiemy jak to działa. Nie znamy odpowiedzialności tego czegoś. W swoim kodzie dbaj o to, aby każda: zmienna, metoda, klasa, interfejs, pakiet, moduł miały określoną tylko jedną opodwiedzialność, która będzie wyrażona nazwą

Enkapsuluj

To, co podlega zmianom, powinno zostać opakowane (w metodę lub w klasę - w zależności od potrzeby). Enkapsulacja pozwala na łatwiejsze zarządzanie zmianą w kodzie. Nie mówiac już o testowaniu.

Preferuj kompozycję ponad dziedziczenie

Związki używania czynią kod bardziej elastycznym, czytelnym i testowalnym. Dodatkowo pozwalają na rozszerzanie funkcjonalności kodu run-time, a nie tylko poprzez przekompilowanie.

Jeśli przestrzegamy tych zasad, prawie na pewno powstanie dobry kod. Jest jeden warunek: trzeba stosować je bardzo skrupulatnie. Żadnego wkuwania nazw wzorców, diagramów, definicji, itd. Zamiast tego: żelazna dyscyplina w stosowaniu w/w zasad.

Wymienione reguły są dość niskopoziomowe, w całościowy proces ujmuje koncept, który nazwaliśmy roboczo Nautralnym porządkiem refaktoryzacji.

Koncept Nautralnego porządku refaktoryzacji

Pisał już o tym sporo Mariusz w artykułach: NPR - Idea rysunkowa, NPR - pod lupą, NPR: Compose Method, NPR: Extract Method, NPR: Refaktoryzacja do wzorców, NPR: Ewolucja architektury, więc nie będę się powtarzał.

Powtarzając konsekwentnie ten proces i stosując wspomniane już trzy metody, otrzymujemy naprawdę porządny kod. Zaczynają pojawiać się dobre rozwiązania. Dość często są to znane wzorce projektowe.

Morfizmy w kodzie
Zauważmy, że w charakterystyka wzorca projektowego zawiera między innymi Motywację/Intencję, Kontekst, Problem. Według definicji wzorzec to rozwiązanie problemu w danym kontekście. Ale przecież nieustanie zmienia się zarówno kontekst, jak i nasze zrozumienie problemu. Wszystko się zmienia!

Aktualne dobre rozwiązanie, które przywykliśmy nazywać wzorcem projektowym, jest tak naprawdę lokalnym optimum, jakieś funkcji (powiedzmy, że Funkcji kodu) w której zmiennymi są przynajmniej: Kontekst oraz Problem.

Tak zwany wzorzec rozwiązuje problem tylko na chwilę, dopóki Funkcja kodu nie ulegnie zmianie, a optimum nie wystrzeli w inną stronę. Mamy wiec do czynienia nie tyle z wzorcami, co z optymalnymi morfizmami w kodzie (niech, Ockham mi wybaczy). Zmiana Funkcji kodu, po której programując się ślizgamy powoduje, że dany morfizm przestaje być optymalny i musimy poszukać nowego optimum właśnie poprzez refaktoryzację.

Optymalne morfizmy

Wnioski
Czy poza gimnastyką umysłu wypływają stąd jakieś wnioski? Owszem, kilka.

1. Istnieje nieskończenie wiele optymalnych morfizmów w kodzie - ponieważ zakres zmienności Problemów oraz Kontekstów jest również nieskończony; w związku z tym publikacje i dywagacje na temat nowych wzorców projektowych nigdy się nie skończą
2. Refaktoryzacja musi trwać - ponieważ Funkcja kodu wciąż się przekształca, wciąż musimy poszukiwać optymalnych morfizmów; zaprzestanie tych działań spowoduje takie zniekształcenie tej funkcji, że znalezienie optymalnych morfizmów będzie niemożliwe i trzeba będzie ją wyrysować na nowo - czytaj napisać system raz jeszcze
3. Ważniejsze jest zdyscyplinowane posługiwanie się wspomnianymi wyżej zasadami i procesem refaktoryzacji niż szastanie kolekcjami nazw wzorców
4. Nie jest możliwe stworzenie czegoś takiego jak patterns language (por: On Patterns and Pattern Languages), bo optymalne morfizmy wciąż się przekształcają podążając za zmianami Funkcji Kodu

"żeby tak wszystko ze wszystkiego wynikało"

Problem dotyczy zarządzania zmianami w wymaganiach. Cytując rozmowę, oczekiwanie brzmi następująco Proszę Pana, chciałbym tu mieć takie narzędzie do zarządzania wymaganiami, w którym będę mógł sobie je definiować, żeby tak wszystko ze wszystkiego wynikało. Na przykład jak przyjdzie jakaś zmiana, to żebym od razu wiedział gdzie, co i jak, w której klasie należy zmienić. Rozumie Pan?

No, niby rozumiem...

Zarządzanie? Dobre sobie!
Weź pierwszą z brzegu mądrą książkę, która ma w tytule Requirements Management. 99% tekstu jest o (w kolejności ilości stron): dokumentowaniu, zbieraniu (ale raczej skąd? niż jak?) i analizie wymagań. I gdzieś tam pod koniec parę akapitów o tym, że change happens. A kluczową atrakcję wieczoru, czyli management zbywa się truizmem w stylu trzeba wdrożyć proces zarządzania zmianą.

Czyli co to jest to zarządzanie? Sądzę, że:

• składowanie wymagań
• dowiadywanie się jak nowe wymagania wpływają na istniejące
• wykrywanie konfliktów w wymaganiach
• dowiadywanie się jak zmiany (w skrócie: CR) wpływają na istniejące wymagania

Hipertraceability
Czy oczekiwanie wyrażone w początkowej historyjce ma sens. Jest w nim ukryta jakaś potrzeba, ale zastanawiam się czy ma sens. Można zaprzęgnąć EA albo coś droższego i wyklikać wszystkie możliwe powiązania tak, "żeby tak wszystko ze wszystkiego wynikało". A co w przypadku zmiany? Oprócz dowiedzenia się co z czym się wiąże, znów trzeba będzie poklikać. Sądzę, że utrzymywanie takiej macierzy powiązań to robota na kilka pełnych etatów. Wątpię, czy warta świeczki. Wątpię, czy jest nawet warta ogarka.

Gdzie leży problem z traceablility?
Duży system jest zazwyczaj podzielony na moduły, które są rozwijane przez osobne podzespoły, którym przewodzą dedykowani liderzy. Gdy przychodzi zmiana dotycząca jednego z modułów, może ona jakiś wpływ na inne. Jeśli dane lider na to wpadnie to świetnie. Jeśli nie, to sprawa wypłynie prędzej czy później.

Niszczące działanie zmiany nie jest wynikiem braku hiepertraceability, braku jedynie poprawnego narzędzia czy wynikiem braku kompetencji. To przede wszystkim problem organizacyjny i komunikacyjny. Liderzy nie wiedzą co się dzieje w inny modułach, analizują zmianę lokalnie bez odniesienia do całości (której nie znają) i nie komunikują się ze sobą wystarczająco.

Product Manager
Brakuje osoby (Product Manager), która będzie spinać system całość. Od razu pada pytania: czy od strony technicznej, czy biznesowej? Nie chodzi to, żeby przez Product Managera przechodziły wszystkie CR, a on będzie podejmował je analizował i podejmował decyzje. Nie może tak być, bo zaraz zrobi się z niego ktoś w stylu Solution Architect, w którym będzie powoli skupiała się kluczowa wiedza o systemie i który będzie wąskim gardłem procesu zarządzania zmianą. (a niech tam, to zatrudnimy mu asystentów i już, czemu nie? :) )

Product Manager jest raczej kimś kto dba o to by komunikacja pomiędzy liderami i zespołami przebiegała płynnie. Oczywiście będą trafiać do niego wszystkie CR, będzie posiadał dużą wiedzę biznesową i będzie doskonale znał produkt. Jego główny zadaniem będzie troszczenie się o produkt jako całość i pomaganie poszczególnym zespołom w komunikowaniu się z innymi i dogrywaniu wszelkich zmian.

Zauważmy, że nie jakaś konkretna osoba analizuje wymagania, wykrywa konflikty i wpływ nowych na istniejące. Rzeczy te wykrywane są w procesie komunikacji pomiędzy poszczególnymi zespołami i liderami.

Czy Product Manager będzie miał co robić? Jeżeli mówimy o produkcie, który ma wdrożenia dla poszczególnych klientów, to z pewnością tak. Odpowiedzialności Product Manager to:

• dbanie o rozwój produktu jako całości
• dbanie o loose coupling między produktem a wdrożeniami dla poszczególnych klientów :)
• przyjmowanie CR
• pomaganie liderom i zespołom w komunikowaniu się między sobą
• uzgadnianie i mediowanie w przypadku wprowadzania zmian w produkcie

Strażnik architektury i ewangelista

Zauważyłem pewną cechę różnicującą projekty, w których kod woła o pomstę do nieba, od tych, które są bardzo przyzwoicie napisane. Różnicą, którą mam na myśli nie jest bynajmniej skala projektu, skomplikowanie domeny, język programowania, czy nawet wiek projektu. Zauważyłem, że w zespołach, w których kod jest dobrze utrzymany objawia się osoba, która nakręca cały ten pęd ku ciągłemu doskonaleniu. Nazwałem go Strażnikiem architektury.

Nie posługuję się nomenklaturą Scotta Amblera, który mówi o Właścicielu architektury, gdyż sądzę, że chodzi o nieco inną rolę. Mimo koncepcji Właściciela architektury, jako roli, a nie stanowiska (zapewne z inspiracji Product Ownerem) trudno uciec od skojarzeń, że właściciel coś posiada. Tego typu rola, bardzo szybko przekształca się w klasyczne stanowisko architekta, który jest wyrocznią w sprawie architektury, od czego Scott Ambler chciał uciec.

Strażnik architektury jest jednym z członków zespołu, który ma "parcie" na ciągłe doskonalenie projektu oraz ewangelizuje zespół w zakresie jakości tworzonego kodu. Zaobserwowałem, że zazwyczaj Strażnik architektury jest inicjatorem i koordynatorem następujących aktywności w zespole:

• wprowadzanie standardu kodowania
• zmiana/wprowadzanie systemu kontroli wersji/zmian
• wprowadzenie code review
• wprowadzenie procesu continuous integration
• wprowadzenie/zmiana podejścia tworzenia kodu np:. DDD
• wprowadzenie/zmiana technologii/frameworka
• tworzenie warstw abstrakcji na niektóre z używanych bibliotek, w celu uniezależnienia się od nich
• zmiana architektury w celu poprawienia wydajności (i nie chodzi tylko do dopisanie paru SQLi i założenie paru indeksów)

Zazwyczaj Strażnik architektury objawia się sam. Po prostu jest ktoś taki w zespole, od kto stopniowo staje się autorytetem dla innych. Uczy ich, prowokuje do wyjścia poza utarte schematy, stymuluje do rozwoju. Zazwyczaj pomaga rozstrzygnąć sporne kwestie dotyczące technicznej strony projektu. Doradza i nieformalnie akceptuje nowe pomysły albo je odrzuca (albo jak mawiają znajomi z pewnego sympatycznego zespołu "spsikuje" pomysły ;) )

Kilka punktów nt. zaobserwowanej charakterystyki Strażnika architektury.

• jest pasjonatem
• poświęca wolny czas na czytanie blogów, literatury, rozpoznawanie technologii
• testuje nowe rozwiązania (często projekcie, w którym uczestniczy)
• często staje się liderem z nadania (poprzez stanowisko) i bywa, że to go "zabija" bo tonie w papierkach, budżetach i spotkaniach
• mimo szeregowego stanowiska z jego zdaniem management się liczy i potrafi przelobbować praktycznie co tylko chce
• szybko wyciąga wnioski z pomyłek, ale się nie zraża
• jest motywowany głównie "na cel"

Pojawia się jednak pewne niebezpieczeństwo. Pęd Strażnika architektury do doskonalenia projektu jest niemal niepohamowany. Niepohamowany do tego stopnia, że może łatwo przekroczyć dopuszczalną tolerancję biznesu oraz wytrzymałość zespołu. Istnieje duże prawdopodobieństwo, że za przyczyną niekontrolowanego Strażnika architektury zespół będzie co miesiąc zmieniał frameworki, a co pół roku technologię.

Kontrolowanie Strażnika przez management bardzo szybko zachęci go do poszukania nowej pracy, gdzie będzie mógł realizować swoje pomysły. Rozwiązanie tej kwestii, podpowiedział mi układ personalny pojawiający się nieraz w zespołach. Otóż, w sprawnie funkcjonującym zespole, prócz Strażnika architektury pojawia się jeszcze jego przeciwwaga. Nazwijmy go Weryfikatorem. Charakterystyka Weryfikatora to:

• jest równie kompetentny technicznie co Strażnik architektury
• bardziej niż nowinki technologicznie ceni sobie bezpieczeństwo
• jest skrupulatny, metodyczny i niesamowicie cierpliwy
• potrafi długo dyskutować ze Strażnikiem architektury i obalać jego teorie jeśli uzna je za niewystarczająco dobrze uzasadnione
• jest motywowany głównie "od problemu"

Strażnik architektury oraz Weryfikator stanowią główną oś zespołu dzięki, dzięki któremu projektu ewoluują w równomiernym tempie. Żaden z nich nie jest nadmiernie, czy sztucznie kontrolowany. Raczej wspólnie wypracowują rozwiązania, czerpiąc jednocześnie wiele satysfakcji z pracy.

Podsumowując: jeśli chcesz mieć dobry zespół i dobrze napisany projekt, to proponuję następujący przepis:

1. Zatrudnij Strażnika architektury oraz Weryfikatora o wskazanych wyżej cechach - ci muszą być rewelacyjni
2. Zatrudnij pozostałych członków zespołu - ci powinni być dobrzy
3. Pozwól im działać

Mnóstwo pytań nasuwa się w związku z tym pomysłem, chociażby: jako to zrobić?, skąd wziąć ludzi?, jak to zrobić najtaniej?. TODO.... :)