Tradycją w Polsce jest wykorzystanie urlopu/chorobowego do prowadzenia remontów. Jako że siedzę na L4, to jest to najlepsza okazja, by zadbać o blogaska. Przy okazji przedstawić wam pewną ciekawą technologię.
Mikroserwisy robione bez sensu
W epoce mikroserwisów coraz częściej można spotkać aplikacje, które są tak naprawdę „mikroserwisami”, bo nie posiadają cech wymaganych dla tej architektury. Z moich obserwacji wynika, że są dwa główne źródła takiego stanu rzeczy.
Źródło marketingowe – zazwyczaj typowe BDD (Buzzword Driven Development). Skoro wszyscy robią mikroserwisy i to się sprzedaje, to my też. Jest to bardzo stara przypadłość.
Źródło biznesowe – dokładnie, bardzo prosta domena biznesowa. Jeżeli mamy dwa przypadki użycia na krzyż, albo niewielką ilość encji, a jednocześnie potrzebujemy pewnych cech, które dają mikroserwisy np. dynamicznej skalowalności, czy ciągłości działania.
Przy czym mam świadomość, że jak w przypadku wszelkich prób opisania świata przez pryzmat własnych doświadczeń, będzie to opis niepełny.
Pierwszy punkt jest oczywisty i co kilka lat przewija się w takiej czy innej formie. Znacznie ciekawszy jest punkt drugi. Wybór architektury mikroserwisowej wynika tu z braku znajomości innych rozwiązań np. mod_cluster (który zazwyczaj wystarcza do zapewnienia dostępności i skalowalności) czy wiary, że „mikroserwisy to same to ogarną”. Jednocześnie ignoruje się dwie cechy, które powinien spełniać projekt, by w ogóle podjąć próbę użycia tego rodzaju architektury:
Niezależność zespołów
Niezależność technologii
W obu przypadkach z naciskiem na liczbę mnogą. Pozatechniczną cechą architektury mikroserwisowej jest możliwość budowania aplikacji w oparciu o rozproszone zespoły, które pracują niezależnie od siebie. Zespoły te mogą używać różnych, całkowicie niekompatybilnych, technologii. Na przykład tworząc aplikację do e-learningu, użyję innych technologii do obsługi streamingu video, a innych do ogarnięcia płatności. Pierwsze zadanie opędzę np. Elixirem, a to drugie napiszę w Javie (w zasadzie wykorzystam jakiegoś gotowca). Całość oczywiście będzie gadać ze sobą po jakimś uniwersalnym protokole.
Z drugiej strony mając jeden niewielki zespół, do stworzenia takiej aplikacji nie mogę wymagać, że będzie on ogarniać kilku różnych technologii. Muszę wybrać takie rozwiązanie architektoniczne, które pozwoli mi na jak najlepszą wydajność pracy. Być może okaże się, że odpowiednio napisany monolit będzie tu lepszy. Co ciekawe (też z własnych obserwacji), nawet jeżeli mamy architekturę mikroserwisową, która poniekąd wymusza separację komponentów, to jeżeli mamy mały zespół, to i tak zacznie powstawać, albo jakieś dziwne spaghetti pomiędzy komponentami, albo zespół będzie kodował metodami Kopiego-Pasty wszędzie tam, gdzie kod się powtarza. Dokładnie w ten sam sposób jak ma to miejsce w przypadku monolitu.
UWAGA!
Dobrze napisany monolit wymaga świadomego zespołu, który potrafi wykorzystywać clean architecture oraz opiera się nieuprawnionym operacjom.
Inne problemy z mikroserwisami
Poza wyżej wymienionymi problemami, które wynikają z niedopasowania architektury do problemu, jest też jeszcze kilka innych, które zazwyczaj umykają przy wyborze architektury.
Koszty sprzętu
Na początku mało kto zdaje sobie sprawę ile może kosztować wdrożenie mikroserwisów. Cztery jednostki m4.large w amazonowym AWS kosztują obecnie 0,60$/h jednocześnie czterokrotnie większa jednostka m4.2xlarge (4x więcej rdzeni i pamięci RAM) kosztuje 1,44$/h. Często padające hasło „mikroserwisy można wdrażać na mniejszych i tańszych serwerach” może okazać się znacznie kosztowniejsze w porównaniu z wykorzystaniem monolitu na mocniejszej maszynie.
Wydajność
Bardzo ciekawy argument, bo często mikroserwisy przedstawia się jako remedium na problemy z wydajnością. A to nie tak. Oczywiście dzięki znacznie lepszej skalowalności można poprawić wydajność w pewnych rejonach np. można przyjąć więcej żądań. Z drugiej strony mogą pojawić się nowe problemy związane z tempem komunikacji. Wywołanie zdalne nie będzie tak szybkie jak wywołanie lokalne. Nawet jeżeli jest robione w obrębie pojedynczej maszyny. Po prostu komunikacja trwa.
Koszty technologii (i ludzi)
Wprowadzając architekturę mikroserwisową do naszego świata, musimy zapewnić odpowiednie zaplecze. Jak wcześniej wspomniałem, koszty sprzętowe mogą być znaczące, dlatego chcemy mieć kontrolę nad sprzętem. Tym samym wprowadzamy różnego rodzaju narzędzia, które pozwolą nam na atomizację komponentów i niezależne zarządzanie nimi. Poszczególne mikroserwisy pakujemy w kontenery dockerowe, te rozrzucamy na środowiska przy pomocy managera w rodzaju Kubernetes, na którym zmiany w boxach są zarządzane za pomocą Ansible, a same boxy są zwirtualizowane z użyciem Mesos, dzięki czemu możemy tworzyć „dziwne” konfiguracje sprzętowe (wirtualne). Do tego procesy deploymentu są zarządzane z poziomu Jenkinsa i jego pipelien-ów. BDD pełną gębą. A przecież, ktoś to musi ogarnąć.
Koszty technologii to nie tylko koszty licencji, ale przede wszystkim koszty ludzi, którzy będą je później utrzymywać. W dodatku nasi ludzie muszą mieć wiedzę z wielu dziedzin, które niekoniecznie idą w parze. Dla dużych organizacji zatrudnienie „gościa od buildów”, którego zadaniem będzie jedynie analizowanie zepsutych zadań jenkinsowych, pod kątem potencjalnych błędów w konfiguracji nie jest dużym kosztem. Dla małej firmy może okazać się to zabójcze. Zresztą tu pojawia się pojęcie DevOps, które oznacza metodykę, ale też pewien zestaw umiejętności i wiedzy. Te z natury muszą być bardzo rozległe. Obejmują znajomość narzędzi, technik programowania, zagadnień z zakresu testowania, bezpieczeństwa, ale też całą masę umiejętności miękkich potrzebnych do pracy z wieloma różnymi ludźmi począwszy od programistów, poprzez managerów, osoby ze wsparcia technicznego, a na klientach kończąc. Wierzę, że można to ogarnąć, ale nie wierzę, że ogarniesz to w przeciągu kilku tygodni czy nawet miesięcy. W dodatku jak je już opanujesz, to może okazać się, że po zmianie organizacji tylko wiedza techniczna (i ogólne umiejętności miękkie) będzie przydatna. Nowa firma, inne procesy, inne standardy.
Typowy system javowy
Spróbujmy popatrzeć na ten problem inaczej. Po pierwsze, jeżeli nasz system jest w całości napisany pod JVM-a, to możemy pokusić się o użycie natywnych dla JVM-a rozwiązań. Po drugie, jeżeli idziemy w mikroserwisy i potrafimy pociąć naszą domenę na mikroserwisy, to zazwyczaj będą one odpowiadać poszczególnym aplikacjom. Po trzecie potrafimy jako tako w CI/CD i umiemy zapewnić sobie jako taką stabilność, to zapewne efekt będzie następujący. Kilka aplikacji Spring Bootowych, które gadają za pomocą Http REST API, bo Spring ma zarówno klienta, jak i pozwala na generowanie końcówek (endpointów) REST-owych. Oczywiście to nie jest takie proste jak się wydaje. W systemach tego rodzaju możemy wyróżnić dwa rodzaje interfejsów komunikacyjnych. Pierwszy to interfejs zewnętrzny, który jest wykorzystywany przez naszych klientów. Ten prawie na pewno powinien być zestandaryzowany. Jakiś REST, może SOAP, może całość napędzane na CORBA/kę. Drugi interfejs to wewnętrzny interfejs komunikacji. Służy on do komunikacji pomiędzy mikroserwisami. Tu zazwyczaj używamy jakiegoś binarnego ustrojstwa w rodzaju gRPC albo Aerona.
I tu wchodzi JLupin…
Największą bolączką opisanego wyżej systemu jest komunikacja wewnątrz. Trzeba jakoś dogadywać mikroserwisy, udostępniać je w ramach systemu oraz monitorować ich stan. Dużo roboty, którą dobrze by było oddelegować. JLupin Next Server jest rozwiązaniem, które pomaga ogarnąć cały ten burdel. Jest niezależne od frameworków aplikacyjnych, ale out-of-box dostarcza nam wsparcie dla Springa, a to dlatego, że twórcy wyszli z założenia, że Spring jest najpopularniejszym rozwiązaniem i trzeba je wspierać by JLNS się przyjął. Co nam daje JLNS?
Po pierwsze ogarnia komunikację wewnątrz systemową. Takie rzeczy jak Service Discovery, wewnętrzna komunikacja w oparciu o szybki binarny protokół, czy nadzór nad stanem poszczególnych mikroserwisów mamy od ręki. Ponad. to mamy zapewniony pseudo hot swap, który pozwala zachować ciągłość działania aplikacji. Mamy narzędzia do monitorowania i zarządzania naszej mikroserwisowej infrastruktury. Mamy możliwość podzielenia naszego systemu na strefy, umieszczania mikroserwisów na konkretnych maszynach w określonych strefach (logicznych) oraz co za tym idzie możliwość zarządzania widocznością mikroserwisów. Do tego twórcy przygotowali plugin do mavena, który pozwala na automatyzację deploymentu oraz plugin do IntelliJ, który pozwala na ogarnięcie zależności generowanie powiązań.
Instalacja
Instalacja sprowadza się do pobrania odpowiedniej paczki i jej rozpakowania na dysku. W przypadku wersji community należy jeszcze wyczyścić zawartość katalogu application/, bo siedzi tam przykładowa aplikacja.
Uruchomienie
W katalogu start mamy skrypt start.sh, który po uruchomieniu nie daje śladów życia, ale w katalogu logs/server/main/start będzie sobie leżał plik server.out, a logs/server/main kilka wyspecjalizowanych logów.
Jeżeli w katalogu start uruchomimy skrypt control.sh, to dostaniemy się do konsoli administracyjnej naszego serwera. Tu mamy wgląd w stan naszego noda oraz możemy zarządzać mikroserwisami. Wygląda to tak:
No trochę vintage, ale zawsze lepiej niż konsola weblogica.
Community vs Enterprise
Różnice są trzy. Po pierwsze wersja community jest ograniczona do 15 mikroserwisów na node. Po drugie może być tylko jeden node. Po trzecie nie ma dostępnego narzędzia Control Center, do zarządzania nodami (bo i po co).
Dodatki
Jeżeli chcemy możemy jeszcze dociągnąć sobie plugin do IntelliJ, bo z jakiś nieznanych mi powodów nie ma go w repozytorium JetBrains. Możemy też pobrać plugin do mavena jeżeli nie chcemy łączyć się do repozytorium JLupina.
Podsumowanie
Na dziś starczy. W kolejnych wpisach pobawimy się w tworzenie prostego systemu bankowego, z wykorzystaniem mikroserwisów i JLupina.
BDD, czyli Buzzword Driven Development, to rak projektów IT. Kupujemy technologię, bo ładnie brzmi, albo jest modna, a potem płaczemy jak przychodzi do utrzymania.
Brak motywacji, by dokończyć pisanie o nazwach i rozwiązać „konkurs” dotyczący nazwy został zredukowany do zera „hejtem”, jaki pojawił sie ostatnio na kod ze strony pkp intercity.
Koledzy i koleżanki w kodzie. Powiem wam jedno.
JESTEŚCIE HIPOKRTAMI
I niech kurwa nikt nie mówi, że nie, bo każde z nas puściło nie jedną kiepską nazwę na produkcję. Do problemu PKP jeszcze wrócimy. Skupmy się na temacie nazw.
Nazywać po imieniu
Problem nazewnictwa przerabialiśmy już w cyklu ekstremalna obiektowość w praktyce, a dokładnie w części piątej. W tamtym wpisie nie wyczerpaliśmy tematu. Co więcej, tamten wpis dotyka trochę innego problemu, czyli odszukiwania potencjalnych problemów za pomocą kontekstu użycia danej metody.
Nazywamy nie tylko metody, ale też klasy, moduły, zmienne i dlatego warto zastanowić się jak robić to dobrze.
Zasady — ogólnie
Branżunia, wypracowała sobie pewne zasady, co do nazywania różnych rzeczy. Można je ująć w następujący sposób.
Klasy, moduły, struktury itp. obiekty, które reprezentują w kodzie pewne byty biznesowe nazywamy korzystając z rzeczowników.
Funkcje, metody, procedury reprezentują czynności i ich nazwy pochodzą od czasowników.
Wartości typów wyliczeniowych, stałe reprezentujące pewną cechę itp. są przymiotnikami, ale możemy je grupować np. w enum-a, którego nazwa jest rzeczownikiem.
Chcąc doprecyzować znaczenie danego elementu oraz umieścić go w przepływie sterowania możemy dodawać przedrostki w rodzaju Pre i Post, albo przyimki. W przypadku przyimków zazwyczaj stosujemy okoliczniki czasu, bo co do zasady używamy języka angielskiego.
Proste. Klasa rzeczownikiem, metoda czasownikiem. Jak pamiętacie coś z polskiego, z podstawówki, to jeszcze dołóżcie budowę zdania i mamy ładnie rozklepane wywołanie metody.
Listing 1. Przykładowe wywołanie metody
"12-345".matches(plPostCodePattern)
„12-345” — podmiot.
matches — orzeczenie.
plPostCodePattern — przydawka (not sure)
Istnieje też grupa zasad, które pozwalają na identyfikowanie problemów:
Jeżeli nazwa zawiera spójniki i, lub, albo, to mamy wiele odpowiedzialności.
Jeżeli nazwa zawiera generyczne bądź abstrakcyjne rzeczowniki, a kod, który reprezentuje jest konkretny, to mamy najprawdopodobniej do czynienia z nieprecyzyjną nazwą.
Jeżeli nazwa na wysokim poziomie abstrakcji zawiera szczegółową nazwę implementacji, to abstrakcja nam cieknie.
Jeżeli mamy powtórzenie w nazwie, to przekombinowaliśmy z architekturą.
Do tego dochodzi kilka „zabronionych” słów w rodzaju Listener, Handler czy Provider, czy niespójności w nazwie i typie zwracanym/przyjmowanym. I mamy komplet.
Problemy
Przyjmując takie proste zasady dość łatwo jest stworzyć idealną nazwę, prawda? No nie do końca. Po pierwsze nazwa powinna być opisowa, ale nie długa. Problem już omówiliśmy wcześniej. Nazwę można skracać, byle nie za bardzo, a nawet powiem więcej czasami stosujemy skróty w rodzaju DTO, DAO. To powoduje, że mamy ograniczone pole manewru. Po drugie nazwa powinna ułatwiać nam lokalizację kodu w architekturze, ale pewne nazwy występują w wielu miejscach w odmiennych znaczeniach. Po trzecie nazwa powinna być dostosowana do poziomu abstrakcji, na którym pracujemy, a nie zawsze jest to możliwe. Po czwarte, w końcu, nazywający może mieć ograniczony zasób słownictwa, który ogranicza mu możliwości zarówno w przypadku oczywistych jak i specyficznych nazw.
Dobra nazwa, czyli jaka?
Z dotychczasowej zabawy wiemy już, że nadanie dobrej nazwy może być problematyczne. Co więcej, im mniej wiemy o systemie, tym trudniej jest nam znaleźć odpowiednią nazwę, która będzie pasować do świata. Z pomocą przychodzi nam DDD, które wymusza do pewnego stopnia stosowanie odpowiedniego nazewnictwa. Użycie języka domenowego do opisu operacji i bytów przenosi ciężar szukania nazw z programistów na ekspertów domenowych. Nie jest to, niestety, idealne rozwiązanie, ponieważ eksperci domenowi mają trochę inną perspektywę. Zazwyczaj bardzo dobrze rozumieją poszczególne pojęcia i potrafią ich używać w odpowiednim kontekście. Jeżeli damy programiście dwa identycznie nazywające się byty, to mamy dużą szansę, że wyprodukuje potworka. Tu warto podrzucić przykład, a ten będzie wredny.
W naszej aplikacji mamy konto (ang. account) i rachunek (ang. account). Konto istnieje w kontekście księgi głównej, rachunek w kontekście klienta. Spotykają się one w kontekście księgowego (ang. accountant), który na podstawie operacji na rachunkach tworzy operacje na kontach.
Zastanówcie się nad nazwami. Przykład jest o tyle wredny, że obie te nazwy w kontekście operacji finansowej w języku angielskim są reprezentowane przez to samo słowo. Nie takie samo, ale to samo. No właśnie, kontekst i język.
Język ma znaczenie
Większość z nas używa języka angielskiego w kodzie. Przyjmujemy to jako oczywistość. Wszelkie odstępstwa są traktowane jako herezja. Czy jednak słusznie? Jeżeli popatrzymy na ten problem z perspektywy użyteczności, to kurczowe trzymanie się języka angielskiego nie ma sensu. Jeżeli środowisko pracy jest polskojęzyczne, to używanie języka polskiego może okazać się dobrym wyborem. Oczywiście musimy spełnić kilka warunków m.in. jakoś zagwarantować sobie, że wszyscy znamy język polski. Oznacza to też, że ograniczamy sobie możliwość zatrudniania, ale czasami i tak mamy to narzucone.
Inna sprawa to język dokumentacji i analizy. Tu często mamy do czynienia z językiem polskim, co prowadzi do podwójnego tłumaczenia nazw i w efekcie może prowadzić do nieporozumień. Jako ciekawostkę można potraktować projekty realizowane przez firmy z Niemiec, gdzie zarówno dokumentacja, jak i komunikacja są w języku niemieckim. Kod też jest w języku niemieckim, jeżeli nie wychodzi poza organizację.
Casus PKP, czyli podsumowanie
Wspomniany na początku kod w wykonaniu PKP Intercity jest, z punktu nazewnictwa, znośny. Problemem nie jest język polski, bo taka jest konwencja i naprawdę nie ma potrzeby, by kombinować z angielskim. Mamy tu do czynienia z dwoma innymi problemami.
Mieszanie języków
Do pewnego stopnia wymuszone przez konwencje stosowanie przedrostków is, valid itp. Jest to problem nie do rozwiązania, szczególnie w językach słabo lub niejawnie typowanych, które bazują na konwencji (patrz FORTRAN i implicit none). W językach silnie typowanych ten problem ma postać generycznych nazw metod w interfejsach np. handle, accept itp. Taki problem, nie problem.
Mieszanie konwencji
Rzeczywistym problemem w tym kodzie jest mieszanie różnych konwencji nazewniczych. Czasami camelCase rowerOferta, czasami snake_case is_bilet_rodzinny. Nazwy pełne kod_znizki, skróty kat_poc, obfuskacja v1, nazwy zawierające liczebniki porządkowe liczba_u_2.
Takie nietrzymanie konwencji jest jak nietrzymanie moczu. W pewnym momencie narobimy sobie wstydu przed obcymi ludźmi.
Sprawa jakości samego kodu nie jest tu istotna, ale będzie i o tym.
Rozwiązanie konkursu
W komentarzach było kilka propozycji co oznacza attrValPrnt. bestils, zaproponował attractvalueprint, która to nazwa też była naszym pierwszym rozwinięciem gdy mieliśmy problem i pośrednio przyczyniła się do powstania kilku ostatnich wpisów. Paweł zaproponował pointer, co jest bliższe prawdzie, ale kolejność liter się nie do końca zgadza.
Otóż moi mili. attrValPrnt to nic innego jak Attribute Value Parent. Jest to wskaźnik na słownik nadrzędny, w którym trzeba szukać wartości dla danego atrybutu pod takim samym kluczem. Fajne prawda?
wyiksowałem rzeczy, które są biznesowo istotne, ale nie straciło to nic ze swojego uroku. Metoda jest prywatna w danej klasie, bo takie potworki czasami trafiają się w Spring Data, i przyjmuje trzy parametry. Zwraca jakiś tam obiekt biznesowy.
W poprzednim wpisie omówiłem, krótko, bo krótko, problem skracania nazw w kodzie. Dziś poruszę problem zbyt długich nazw. One też nie są dobre.
Co oznacza „nazwa opisowa”?
No właśnie… Czy pojęcie to oznacza nazwę, która jest długa, precyzyjna i w najmniejszych szczegółach oddająca co dzieje się w środku? A może nazwa opisowa niesie ze sobą pewien „ładunek emocjonalny”, który pozwala na wczucie się w kod? Był sobie taki nurt w literaturze. co nazywał się RealizmW. Jednym z jego najwybitniejszych przedstawicieli był Lew TołstojW. I większość z nas zapamiętała go jako autora długich, bardzo szczegółowych opisów.
Obserwacja
Im bliżej technicznych aspektów projektu, tym bardziej rozwlekłe są nazwy. Jest to oczywiste przeciwieństwo problemu z poprzedniego wpisu. Być może ma ono źródło w „nie jesteśmy humanistami” i brakach w umiejętnościach językowych? Z drugiej strony płodzenie takich potworków.
Podsumowanie
Na dziś tyle. Zostawiam was z problemem nazywania różnych elementów w kodzie i szukania tego złotego środka pomiędzy nazwami zbyt krótkimi i zbyt długimi. Jako „zadanie domowe” możecie spróbować wypisać sobie trzy dobre i trzy złe cechy nazw popularnych algorytmów jak Quick Sort, A*, Sidewinder.
Nowy rok, nowe błędy. Wpis miał być o czymś innym, tzn. miało to być podsumowanie poprzedniego i plany na obecny rok, ale jak to w życiu bywa, plany poszły się paść. Będzie o czymś, moim zdaniem, ciekawszym. Będziemy przyzywać wielkich przedwiecznychW.
Kontekst
Mając możliwość obcowania z różnymi systemami, zauważyłem pewną prawidłowość. Im bliżej biznesu umieszczamy kod, tym bardziej niezrozumiałe i skrótowe są nazwy. Dotyczy to zarówno nazw usług, jak i bytów biznesowych. Co ciekawe w dokumentacji mamy do czynienia z całymi tabelami translacji, które tłumaczą nazwy domenowe na nazwy techniczne. Jednocześnie im bardziej zagłębiamy się w kod, tym bardziej opisowe i abstrakcyjne nazwy poszczególnych elementów. Takie nazewnictwo, zarówno bliżej biznesu jak i bliżej krzemu ma pewne negatywne konsekwencje.
Nazwy skrótowe
Wiele lat temu pracując przy systemie SIS spotkałem się z bardzo ciekawym problemem. Pewien fragment systemu posługiwał się nazewnictwem pozbawionym samogłosek. No spoko, da się żyć z tego typu „optymalizacją”. Tyle tylko, że nazwy pochodziły z języka portugalskiego. No kurwa…
Dopiero wtedy odkryłem, po co mi była karteczka z tłumaczeniami, którą otrzymałem pierwszego dnia od liniowego. Tak, zawierała ona tłumaczenie skrót → całe słowo po portugalsku → słowo po angielsku, bo oczywiście klasy były już w cywilizowanym języku. Narzut komunikacyjny, który był spowodowany koniecznością, takiego wielokrotnego tłumaczenia był znaczny.
Kolejny ciekawy przykład, to tytułowy PrtDtRefStsMngmnt, który jest nazwą klasy. Spoko, prawda? Tylko co to, kurwa, jest? A teraz wyobraźcie sobie, że spotykacie taki oto fragment kodu:
Cytując klasyka, o co tu kurwa jego mać chodzi, w tym burdelu? Pozostawię was z tym problemem.
Powyższy kawałek kodu jest wynikiem pracy z SOAP-em i usługami na szynie danych. Tak już się jakoś złożyło, że biznes postanowił oszczędzić kilka znaków i spłodził potworka.
Dlaczego tak się dzieje?
Moje obserwacje wskazują na trzy główne powody używania tego rodzaju konwencji nazewniczych. Po pierwsze to ograniczenia innych technologii. XML nie jest jakoś specjalnie elastyczny, jeśli chodzi o nazwy. Podobnie wiele narzędzi około XML-owych wprowadza własne ograniczenia związane zazwyczaj z długością nazw. Po drugie na poziomie analizy istnieje silna potrzeba upraszczania. Upraszczanie jest najbardziej widoczne na poziomie długości nazw. Działa to trochę jak taka typowa restrukturyzacja w przedsiębiorstwie. Wywali się 30% załogi, a reszcie utnie pozapłacowe dodatki i będzie zreformowane. Nie ważne, że procesy nadal są słabe, ale finansowo widać poprawę. Podobnie tutaj. Wywali się długie nazwy, które robią wrażenie skomplikowania systemu. W zamian wstawi się skróty, które będą wyglądać mądrze i pseudo-technicznie, a jednocześnie przepchną „komplikację” na stronę techniczną. Inaczej mówiąc, analitycy chcą dobrze, ale ci techniczni… Po trzecie lenistwo w pisaniu. Dziesięć znaków wedle konwencji pisze się szybciej niż 20 pełnej nazwy.
Oczywiście jest to moja obserwacja i może być błędna, ale chyba nie mylę się jakoś szczególnie.
W niektórych przypadkach, szczególnie bardzo starych systemów, przyczyną są rzeczywiste ograniczenia techniczne. W DOSieW nazwa pliku mogła mieć jedynie osiem znaków plus trzy znaki rozszerzenia. Tyle tylko, że DOS umarł w 2003 roku wraz z wersją 7.1 (dla specyficznych maszynek IBMa).
Konsekwencje
Najpoważniejszą konsekwencją są wspomniane wcześniej zatory komunikacyjne. Nowa osoba wchodząca do projektu musi poświęcić mnóstwo czasu i energii na odszyfrowanie dziwnych nazw. Czy stać nas na ten luksus? Chyba tak, bo twardo trzymamy się tego typu nazw. Kolejny problem to błędy wynikające ze stosowania intuicji. Jeżeli mamy takie oto nazwy:
attrValStr
attrValInt
attrValBool
attrValReal
to, co oznacza attrValPrnt? Odpowiedź będzie w jednym z kolejnych postów, a na razie czekam na propozycje w komentarzach.
Podsumowanie
Blogonotkowe życie toczy się samo. Miała być szybka notka będą pewno trzy. Jednocześnie mam nadzieję, że mi się uda wrócić do regularnego pisania 🙂
Wiem, że wiele osób czekało na ten wpis. Kolejna prezentacja Wojtka Seligi na Confiturze i kolejny raz mam okazję do napisania polemiki. Na wstępnie chcę jednak zaznaczyć, że zgadzam się z częścią tez Wojtka. W czasie prezentacji pojawiło się jednak wiele wątków, z którymi nie mogę się zgodzić.
Nagranie całej prezentacji:
Eksportujemy ciała – NIE
Pierwszą tezę Wojtka można ująć tak
Z Polskie przestaliśmy eksportować towary, a zaczęliśmy eksportować usługi.
Ciężko jest mi zgodzić się z tak postawioną tezą, ponieważ jest ona nieprawdziwa. Bazując chociażby na publikacji Ministerstwa Gospodarki/Rozwoju możemy stwierdzić, że w takim 2014 roku eksport towarów wynosił ponad 157 mld EUR (str. 39), a eksport usług wynosił raptem 36 mld EUR (str. 69). Co więcej jeżeli przyjrzymy się jakie usługi eksportujemy, to większość stanowią odpowiednio usługi transportowe ponad 10mld EUR (str. 72), a następnie turystyka ponad 8mld EUR (str 72).Eksport usług telekomunikacyjnych, informatycznych i informacyjnych to raptem 3 mld EUR. Jak ma się, to do sprzedawania ciał… nie wiem.
Ale, ale… dane które tu przytaczam pochodzą z 2014 roku. Mamy rok 2017! Ok, należy jednak zwrócić uwagę, że dane statystyczne co do zasady są publikowane z pewnym opóźnieniem. Publikacja, którą linkuję pochodzi z 2015 roku. Sięgnijmy zatem do nowszych danych, za rok 2016. Tu niestety forma jest znacznie mniej przystępna i trzeba się trochę nagimnastykować, by odszukać potrzebne informacje. Informacje będą dotyczyć roku 2015. Według tej publikacji wartość eksportu towarów wynosiła prawie 180 mld EUR (tab 19 str. 90), a wartość usług dostarczonych (wyeksportowanych) wynosiła około 40mld EUR (tab 29, str. 206). I znowuż lwią część tej kwoty stanowią usługi transportowe (str. 222). Warto też tu wspomnieć, że do usług zalicza się obrót własnością intelektualną, więc jeżeli takie LPP tworzy spółkę w ZEA czy innym Katarze, by tam ulokować swoje biznesy związane z posiadanymi znakami towarowymi, to też liczymy ten biznes do bilansu (choć jest to tylko optymalizacja podatkowa, a nie realny biznes).
Podsumowując, Wojtek postawił pewną tezę i nie skonfrontował jej z rzeczywistością. A rzeczywistość okazała się brutalna.
Co dzieje się w Mordorze?
W świetle danych, trudno odpowiedzieć na to pytanie. W trakcie prezentacji Wojtek słusznie wspomniał o Mordorze i milionach metrów kwadratowych powierzchni. Jak to możliwe, że pomimo dostępu do tak ogromnych zasobów, eksport jest niewielki. Przecież wiele firm otwiera swoje centra usług wspólnych w Polsce! Przepracowałem kilka ostatnich lat w tego typu miejscach i chyba mogę odpowiedzieć na to pytanie.
Po pierwsze dużą część powierzchni zajmują firmy, które nie uczestniczą w eksporcie. Czy taki Play albo mBank eksportują swoje usługi? No nie. Eksport usług jest zapewne ułamkiem procenta ich „produkcji”. Jednocześnie te firmy muszą jakoś obsłużyć sporą liczbę klientów tu na miejscu. I to właśnie obsługa rynku wewnętrznego pochłania lwią część powierzchni. Dołóżmy do tego przepisy BHP, które określają ilość miejsca (wolnej podłogi jak i kubaturę pomieszczenia) na pracownika i nagle okazuje się, że chcąc zatrudnić 100 osób, trzeba mieć na „dzień dobry” około 1000-1500m^2 biura (w zależności od zagęszczenia i układu, więcej tu). Czy 100 osób to dużo? No nie, ale poza powierzchnią musisz zapewnić im też otoczkę, czyli zatrudnić kolejnych ludzi, którzy będą dbali o to biuro.
Drugim pochłaniaczem powierzchni jest obsługa biura. Serwis sprzątający, to tylko ułamek. Przecież ktoś musi zadbać o to, żeby sale konferencyjne były przygotowane na spotkania (ustawione stoły, krzesła, dodatkowe wyposażenie), ktoś musi obsłużyć interesantów (recepcja i ochrona), a jak spieprzy ci się myszka, to też ktoś musi ją naprawić. Nie wspominam tu już o działach typu księgowość, kadry, rekrutacja, bo to kolejni pracownicy. Jeżeli nałożymy na to typowy dla korporacji sposób organizowania pracy poprzez ujmowanie jej w regulaminy, to nagle dla naszych 100 „roboli” musimy zapewnić jeszcze 10-20 osób „obsługi” (weź pod uwagę urlopy). Nasze biuro rośnie już do 1200m^2. A przecież wymagania stawiane dużym firmom są bardziej rygorystyczne. Pokój dla matek karmiących, kuchnia, która „przyjmie” twoich pracowników w porze obiadowej, sławetny jeden pisuar i jedna miska ustępowa na 20 chłopa (plus 1 miska ustępowa na 10 pań). Biuro puchnie.
Trzeci pochłaniacz to powierzchnie wspólne, których zadaniem jest „oczarowanie” wchodzących. Odpowiednio duży hol, przestronna recepcja, ale też odpowiednie drogi ewakuacyjne, parkingi, hole windowe, to wszystko pompuje nam budynek. W Mordorze pracuje około 100 tysięcy ludzi. Ogromna część z nich pracuje na to, by Mordor w ogóle działał.
Drang nach Ost – NIE
Drugą tezę z prezentacji można opisać w następujący sposób:
Tylko wojna na Ukrainie spowodowała, że usługi nie zostały przeniesione dalej na wschód.
Nie siedzę w głowach managerów, ale teza ta wydaje mi się mocno naciągana. Wojtek odwołuje się tutaj do, fenomenalnej skądinąd, książki My Job went to India autorstwa Chada Fowlera. BTW druga edycja tej książki ma inny tytuł, ciekawe dlaczego…
Zacznijmy od podstawowych różnic pomiędzy Polską, a taką Rosją. W sumie różnica jest jedna i widoczna najlepiej na lotniskach. Jako obywatel Polski, nie muszę tłumaczyć się z tego dlaczego przyjechałem, po co przyjechałem, co przywiozłem. Gwiazdki unijne w paszporcie dają bardzo dużo. Dla korporacji system polityczny nie ma większego znaczenia. Do póki idzie dogadać się z rządem, czy to za pomocą oficjalnych kanałów, czy to za pomocą kanałów mniej oficjalnych, nikt nie będzie się zastanawiać nad tym czy rząd pałuje obywateli. Zresztą bardzo dobrym potwierdzeniem mojej tezy jest zachowanie instytucji takich jak Citigroup czy Morgan Stanley w obliczu Brexitu. Banki te po prostu przenoszą swoje zespoły na teren UE (opisane tutaj). Dlaczego? Ponieważ wspólny rynek i swobody przepływu dają znacznie większe zyski niż niskie pensje pracowników. Pozwalają też na budowanie pewnych konstruktów biznesowych w rodzaju podwójnej kanapki irlandzkiej z wkładką holenderską, czy jakoś tak (to konkretne rozwiązanie uwalono, ale są inne). Inaczej mówiąc jeżeli jesteś w UE, to łatwiej prowadzić ci biznes. Wycieczka dalej na wschód nie ma sensu.
Tu mały pr0tip. Jeżeli chcecie pozwiedzać Amerykę Południową, to Air France lata do Gujany Francuskiej po kosztach lotów krajowych. Można dużo zaoszczędzić.
Informatycy – zawód (nie)wybrany
Kolejna teza opiera się o założenie, że programiści nie są zawodem wybranym. W pełni zgadzam się z tym twierdzeniem, ale pozwolę sobie na małą kontrę co do listy innych „zawodów wybranych”, którą przedstawił Wojtek.
Górnicy
No nie. Pozycja jaką mieli górnicy w czasach PRLu, to taki trochę urban legend. Po pierwsze na górnictwo i hutnictwo jako branże „wiodące” postawił dopiero Edward Gierek. W dodatku zrobił to tylko i wyłącznie z przyczyn politycznych. Jako sekretarz wojewódzki ze Śląska wsparł swój twardy elektorat. Zresztą takie same kroki podjęto wobec innych branży w drugiej połowie lat 80-tych. Stąd właśnie jako dziecko kolejarzy miałem darmowe i nielimitowane bilety na pociągi. Po prostu nie mogąc dać ludziom pieniędzy dano im pewne przywileje. Zresztą większość z nich odebrano, a sławetne 13-stki i 14-stki, to potoczne nazwy na premie roczne albo spieniężone świadczenia materialne, których istnienie w przemyśle wydobywczym ma bardzo dawne korzenie.
Bankowcy
Witki mi opadły jak to usłyszałem. Serio. Redukcja zatrudnienia w bankach jest po części związana z kryzysem. Największy wpływ na redukcje zatrudnienia w bankach miała automatyzacja. Taki mBank, który jest czwartym co do wielkości bankiem w Polsce (pod względem wielkości aktywów), zatrudnia raptem 5 tysięcy osób. Mniejsze ING zatrudnia ponad 7 tysięcy (tamże), a większe BZ WBK ponad 11 tysięcy (tamże).Zresztą procesy automatyzacji mają to do siebie, że są w dużym stopniu wymuszane, ale jak już zaistnieją, to gwałtownie wypychają wcześniejsze formy. Nie dotykają też tylko bankowości. Przez ostatnie 200-250 lat trudnym do automatyzacji był proces szycia ubrań. Dlatego też szyjemy ubrania w krajach tanich. Jednak ostatnio coś drgnęło. Można to traktować jako ciekawostkę, ale z drugiej strony, jeżeli wypali, to kraje Azji Południowo-Wschodniej mają poważny problem.
Nauczyciele jęz. angielskiego
Trochę inaczej miała się sprawa z nauczycielami języka angielskiego. Na początku lat 90-tych po prostu ich nie było. Jednocześnie powstało ogromne zapotrzebowanie zarówno prywatne, jak i publiczne. Szkoły przechodziły z nauczania rosyjskiego na nauczanie angielskiego. Po 20 latach publiczna edukacja spowodowała, że nie ma aż takiego zapotrzebowania na nauczycieli angielskiego, bo po prostu uczymy się w szkole. Pozostał rynek korepetycji i prywatnych szkół językowych, który będzie zachowywać się tak samo, jak na przykład rynek korepetycji z matematyki.
Prawnicy
Prawnicy to zupełnie inna działka. Zacznijmy od wspomnianych „ustawionych” notariuszy. Po pierwsze w przypadku pewnych działań np. sprzedaży nieruchomości jest przymus notarialny. Po drugie taksa notarialna jest określona w rozporządzeniu. Po trzecie notariusze, tak samo jak inne zawody prawnicze „dla ludu” (adwokaci, radcy, komornicy), mają zakaz reklamy oraz zakaz pracy poza kancelarią (z nielicznymi wyjątkami jak praca na uczelni, czy w jednostkach administracji publicznej). Jeżeli tak ograniczony rynek nałożymy otwarcie zawodu, które miało na celu:
Otwarcie dostępu do zawodów prawniczych wychodzi naprzeciw społecznym oczekiwaniom zwiększenia dostępności do pomocy prawnej oraz potrzebom prawników aspirujących do wykonywania tych zawodów.
Jednak zostało zaaplikowane w społeczeństwie, które nie ma w zwyczaju korzystać z pomocy prawnika, albo korzysta w ostateczności narzekając na cenę i bardzo często przychodząc „po ptokach”. Więc nie należy się dziwić, że dziś prawnicy mają pod górkę.
Podsumowując, przyczyny załamań w różnych zawodach są znacznie bardziej skomplikowane, niż przedstawił to Wojtek. Tu bardzo ładnie wchodzi temat codzienności programowania i cyfryzacji społeczeństwa. Teoretycznie każdy z nas potrafi pisać i czytać. Praktycznie czytamy i piszemy, ale niewiele osób potrafi kaligrafować i recytować. W każdej powszechnej umiejętności jest pewien próg, którego zwykle nie osiągamy.
Murarz, domy muruje
I całkiem dobrze mu to idzie. Co więcej, w przeciwieństwie do tego co Wojtek próbuje wmówić, potrafi robić nie tylko z cegieł. Technologia jest celem sama w sobie. Dzięki temu potrafiliśmy odejść od cegieł i zmusić wielki stalowy walec najpierw do pływania, a potem do latania. Właśnie na tym polega rozwój technologiczny. Potrafimy rozwiązać problem, ponieważ znamy się na konkretnej technologii i rozumiemy dlaczego, ona nie będzie działać w danym przypadku. Murarz nie będzie na siłę murował hali sportowej, a odeśle nas do kogoś, kto jest specjalistą od konstrukcji tego typu. Wojtek podszedł tu bardzo naiwnie do tematu. Kontrastuje to z jego wcześniejszymi słowami, o przeskakiwaniu pomiędzy technologiami. Takie zmiany robimy nie dlatego, że nam się nudzi, ale po to by nie murować wszystkiego. Mówiąc inaczej dostosowujemy narzędzia do oczekiwań.
Add to cart
Bardzo zabawnie może wyglądać w tym miejscu tabelka z cenami wynajmu zespołów. Tyle tylko, że została podana bez kontekstu. Co czyni ją zabawną w dalszej części prezentacji, gdzie widzimy podwójną toaletę. PM po 5USD/h nie dostanie z tego 3USD/h. Pracując kilka lat w firmie o rosyjskich korzeniach i rozmawiając z kolegami z Ukrainy o zarobkach, przekaz był jednolity. Na Ukrainie zarabiali więcej niż w Polsce (mówimy o IT, a nie innych sektorach). W dodatku płacone mieli w twardej walucie (przede wszystkim dolary), a nie w hrywnach. Dlaczego zatem przenieśli się do nas? Ponieważ po pierwsze Polska jest w UE i wielu kolegów po odpracowaniu lojalki przeniosło się dalej na zachód (bezterminowa wiza pracownicza), a po drugie „u was żyje się normalniej”. Co oznacza normalniej? Chociażby to, że w zimie jest prąd i woda, a nie awaria.
Wróćmy jednak na chwilę do tabelki i sięgnijmy po dane. Średnie zarobki senior java deva na Ukrainie to niecałe 41 tys. USD (za payscale). W Polsce to niecałe 38 tys. USD (tamże). Zatem wniosek, który wyciągnął Wojtek o tych trzech dolarach, jest błędny.
Brak kontekstu, który zna autor tabelki prowadzi nas do błędnych wniosków. Oczywiście możemy spróbować wydedukować pewne elementy tego kontekstu i tym samym spróbować zrozumieć dlaczego oferta wygląda tak, a nie inaczej:
Firma wchodzi na rynek unijny i chce złapać pierwszych klientów.
Ktoś przeprowadził badanie i wie do kogo wysyła ofertę. Chce mieć Spartez w portfolio.
Druga opcja jest trochę naiwna, ale prawdopodobna. Czasami bardzo nam zależy na konkretnym kliencie, bo wartość niematerialna, a tym samym wpływ na wartość późniejszych biznesów będzie większy niż bezpośrednia strata. Takie myślenie nie jest niczym nowym i choć w Polsce przybrało w pewnym momencie karykaturalną formę „będzie miał pan do portfolio”, to robienie po kosztach dla VIP-ów nie jest niczym nowym.
Znacznie ciekawsza jest tu pierwsza opcja. Jeżeli firma chce wejść na jakiś rynek, zamknięty i regulowany, to musi znaleźć pierwszego klienta. Nie jest to coś niezwykłego. Pierwszy, drugi udany kontrakt na danym rynku daje większe możliwości negocjacyjne z innymi klientami. Nie muszą oni dokładnie sprawdzać firmy, bo sprawdzenie takie zrobił już ktoś inny i było ono pomyślne. Pamiętacie firm ę Covec? Dokładnie ten sam mechanizm.
By dopełnić obrazu zarobków na wschodzie udajmy się do Indii. Średnie zarobki dla senior java deva w Indiach to około 12 tys. USD (j.w.). Dlaczego zatem nie zatrudniamy w Indiach na jeszcze większą skalę? Podpowiem chodzi nie tylko o jakość, bo i drodzy programiści na przykład z Niemiec, potrafią walnąć ciekawe babole, a tani nie są.
Technologia kontra produkt
Skupienie się na produkcie, a dokładnie na wartości dla klienta, jest kolejną tezą prezentacji.
Technologia w tym wszystkim staje się rzeczą, tak samo jak umiejętność programowania, czymś po prostu domyślnym, którą się bierze by default.
Jest to ciekawe stwierdzenie, biorąc pod uwagę poprzednie wywody o niskiej jakość tanich programistów. Bo, czy możemy sobie pozwolić na zignorowanie technologii i całkowite skupienie się na produkcie? Czy bycie dumnym, że coś potrafimy zrobić jest czymś złym? Oczywiście nie. Nawet jeżeli nasza praca jest odtwórcza i powtarzalna, to nadal nasze umiejętności są bardzo ważne. Wojtek mówi, że niewiele jest firm w IT, które robią coś rzeczywiście innowacyjnego w skali świata. Pełna zgoda. Takich firm jest niewiele. Jednak tak samo niewiele jest firm, które tworzą innowacyjne rozwiązania w budownictwie. Tu też 99% pracy to lanie betonu i układanie cegieł. Jeżeli murarz, albo zbrojarz-betoniarz (boska nazwa stanowiska pracy tak BTW) będzie partaczył, to nawet przy najlepszym fokusie na produkt, nie dowieziemy. Przy czym nadal istotą jest rozwiązanie, które działa dla klienta. Inaczej mówiąc technologia nie jest czymś, co możemy sobie zapudełkować, bo realnie wpływa na koszty biznesu i jego późniejsze losy. Słaby programista wyprodukuje słaby kod, który będzie budować słaby produkt. Tak samo jak słaby murarz wybuduje krzywą ścianę.
Uwaga, nie oznacza to, że dobry programista zawsze stworzy dobry kod. Dobry programista ma większą szansę na stworzenie lepszego kodu. Na tej samej zasadzie świetny kierowca może mieć zły dzień i zamiast elegancko zaparkować po prostu zwali gruchę do wykopu.
Why, how, what
Kolejna teza jest silnie powiązana z koncepcją „Golden Circle” Simona Sineka. Tyle tylko, że Wojtek chyba trochę ominął dość istotny szczegół. Otóż aplikujemy to do dwóch różnych światów. Cel firmy produkującej oprogramowanie, czyli WHY, jest inny niż cel firmy, która to oprogramowanie zamawia. Niezależnie czy zamawia to bank, czy hodowca bezmózgich kurczaków. To o czym wspomina, czyli kto będzie używał, jak będzie używał, jest elementem wspólnym tych dwóch światów. Jednak informacje te służą nam w zupełnie innym celu. Bank powie, że będzie to grupa około 100 traderów klikających jak szaleni. Dla osoby, która ten soft będzie robić, to jest informacja, a nie to, że będą oni robili nielegalne operacje finansowe. Nasza definicja WHY jest inna niż definicja WHY hodowcy kurczaków.
Jednak poruszone są tu inna ważne kwestie. Pierwsza z nich to skrytość i brak zaufania. Prowadzę obecnie projekt, który da naszemu klientowi bardzo dużą przewagę nad konkurencją. Klient pochodzi z sektora IT, ale z zupełnie innego segmentu. Teoretycznie wiedząc, co chce osiągnąć, mógłbym na bezczelnego ukraść mu ideę i samodzielnie ją wdrożyć. Tyle tylko, że jest to bez sensu, bo nie znam się na rynku, na którym nasz klient jest obecny. Z drugiej strony klient mógłby nam zlecić przygotowanie produktu, a potem wypiąć się na nas, bo teoretycznie ma możliwości, by samodzielnie stworzyć oprogramowanie. W praktyce jednak nie zna się na naszej działce i nie wie o wszystkich potencjalnych problemach. Obydwaj mamy tego świadomość i dlatego współpracujemy. Nasze motywacje są zupełnie różne, ale dzięki otwartości możemy razem coś osiągnąć. Niestety nie zawsze istnieje zaufanie. Druga istotna kwestia, to wiedza specjalistyczna. Czy muszę poznać tajniki hodowli kurczaka, by zaprogramować rozrzutnik karmy? Trochę tak, chociażby po to, by dostosować się do rodzaju karmy. Jednak głęboka wiedza specjalistyczna powinna być domeną klienta, który potrafi robić na tym biznes. Moja wiedza specjalistyczna, jako programisty, jest związana z komputerami. Tym właśnie jest element HOW, czyli umiejętności, które pozwalają na wybranie narzędzi używanych w WHAT. Hodowca kurczaka będzie wiedział, jak określić parametry karmy, bo ma taką wiedzę, a ja będę wiedział jaki serwer potrzebny jest do kontroli stu rozrzutników. Kwestia wybranej technologi implementacji serwera jest już szczegółem tak samo jak sposób machania łopatą, by się nie męczyć przy rozrzucaniu karmy.
Product engineering
W ten sposób płynnie przechodzimy do product engineeringu, czyli umiejętności dostarczania produktu, który trafia w potrzeby rynku. Jest to oczywiście kluczowa umiejętność. Tyle tylko, że Wojtek trochę miesza różne odpowiedzialności. Znowuż dział programowania odpowiada za techniczną część produktu, dział zajmujący się UX za odpowiedni wygląd i funkcjonalność, a dział sprzedaży za taki dobór funkcjonalności, by klienci byli zadowoleni. Tego nie zrobi jeden pojedynczy człowiek i nie ma co czarować, że programiści, którzy całe życie grzebali w krzemie nagle staną się specjalistami od psychologii.
To o czym jest product engineering, to umiejętność łączenia pracy różnych specjalistów w ramach procesu produkcji. Czy łączymy specjalistów z różnych dziedzin życia, by otrzymać dobrze działającą firmę produkującą oprogramowanie, czy też produkującą bezmózgie kurczaki oznacza, że rozumiemy NASZ biznes. Wymaganie by programista nagle stał się specjalistą od sprzedaży mija się z celem.
Zresztą Wojtek mówiąc o PE, posiłkuje się slajdem , na którym wymienione są różne cechy związane z tym pojęciem. Rzecz w tym, że jedna osoba nie może być odpowiedzialna za wszystkie te obszary. Może mieć pojęcie o strategiach cenowych, o analizie danych, o UXie, ale nadal jest, to wiedza powierzchowna, bo tak naprawdę wiedzę ekspercką ma w innej dziedzinie. I to nie jest złe. To jest bardzo dobre, bo wolę mieć zespół ekspertów, którzy mają szeroką wiedzę ogólną (niekoniecznie bardzo głęboką), niż zespół złożony z ludzi, którzy wiedzą trochę o wszystkim, ale napotykając na poważny problem, nie są wstanie prawidłowo go opisać i zadać pytania. Jest jeszcze trzecia, moim zdaniem najgorsza grupa. Zespół ekspertów, którzy dziobią tylko własną działkę, nie wykazując zainteresowania resztą. Zresztą zaczął się sezon skoków narciarskich, a przecież każdy z nas jest ekspertem w tej dziedzinie.
Buy vs Build
Kolejna kwestia, która wynika bezpośrednio z PE, to wybory, których dokonujemy. Zastanówmy się przez chwilę, jakie jest WHY każdej firmy. Odpowiedź brzmi zarabiać pieniądze. Praktycznie poza kilkoma wyjątkami każda firma jest nastawiona na zarabianie pieniędzy. Ile? Nie koniecznie jak najwięcej, ale wystarczająco dużo by zaspokoić udziałowców.
//offtopic
Jedną z nienastawionych na zysk form pracy jest spółdzielnia pracy. Celem spółdzielni jest zapewnienie zatrudnienia spółdzielcom. Nie oznacza to, że spółdzielnia nie ma zarabiać. Ma zarabiać, ale nie jest to najważniejsze zadanie. Zresztą zyski spółdzielni dzieli się pomiędzy spółdzielców.
//offtopic
Jeżeli mamy firmę, która produkuje oprogramowanie, a do tego sprowadzają się firmy outsourcingowe, to nie powiem klientowi „słuchaj my ci sprzedamy produkt naszej konkurencji”. To jest pozbawione sensu. Jeżeli chciałbym sprzedawać gotowe rozwiązania, to zostałbym re-sellerem. Jest jeszcze coś co umyka wielu osobom, które nie pracowały w outsourcingu IT. Instytucje, które „kupują ciała”, to nie są firmy, które nie potrafią albo nie chcą kupować gotowych produktów. Bank kupuje JIRE nie dlatego, że jest taka wspaniała i nie mógłby napisać własnego, podobnego rozwiązania. Kupuje, bo jest to produkt pudełkowy, dostarczany jako archiwum tar.gz, ale to nowa forma pudełka. Kupuje, ponieważ nie jest to produkt związany z głównym biznesem banku. Tak samo kupuje się szyny rozliczeniowe, czyli aplikacje do obsługi komunikacji z systemami rozliczeniowymi, bo to nie jest coś nietypowego. Bank kupuje ciała, i obarcza je zakazami konkurencji, ponieważ potrzebuje produkować bardzo specyficzny soft lub utrzymywać własną infrastrukturę. Coś, co jest charakterystyczne tylko dla danego banku i co buduje jego przewagę konkurencyjną.
To samo dotyczy traktowania kodu jako własnego dziecka. Z Jarka Pałki (który kogoś cytował, ale nie pamiętam kogo):
Dobra architektura, to architektura, której nie szkoda wyrzucić.
Podobnie ma się rzecz z kodem. Dobrzy programiści nie boją się wyrzucić własnego kodu, bo to tylko forma zapisu wiedzy. Wiedzy tak łatwo z głowy nie wyrzucimy. I znowuż Wojtek mówi dostarczmy, byle co, byle szybko, a potem będziemy się martwić i poprawiać. Nie chciałbym się leczyć w sprzęcie programowanym w takim startupowym stylu. Zresztą nie musi być to sprzęt medyczny czy krytyczna aplikacja bankowa. Facebook czy Apple mogą wypuścić gówniane rozwiązanie. Nie tylko ich stać, ale przede wszystkim mają na tyle mocną pozycję, że potencjalny bojkot konsumencki mogą zignorować. Mniejsze firmy nie mają takiego luksusu. Sprzedaż produktu w fazie „wczesna beta” wiąże się z bardzo dużym ryzykiem. W dodatku ryzyko to jest nieproporcjonalne do potencjalnych zysków.
Co ciekawe w kolejnych argumentach Wojtek zaprzecza sobie. Nagle okazuje się, że rozwiązania „too fast” nie są najlepsze, bo zazwyczaj adresują problem w zły sposób. Nagle potrzeba nam komunikacji z biznesem, bo sami tak szybko nie ogarniemy domeny. No nie trzyma się to kupy. Albo znamy WHY klienta, albo rozmawiamy z klientem o rozwiązaniach bez głębokiego wnikania w zasady działania specyficznego biznesu. Albo szybko dowozimy produkt, ryzykując złe adresowanie, albo robimy porządną analizę i solidne rozwiązanie, co trwa. Tu przechodzimy do kolejnej kwestii.
Wychodzenie ze strefy komfortu
No nie, nigdy w niej nie byliśmy. Wszystkie rzeczy o których mowa w prezentacji zamykają się w świętej trójcy szybko-dobrze-tanio. I dotyczy to każdego rodzaju inżynierii. Kolejny cytat w prezentacji pochodzi z Mario Andrettiego i moim zdaniem jest on na miejscu. Co ma on do strefy komfortu?
Po 18 latach turlania się po tatami wiem co mogę zrobić, a czego nie. Andretti nigdy nie opuścił swojej strefy komfortu. Nie musiał, bo potrafił dostosować prędkość do panujących warunków. Jako dobry programista wiem kiedy mogę olać TDD, a kiedy mogę je przytulić. Ta umiejętność cechuje ekspertów. Znają swoje granice i wiedzą kiedy mogą je bezpiecznie przekraczać. Wyjście ze strefy komfortu jest zgrabnym pojęciem z zakresu sprzedaży głupcom.
Wisienką na tym torcie jest stwierdzenie, że stare firmy są wygryzane przez młode. Pamiętacie procesory CyrixW? Nie? Byli najlepsi i najszybsi, ale jakoś nie wygryźli starych i powolnych wyjadaczy jak Intel(rok zał. 1968) czy AMD(rok zał. 1969). Dlaczego? Ponieważ jeżeli firma jest wystarczająco duża, to w najgorszym przypadku stanie się nudna. Jak IBM czy Microsoft. Ubrana w korpo-procedury armia ludzi. Sukces, o którym wspomina Wojtek, nie jest wynikiem przewagi nad wielkimi graczami, a wejścia w niszę rynkową, która dla dużych nie jest istotna. Facebook wygrał, bo Google odpuścił usługi społecznościowe. Zanim Google się połapał co i jak było pozamiatane.
Czy my w Polsce
W tym miejscu jest już źle. Bardzo źle, bo o ile wcześniejsze dywagacje Wojtka dotyczące branżuni, to nasza wewnątrz plemienna filozofia, to mówienie o mindsecie wymaga, znowuż, solidnych podstaw w źródłach. Pozwolę sobie rozprawić się po kolei.
Lepsze firmy, bogatsi inwestorzy, większy rynek
No sorry, ale tak to działa. W Polsce inicjatywy typu Booksy chwytają słabiej, bo też jest na nie mniejsze zapotrzebowanie. Jeżeli ktoś dobrze zarabia, jak na nasze warunki, to nie zatrudnia sprzątaczki by raz w tygodniu ogarnęła mieszkanie, bo go nie stać. Jeździmy starymi samochodami, bo nas nie stać. To samo tyczy się wszystkich innych zakupów. Uważnie oglądamy każdą złotówkę, bo jako społeczeństwo jesteśmy biedni i oszczędzamy gdzie się da.
Bogaci rodzice, większa stabilność
Bogatsi rodzice mogą zapewnić dzieciom lepsze wykształcenie. Nawet jeżeli bogactwo oznacza możliwość wysłania dziecka na „obóz z niemieckim” (w okolice Dachau – Mysza na taki pojechała kiedyś dawno temu), to jest to gigantyczna przewaga nad dzieciakami z rodzin, których nie stać na takie „luksusy”. Co zatem z całymi społeczeństwami, które dzięki swojej otwartości mogły się rozwijać?
Jeżeli stracę pracę, to czy pewność wysokiego zasiłku dla bezrobotnych, powiedzmy 90% ostatniej pensji przez 6 miesięcy, nie motywuje mnie do szukania pracy w zawodzie, a nie jakiejkolwiek pracy, nawet znacznie poniżej kwalifikacji i w efekcie opuszczenia rynku pracy? Czy nie oznacza, to lepszej alokacji talentów obywateli? Takie mechanizmy zbudowały Europę Zachodnią. Ich brak odbija się w Polsce, bo nie dość, że jesteśmy biednym społeczeństwem, to jeszcze dodatkowo marnujemy zasoby. Takie marnowanie opisał Kamil Fejfer w Zawodzie. Nieskładnie, ale zawsze. O tym pisał, znacznie lepiej, Filip Springer w „13 Pięter”. O tym też pisze Chang Ha-Joog w „23 rzeczach, których nie mówią ci o kapitalizmie”. Bez mocnych fundamentów społecznych nie wybudujemy nowoczesnej gospodarki.
Klasyczne, konserwatywne biznesy
Jesteśmy krajem na dorobku. Krajem wysoko rozwiniętym, ale nadal stosunkowo biednym. Wróćmy na chwilę do statystyk związanych z zarobkami, a pośrednio z możliwościami zakupowymi obywateli. Jak już wiemy średnie zarobki programisty Java w Polsce to niecałe 38 tys. USD. Jeżeli przeliczymy to na euro, to otrzymamy około 32 tys. EUR (po kursie z początku grudnia 2017). Teraz porównajmy to z średnim wynagrodzeniem w UE. Nie podam tu kwoty by nie psuć niespodzianki (ale jest w źródle strony). Powiem to dosadnie. Jeżeli kurwa myślisz, że masz szmal jako java dev, to kurwa się grubo mylisz. Przyczynę już znamy, ale jakie jest rozwiązanie? Przeczytajcie wywiad z Pawłem Dobrowolskim.
I wtedy wchodzi Elon Musk, cały na biało
Prezentacja dotarła do miejsca, gdzie pojawił się bohater. Elon Musk, który wyszedł ze strefy komfortu, zaryzykował i stworzył PayPala. Firmuje swoim nazwiskiem Teslę, bo nie jest większościowym udziałowcem, a w SpaceX ma ponad 50% udziałów, ale nie ma wyłącznego prawa głosu (trzeba mieć około 80%). Rzecz w tym, że jemu się udało. Nie udało się AOL, ani Yahoo, ani też wielu innym firmom. W tym miejscu prezentacji widzimy klasyczny błąd przeżywalnościW. Zakładam, że to nie jest celowe działanie, ale mówienie, że kilka osób nakręca sukcesy kolejnych firm i jeżeli będziemy tak jak one, to wygramy, jest nieprawidłowe. Toż to klasyczny cherry picking. Widzimy tylko zwycięzców. Ile dużych firm upadło. Co więcej ten błąd może doprowadzić do wniosku, że kopiowanie rozwiązań jest drogą do sukcesu. Nie jest. Co prawda przewija się motyw bankructwa Muska, ale znowuż odsyłam do „23 rzeczy…”, gdzie opisany jest mechanizm powstania czegoś takiego jak spółka Ltd. Elonowi Muskowi nigdy nie groziło bankructwo. Dzięki zabezpieczeniu de iure mógł zwinąć SpaceX, ale nadal miałby bardzo dużo pieniędzy.
Podsumowanie wg. Wojtka
Na koniec Wojtek odwołuje się do piramidy związanej z zyskami. Problem nie jest nowy i na zachodzie jest coraz częściej podnoszony. Nierówności płacowe i związane z ryzykiem są badane i wskazywane jako przyczyna wielu problemów społecznych. Chociażby kryzys z 2008 roku. Najbardziej poszkodowani zostali zwykli ludzie. Bankierzy nie ucierpieli. Co więcej, nadal radośnie kombinują, chociażby w Legnickiej SSE na pl. Dominikańskim we Wrocławiu.
Kryzys
Będzie. W dodatku silnie dotknie branżunię. Obecnie na rynku kumulują się problemy, które znamy już z dawnych czasów. Kryzys finansowy, w połączeniu z kryzysem zatrudnienia. Zarówno rewolucja przedindustrialna, która wprowadziła na rynek manufaktury, jak i rewolucja przemysłowa były związane z brakiem rąk do pracy. Pierwsza w wyniku epidemii, które dotknęły kilka pokoleń, a druga w wyniku wojen, które trwały przez ponad 200 lat. W obu przypadkach nastąpiła optymalizacja procesów produkcyjnych i automatyzacja pracy. To samo czeka rynek IT. Brak rąk do pracy oznacza, że będzie trzeba automatyzować.
Jesteś devem, umrzesz devem
Rozwiązania proponowane przez Wojtka nadają się niestety na buniowy profil Zausz Firmę. Niemiecki system edukacji kształci mechaników samochodowych mniej więcej od 13 roku życia. Na zawodach iaido, w finale rzadko widać osoby młodsze niż 60 lat. Skakanie ze specjalizacji do specjalizacji nie jest wbrew pozorom drogą do sukcesu. Można rozważyć taki model, ale trzeba pamiętać o ryzyku i o tym, że niewielu wygrywa. W dodatku należy założyć, że nie wiemy wszystkiego o zwycięzcach. Koniec końców Musk swój kapitał społeczny budował jako biały w podzielonym rasowo RPA. Mówiąc prościej, jego sukces jest, pośrednio, wynikiem pracy niewolników.
Na koniec wraca jeszcze praca prawników jako instytucji dostarczających holistycznych rozwiązań dla klientów. Mam takiego księgowego. Czasami coś ciekawego podrzuci. Rzecz w tym, że o ile mój księgowy działa jak tablica ogłoszeń, to prawnicy nie zawsze działają w zgodzie z prawem. Najlepszym przykładem tego typu prawników magików są specjaliści od odzyskiwania kamienic. Niestety.
Podsumowanie
Uodporniłem się na prawdy objawione. W prezentacji zabrakło weryfikacji danych. W ten sposób powstał potworek, który ma w sobie trochę prawdy, trochę magii, trochę zachwycania się nad zajebistością branżuni. IT nie jest branżą wybraną, ale niestety w ostatnich latach wielu ludziom na oczy spadły klapki. Wiara w to, że zarabiając przysłowiowe 15k, jesteśmy narodem wybranym, spowodowała, że nie dostrzegamy rzeczywistości. Specyfika naszej pracy pozwala na więcej, ale nie żyjemy w próżni. Chcemy wierzyć, że prowadzimy ludzi w epokę post industrialna, ale to słaby mit. Zakończę cytatem z Chang Ha-Jooga:
Podsumowując, nawet bogate kraje nie stały się jednoznacznie postindustrialne. Choć większość ich mieszkańców nie pracuje już w fabrykach, to – licząc w kategoriach cen względnych – znaczenie sektora wytwórczego w ich systemach produkcji nie spadło znacząco. Ale nawet jeśli deindustrializacja nie jest z konieczności symptomem upadku przemysłu (choć często bywa), to należy pamiętać o tym, że ma ona negatywne skutki dla wzrostu produktywności w długim okresie i dla bilansu płatniczego. Mit, że żyjemy teraz w erze postindustrialnej sprawił, że wiele rządów zlekceważyło negatywne konsekwencje deindustrializacji.
I pamiętajcie, że pracujecie w usługach, które, choć ciężko zautomatyzować, to jak już to nastąpi…
Posłowie
Ten tekst powstawał przez około 5 miesięcy. To dużo czasu. Jednak całość nadal odzwierciedla moje poglądy co do prezentacji. Wojtka Seligę szanuję jako specjalistę, ale po prostu nie zgadzam się z jego poglądami.
Projekt używa kilku wersji Javy. Tak mniej więcej czterech, czyli od 6 do 9. Nic nadzwyczajnego, ale czasami mavenowi trzeba podstawić inne JDK. I tu zaczyna się robić ciekawie…
Listing 1. Domyślna konfiguracja JDK
$ echo $JAVA_HOME
/usr/lib/jvm/java-9-oracle
To nas nie zadowala z kilku różnych powodów. Maven co prawda ruszy, ale Java 9 poprzerzucała kilka przydatnych rzeczy i na przykład pluginy do generowania kodu nie za bardzo chcą działać. Jak sobie z tym poradzić?
Listing 2. Rozwiązanie proste
$ export JAVA_HOME=~/jdk-8
Tyle tylko, że jak będziemy chcieli coś zmienić, to znowu trzeba eksportować, a tu jeszcze dochodzą różne wydania w ramach „dużej” wersji języka. Można oczywiście to opędzić dodając odpowiedni skrypt i dodając go do $PATH! No nie…
Gdy uruchamiamy skrypt (proces) w bashu, to tworzona jest kopia wszystkich zmiennych środowiskowych i skrypt dział na tej kopii. Nie ma dostępu do zmiennych procesu rodzica. Inaczej mówiąc, jeżeli wykonamy kod z listingu 2 w skrypcie, to po zakończeniu skryptu, zmienna JAVA_HOME w aktualnej powłoce, będzie miała taką samą wartość jak przed wywołaniem skryptu.
To może aliasy? Aliasy mają to do siebie, że są rozwijane w ramach bieżącego procesu, ale nie mogą przyjmować parametrów. Można sobie zdefiniować kilka aliasów i mieć z głowy. Jeżeli jeszcze dodatkowo zautomatyzujemy tworzenie aliasów przy starcie powłoki, tak by opierając się na konwencji nazewniczej, generować alias per folder z JDK, to już miód. Osobiście ten pomysł nie przypadł mi do gustu. Bardzo mocny, ale ma pewną wadę. Jest zbyt dynamiczny jak na mój gust. Tak naprawdę nie wiem, co mam dostępne.
Opcją pośrednią jest zdefiniowanie funkcji w pliku .bashrc. Funkcja taka jest wykonywana w kontekście bieżącej powłoki. Mamy do niej dostęp i możemy ją swobodnie modyfikować.
Listing 3. Przykładowa implementacja.
use-java(){
export JAVA_HOME=~/jdk-"$1"
}
Podsumowując, należy raz jeszcze wspomnieć, że skrypty (procesy) uruchamiane w powłoce są odseparowane od środowiska rodzica i nie mogą go zmieniać. Warto o tym pamiętać, bo pozwala, to na uniknięcie wielu uciążliwych błędów.
Nowa fabryka, nowy projekt, nowe wyzwania. Tak można by podsumować ostatnie trzy tygodnie w moim wykonaniu. Projekt został przejęty po innej firmie, która się zwinęła z rynku. Otrzymaliśmy niewydolne repozytorium svn z pełną historią, dokumentację i tyle. Kilka osób w zespole przeszło z tamtej firmy, ale jest to dla nich stan przejściowy. Co najważniejsze nie mamy, poza kodem, nic innego. Trzeba wszystko zestawić praktycznie od zera.
Dziś chciałbym opisać nasz pomysł na code review. Jednak zanim do tego przejdę, to krótkie wprowadzenie, które przybliży, dlaczego wybraliśmy takie, a nie inne rozwiązania.
Dlaczego Phabricator?
Jak już wspomniałem mamy kod, ale nie mamy żadnego narzędzia, które pozwoliłoby nam na organizację procesów. Nie mamy też budżetu na zakup JIRY, a charakter projektu, bankowy core, wyklucza wypchnięcie całości na rozwiązanie chmurowe w rodzaju Githuba czy Bitbucketa. Poszukiwaliśmy zatem rozwiązania opensource, bezpłatnego w opcji self-hostingu, oraz kompletnego. Kompletność oznacza, że w jedynym narzędziu, albo grupie narzędzi współpracujących ze sobą, mam dostęp do wszystkich elementów związanych z prowadzeniem projektu. Tak właśnie działa JIRA z przyległościami. Grupa narzędzi, które możne ze sobą łatwo zintegrować. Jednak JIRA jest poza zasięgiem budżetu. Po krótkim rozpoznaniu wybór padł na Phabricatora.
Phabricator jest otwarty, bezpłatny i zawiera wszystko, czego potrzebujemy. Jest obsługa zgłoszeń, wiki, kanban board, zarządzanie repozytoriami kodu, CI oraz narzędzia do code review. Całość napisana w php, co oznacza, że wystarczy bardzo prosta konfiguracja po stronie serwera. Do tego całość jest żywa, to znaczy aktywnie rozwijana, oraz sprawdzona przez większych graczy np. Ubera, Facebooka, czy Fundację Wikimedia. Proces instalacji i konfiguracji jest bardzo prosty i dobrze opisany w dokumentacji. Aktualizacja do nowszej wersji polega na zatrzymaniu serwisów, zrobieniu git pull i ponownym uruchomieniu serwisów.
Przejdźmy zatem do dania głównego tego wpisu, czyli narzędzia do code review.
Rodzaje Code Review
Przegląd kodu można prowadzić na wiele sposobów. Każdy z nich ma zalety i wady. Każdy może też być dobrze i źle wdrożony. Nie twierdzę, że nasz pomysł jest najlepszy z możliwych, ale na chwile obecną wydaje się najsensowniejszy. Przyjrzyjmy się jakie mamy możliwości i czym się różnią.
Przeglądy post-commit
Jak sama nazwa wskazuje przeglądy takie, są wykonywane na kodzie, który już znajduje się w repozytorium. Typowy proces pracy wgląda w tym przypadku w następujący sposób:
Anna commituje zmiany do repozytorium. Najczęściej na osobną gałąź.
Następnie tworzy CR request, czyli w narzędziu oznacza commit albo grupę commitów jako gotowe do przeglądu.
Mike wykonuje przegląd, dodają uwagi.
Anna wprowadza poprawki i rozszerza CR o kolejny commit. Rozszerzenie może dziać się automatycznie.
Mike akceptuje poprawki i zamyka CR
W tym momencie możliwe są dwa scenariusze. Zamknięcie CR automatycznie łączy gałąź ze zmianami z gałęzią główną. Warunkiem koniecznym jest możliwość złączenia bez konfliktów. Drugi scenariusz to ręczne łączenie gałęzi.
Takie podejście jest o tyle fajne, że jest bardzo proste w implementacji. Zazwyczaj nie wymaga żadnych dodatkowych narzędzi poza narzędziem do CR. Całość opiera się na poleceniach naszego VCS-a. W dodatku jesteśmy niezależni od silnika VCS. Wady są dwie. Po pierwsze przeglądany kod jest już w repozytorium. Po drugie nie wszystkie silniki VCS są, wstanie płynnie działać w ten sposób. Chyba najlepszym przykładem jest SVN i jego model tworzenia gałęzi. Dla dużej ilości danych będzie to powolne, a ciągły schemat nadawania numerów wersji będzie tylko przysparzał problemów. W dodatku nie mamy możliwości zablokowania commitowania do głównej gałęzi. Podobnie w git. Co prawda można tak skonfigurować narzędzia, by nie akceptowały commitów bezpośrednio do mastera i pozwalały jedynie na pull requesty, ale na „czystym” gicie jest to, co najmniej uciążliwe.
Audyty
W praktyce podejście post-commit nie służy do CR rozumianego jako element wewnętrznego procesu w zespole. Podejście to służy do audytu kodu przez podmiot zewnętrzny. Załóżmy, że dowieźliśmy sprint na czas. Jednym z artefaktów końcowych, jest opis zmian w kodzie w formacie podobnym, do tego którego używamy do CR. Nasz klient wysyła taki pakiet do na przykład usługi Veracode, gdzie zmiany są badane pod kątem luk bezpieczeństwa. Inaczej mówiąc, wszystkie zamiany wprowadzone przez zespół podlegają przeglądowi przez niezależny podmiot.
Phabricator wspiera ten model i co ciekawe jest to osobny moduł. Audyty są czymś niezależnym od CR. Jest to osobne menu.
Pull request
Wspomniałem wyżej, że w gicie można wykorzystać trochę inny mechanizm, a mianowicie pull requesty. Schemat działania jest podobny do poprzedniego. Też trzeba zacommitować zmiany do gałęzi w zdalnym repo (bare), a następnie wypchnąć zmiany do własnego repozytorium. Kolejnym krokiem jest stworzenie PR-ki do repozytorium docelowego. I działa to świetnie. PR-ka może zostać przejrzana i zaakceptowana bądź odrzucona. Kolejne zmiany w naszym repozytorium będą uwzględniane w PR-ce we w miarę zautomatyzowany sposób. Oczywiście o ile korzystamy z jakiegoś narzędzia w rodzaju githuba.
Zresztą jest to najpopularniejsza metoda pracy z repozytoriami na githubie. Ma jednak pewien feler. W pewnym momencie mamy dwa repozytoria, które mają w głównych liniach kodu dwie różne wersje kodu. Można to naprawić. Wystawiając PR gałęzi z naszego repozytorium do głównej gałęzi repozytorium docelowego… co efektywnie można zredukować do commitowania do gałęzi w repozytorium docelowym i w efekcie PR staje się takim post-commit CR, tyle tylko, że jest ładniej nazwane. Dodatkową wadą jest ograniczenie się do rozproszonych VCS-ów. Jeżeli chcemy zrobić coś takiego w SVNie, to musimy korzystać z mirroringu i personal upstreamów, które są zwyczajnym hakiem.
Przeglądy pre-commit
I tu dochodzimy do przeglądów wykonywanych przed commitem. Przy czym „przed commitem” oznacza, że zmiana nie wycieka poza nasze lokalne repozytorium. Na czym to polega. Zamiast wysyłać zmiany do zdalnego repozytorium, przygotowujemy patch file, który będzie podlegać przeglądowi. Taki patch file jest traktowany jako wsad do narzędzia CR. Akceptacja zmian pozwala nam na ich opublikowanie w zdalnym repozytorium.
Taki model jest przyjęty wśród programistów jądra. Linus ostatecznie akceptuje lub odrzuca zmianę. Zanim zmiana trafi do niego, jest oczywiście przeglądana przez opiekunów poszczególnych modułów, a oni otrzymują wstępnie przesiane zmiany przez opiekunów poszczególnych plików lub fragmentów kodu. Ci są adresatami zmian, które są tworzone przez zwykłych programistów. Oczywiście opisuję tu model w sposób uproszczony, ale to mniej więcej tak działa. Zaletą tego modelu jest to, że zmiana nie jest opublikowana przed akceptacją. W dodatku całość jest niezależna od systemu VCS, ponieważ opiera się na patch filach, które są standardem. Najpoważniejszą wadą jest użycie formatu patch file, który ma pewne ograniczenia m.in. w przeciwieństwie do PR nie można ich budować ze zmian, które mają różnych autorów. Drugą wadą jest konieczność przestrzegania procesu, bo narzędzia nie radzą sobie jeszcze z np. commitem bez zatwierdzenia CR. Tu na scenie pojawia się phabricator i jego narzędzie arcanist.
Dlaczego nie gerrit?
Tu dochodzimy do kolejnego pytania. Dlaczego nie użyć gerrita? Z bardzo prostej przyczyny. Gerrit pracuje tylko z repozytoriami git, a obsługa svn jest możliwa tylko poprzez git-svn. Tyle tylko, że git-svn wymaga gita, a my nie możemy go użyć w jednym z naszych projektów. W dodatku jest to kolejne narzędzie, które wymaga uwagi z naszej strony.
Dlatego arcanist
Arcanist jest konsolowym interfejsem phabricatora. Daje on dostęp do różnych modułów, ale my skupimy się na module differential, który służy do zarządzania CR.
Mała uwaga, w dokumentacji Differentiala jest mowa o pre-push CR. Wynika to z popularności gita i gitowej nomenklatury. W przypadku svn-a jest to oczywiście pre-commit.
Instalacja i konfiguracja projektu
Żeby móc korzystać z arcanista należy go zainstalować. W przypadku linuxów znajduje się on w pakiecie arcanist, który wymaga instalacji php7. Dodatkowo należy zainstalować najnowszą wersję pakietu php7.0-xml/php7.1-xml. Pakiet ten nie jest w podstawowej dystrybucji php i trzeba go samodzielnie zainstalować.
Po zainstalowaniu arcanista należy jeszcze skonfigurować projekt. Konfiguracja jest bardzo prosta. W katalogu głównym należy utworzyć plik .arcconfig, który jest prostym JSON-em:
Zgodnie z dokumentacją minimalna konfiguracja może być ograniczona tylko do własności phabricator.uri, ale bez repository.callsign arcanist może mieć problemy z rozpoznaniem repozytorium projektu. Teoretycznie robi to automatycznie, ale nie zawsze to wychodzi. W szczególności gdy nazwa lokalna różni się od zdalnej.
Tworzenie CR
Proces tworzenia CR jest niezależny od silnika VCS, którego używamy. Phabricator wspiera git-a, svn-a i mercicurala więc nie jest źle. Po wprowadzeniu zmian w kodzie wystarczy w linii poleceń uruchomić:
Listing 2. Tworzenie CR
$ arc diff
Zostanie uruchomiony edytor, w moim przypadku jest to nano, w którym musimy wypełnić szablon z informacjami:
Listing 3. Szablon CR
<<Replace this line with your revision title>>
Summary:
Test Plan:
Reviewers:
Subscribers:
# NEW DIFFERENTIAL REVISION
# Describe the changes in this new revision.
#
# arc could not identify any existing revision in your working copy.
# If you intended to update an existing revision, use:
#
# $ arc diff --update <revision>
Obowiązkowymi polami są tytuł, podsumowanie i plan testów. Pola Reviewers i Subscribers są opcjonalne i podajemy tam loginy. Po zapisaniu i wyjściu z edytora arcanist utworzy CR w phabricatorze. W tym celu używa crul-a.
Jeżeli pracujemy z gitem, to nie musimy wykonywać git commit, bo arc diff zrobi to za nas. W przypadku svn-a zostanie wygenerowany patch file i nie będzie zmian w repozytorium. Pytanie, które zmiany są brane do CR? Odpowiedź jak zawsze brzmi, to zależy. W przypadku svn-a jest są to zmiany, które są widoczne w svn status. W przypadku git-a są to zmiany widoczne w po zaaplikowaniu git merge-base origin/master ..HEAD. Inaczej mówiąc wszystkie różnice pomiędzy aktualna gałęzią, a zdalnym masterem.
Akceptacja CR i różnice pomiędzy VCS-ami
Jeżeli chcemy zobaczyć, jakie CR czekają na nas, wystarczy wydać polecenie arc list.
Listing 4. Lista oczekujących CR
$ arc list
* Needs Review D6: Testowe CR w svn
Należy tu zwrócić uwagę na identyfikator CR. W tym przypadku jest to D6. Będzie on nam potrzebny do dalszej pracy z arcanistem. Jeżeli CR-ka zostanie zaakceptowana, to wystarczy klepnąć zmianę i wysłać ją do repozytorium. Niestety nie ma jednego spójnego interfejsu do wykonania tej operacji.
Listing 5. Zamknięcie niezaakceptowanego CR w svn-ie
$ arc commit --revision D6
Revision 'D6: Testowe CR w svn' has not been accepted. Commit this
revision anyway? [y/N] N
Usage Exception: User aborted the workflow.
Oczywiście można wymusić zamknięcie CR i wysłać zmiany do repozytorium.
Listing 6. Zamknięcie niezaakceptowanego CR w git
$ arc land --revision d7
Landing current branch 'master'.
TARGET Landing onto "master", selected by following tracking branches upstream to the closest remote.
REMOTE Using remote "origin", selected by following tracking branches upstream to the closest remote.
FETCH Fetching origin/master...
This commit will be landed:
- 4affd51 OK
Revision 'D7: OK' has not been accepted. Continue anyway? [y/N]
Usage Exception: User aborted the workflow.
Jak widać svn i git mają osobne polecenia. To nie jest najfajniejsze rozwiązanie, ale daje radę. Jeżeli CR zostało zaakceptowane, to nie otrzymamy komunikatu, że coś wisi, tylko zmiana zostanie wysłana na serwer. Tu właśnie wychodzi największa zaleta modelu pre-commit/pre-push w porównaniu do pull requestów. Zgłoszenie CR jest nieblokujące. Oczywiście, jeżeli ktoś odwali maniane i wyśle kod, który nie był przejrzany, to odpowiednia adnotacja pojawi się w historii CR. Winny zostanie już odpowiednio nagrodzony…
Za i przeciw
Czas na krótkie podsumowanie. Phabricator ma bardzo dobrze przemyślany mechanizm przeglądów kodu. W dodatku jasno rozgranicza przeglądy od audytów. Wspiera kilka różnych rodzajów repozytoriów. Co prawda interfejs nie jest spójny, ale różnice są minimalne. Całość jest nieblokująca i w przeciwieństwie do klasycznych gitowych PR łatwiejsza do zrozumienia.
Rozwiązanie nie jest pozbawione wad. Największą jest konieczność używania arcanista, który jest dodatkowym oprogramowaniem. Jeżeli używamy niestandardowego sposobu zarządzania commitami, to musimy zapomnieć o automatyzacji niektórych czynności. Gotowe rozwiązania muszą zostać dostosowane. Niektórych może też zaboleć, że całość jest w php, co powoduje, że kod jest rozszerzalny dla zespołów niephpowych.
Podsumowując, lubię i polecam. Pobawić się można, a potencjalne korzyści są duże. Jeżeli zatem szukasz narzędzia do ogarniania projektu, to phabricator będzie całkiem fajny.
Zasadniczo leżę i kwiczę. W zasadzie to cichutko pokwikuję. Bywa, zdarza się najlepszym. Oczywiście przeglądam sobie internety i trafiam na ten oto wywiad. Co w środku? Ano taka oto perełka:
Odwrócę pytanie. Czego absolutnie nie polecasz osobie uczącej się programować?
Pójścia na studia. Przynajmniej w Polsce. To będzie strata czasu i brak konkretnego przygotowania do pracy.
Kilka dni temu prowadziłem rozmowę rekrutacyjną do mojego teamu. Trafił nam się osobnik, który ogólnie rzecz ujmując, studiował dość dokładnie, licencjat robił już siódmy rok. Przy czym studiował kierunek spokrewniony – elektronikę. Jednak studia zapewne były tylko dodatkiem do pracy, bo pracował już z pięć czy sześć lat i to jako programista. Na czym poległ?
Poległ na dwóch prostych pytania, na które odpowiedź poznałby na studiach:
Co to jest transakcja?
Co to jest sekcja krytyczna?
Easy, prawda?
ps. Bohaterka wywiadu prowadzi podobno bloga technologicznego. Tyle tylko, że mało tam treści technologicznych, a więcej life stylowych.
