Maciej Aniserowicz's Blog, page 9

January 15, 2020

January 12, 2020

Czterej jeźdźcy gnijącego designu

Gdy zaczynamy nowy projekt, spędzamy mniej lub więcej czasu na jego projektowaniu. Często mamy jasny obraz tego, jak powinno wszystko działać, jakie mamy założenia, na co pozwalamy, a na co nie. W rezultacie otrzymujemy design, który w danym momencie wydaje nam się najlepszym rozwiązaniem. Wszyscy rytualnie podpisujemy się pod nim krwią i postanawiamy nie łamać jego założeń.


Na razie wszystko jest dobrze, development idzie gładko, pierwsze wersje lądują na produkcji i zaczynają spływać pierwsze żądania zmian czy też nowych funkcjonalności. Jednak prędzej czy później w aplikacji pojawiają się małe odstępstwa od pierwotnych założeń. Tu jakieś obejście, tam jakieś obejście. A bo to tylko na chwilę, zobaczymy, czy to się w ogóle sprawdzi. A bo na szybko trzeba załatać buga itd. Nasz oryginalny design zaczyna gnić i nie przypomina tego, co żmudnie wypracowaliśmy na samym początku. W pewnym momencie osiągamy stadium, w którym padają magiczne słowa: „To wszystko trzeba przepisać”. I tu pojawia się problem, bo nie wszyscy muszą być tego samego zdania, a w szczególności ludzie, którzy nie mają styczności z kodem, ale za to są osobami decyzyjnymi. Wtedy może dojść do sytuacji typu: „Działa? Działa. No to jedziemy dalej!”. Ostatecznie może się okazać, że nie tak łatwo przeforsować owo przepisanie, i przyjdzie nam wypić piwo, które sami nawarzyliśmy. W tym momencie wprowadzanie jakichkolwiek zmian staje się zarówno bardzo trudne, jak i frustrujące, i to nie tylko dla programistów, ale też dla osób zlecających nowe funkcjonalności.


Możemy teraz zacząć szukać winnych i tłumaczyć sobie, że przecież to wszystko przez ciągle zmieniające się wymagania, że klient sam nie wie, czego chce, że skąd niby mieliśmy wiedzieć, że to ma być tak, a nie inaczej. Racjonalizacja to bardzo wygodna i skuteczna metoda. Zdarza się, że z przyczyn niezależnych rzeczywiście mamy związane ręce. Mimo to żąda się od nas, aby kod był odporny na takie zmiany. Dlaczego? Bo w większości wypadków pracujemy w metodykach zwinnych, a one zakładają, że wymagania będą się zmieniać, i naszym zadaniem oraz zadaniem naszego designu jest wychodzenie naprzeciw wymaganiom klientów.


Ale spokojnie, rozluźnijmy się trochę i zagrajmy w BINGO:


Rys. 1. Rotting design BINGO


I jak? Jest „BINGO!” czy nie? Jeśli „wygrałeś”, mam dla Ciebie dwie wiadomości: dobrą i złą. Zła jest taka, że chyba właśnie zmagasz się z psującym się designem, a dobra to taka, że postaram się rzucić trochę światła na chorobę, która go toczy. Zanim to jednak nastąpi, chciałbym, żebyśmy przyjrzeli się bliżej tym przykładom. Każdy z nich charakteryzuje się występowaniem jednego z czterech głównych symptomów psującego się designu.


Symptomy gnijącego designu
Symptom nr 1 – sztywność

Oznacza to, że z pozoru prosta, niewinna modyfikacja w kodzie powoduje lawinę nieprzewidzianych zmian, a każda kolejna pociąga za sobą następną. Rozlewa się po kodzie na coraz większe obszary, zajmując zależne klasy. Tym samym te – jak się wydaje – trywialne zmiany są bardzo trudne do wprowadzenia, bo wymagają korekty w wielu innych miejscach.


Przykładem z życia może być sytuacja, gdy Product Owner pyta, ile czasu zajmie dorzucenie checkboxa do formularza, a wy odpowiadacie, że dwie osoby będą nad tym pracować cały sprint. Niewiarygodne? Zaręczam, że prawdziwe.


W rezultacie problemy, które nie są krytyczne dla aplikacji, nie są naprawiane, ponieważ Product Owner czy inny manager zwyczajnie boją się zlecić ich naprawienie, nie wiedząc, na jak długo programista może przepaść.


Symptom nr 2 – kruchość

Jej występowanie możemy zauważyć, gdy przy zmianie w jednym miejscu zaczynają pojawiać się bugi w miejscach logicznie niezwiązanych z samą zmianą.


Naprawiliście politykę obliczania VAT-u, ale stało się to przyczyną trzech innych błędów obejmujących: dodawanie produktów do koszyka, filtrowanie użytkowników w panelu administratora i logowanie wyjątków.


Znowu pojawia się strach, bo nie wiadomo, czy naprawa błędu nie spowoduje tego, że biznesowo istotne funkcjonalności losowo przestaną działać. Wkrada się też podejrzenie, że programiści mogli stracić kontrolę nad kodem.


Symptom nr 3 – nieruchliwość

Teraz wyobraź sobie sytuację, że pisząc nową funkcjonalność, wiesz, że gdzieś w kodzie jest kawałek, który idealnie by pasował do tego, co masz zamiar zrobić, zarówno pod kątem funkcjonalności, którą realizuje, jak i kontekstu użycia. Odnajdujesz go, analizujesz z każdej strony, a następnie zostawiasz i piszesz to samo, tylko w nowym miejscu. Dlaczego? Bo oceniasz, że narzut związany z jego ponownym użyciem – wyodrębnieniem i spełnieniem jego zależności – jest tak duży, że zwyczajnie się to nie opłaca. W tym przypadku kończymy z klasami, które po prostu nie nadają się do ponownego użycia.


Symptom nr 4 – lepkość

Istnieją w zasadzie dwa sposoby wprowadzania zmian: zgodnie lub niezgodnie z aktualnym designem. W przypadku kiedy łatwiej jest nam działać według drugiego z tych sposobów, oznacza to, że mamy do czynienia właśnie z lepkością. Możliwe, że spotkaliście się z sytuacją, kiedy wiedzieliście, jak „powinno” się coś napisać, ale ostatecznie po analizie, ile by to zajęło, zapadała decyzja, że na razie zrobi się mały wyjątek, żeby szybko coś dowieźć. Podsumowując – wygodniej i sprawniej jest nam dorzucić tzw. „hack”, niż trzymać się założeń designu.


Rys. 2. Cztery główne symptomy psującego się designu


Złe zarządzanie zależnościami

Dotarliśmy do momentu, kiedy trzeba odpowiedzieć na pytanie: właściwie jaka choroba trawi nasz design? Skoro powiedzieliśmy wcześniej, że niekoniecznie są to zmieniające się wymagania, to co to może być innego? Najczęściej okazuje się, że jest to złe zarządzanie zależnościami w naszym kodzie. Z pomocą przychodzą nam tu dwa stare pojęcia: „coupling” (myślę, że angielska forma jest tak popularna, że wybaczycie mi posługiwanie się właśnie nią) i „kohezja”.


Coupling można zdefiniować jako stopień zależności między klasami czy modułami, siłę ich relacji. Zwykle mówi się o dwóch typach couplingu, czyli o słabym i mocnym. Jednak jak to w życiu bywa, jeśli są jakieś skrajne wartości, to musi być coś między nimi, i tak też jest w tym przypadku. Dowiesz się więcej na ten temat w kolejnym wpisie.


Jeśli chodzi natomiast o kohezję, to jest to określenie tego, jak bardzo elementy już pojedynczej klasy „pasują do siebie”. Wszystkie one powinny efektywnie ze sobą współpracować w konkretnym wspólnym celu. Powinny wręcz naturalnie się zazębiać, bez potrzeby stosowania jakiegoś „kleju” do ich połączenia. W przypadku spójności najczęściej mówi się o niej jako o niskiej lub wysokiej, i tutaj niespodzianka – również jest coś pomiędzy.


W ogólnym rozrachunku dobry design, czyli taki, który jest łatwy w utrzymaniu i odporny na zmiany, charakteryzuje się tym, że klasy są niezależne i słabo powiązane ze sobą oraz wykonują dokładnie określone czynności. Innymi słowy: w takim designie występują słaby coupling pomiędzy klasami i wysoka kohezja ich samych.


Rys. 3. Silny coupling i niska kohezja (po lewej) oraz słaby coupling i wysoka kohezja (po prawej)


Na teraz to tyle. Zagraj w Bingo w swoim projekcie, poszukaj symptomów gnijącego designu. Już niedługo wrócę z dwoma wpisami, w których szczegółowo opiszę pojęcia couplingu i kohezji.


Chcesz więcej JUŻ TERAZ? >>TUTAJ znajdziesz podcast DevTalk O Programowaniu Obiektowym<< z Tomkiem, autorem tego tekstu!


Trzymaj się ciepło i do przeczytania!


The post Czterej jeźdźcy gnijącego designu appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on January 12, 2020 21:55

January 10, 2020

RUTYNA [vlog #335]


The post RUTYNA [vlog #335] appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on January 10, 2020 13:30

January 9, 2020

January 8, 2020

January 2, 2020

December 31, 2019

December 30, 2019

2019 / 2020 [vlog #330]


The post 2019 / 2020 [vlog #330] appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on December 30, 2019 13:30

December 23, 2019

December 19, 2019

Nieoczekiwany zryw blisko mety. Czyli listopad 2019: podsumowanie i raport finansowy.

Na swoim (nieaktywnym już) profilu na Patronite obiecałem publikować co miesiąc “raport finansowy”. Dodatkowo zamieszczam podsumowanie tego, co działo się w imperium devstyle w ostatnim miesiącu. Pokazuję… wszystko. Bez tajemnic. Enjoy!


A TUTAJ znajdziesz wszystkie moje raporty, poczynając od maja 2017!


Listopad to bardzo ciekawy miesiąc. Strasznie intensywny. Sporo wydarzeń, sporo emocji. Nieco “zbyt sporo” jak na mój gust. Ale sam sobie zgotowałem ten los ;).


Biznesowo: rozbity bank w przedsprzedaży #dbmaster. Temat baz danych ma wielki potencjał, ale sam nie spodziewałem się, że AŻ TAK wielki, już na tym etapie. Damian Widera zaciera ręce i przygotowuje materiał :).


Znowu biznesowo: nie planowałem robić niczego na Black Friday/Cyber Monday, ale finalnie… zrobiłem. Dotrzymuję obietnicy, że u mnie zawsze ceny idą tylko w jednym kierunku (w górę), więc promocją była sama możliwość dołączenia do niektórych Programów. I to też sprawdziło się świetnie.


A mniej biznesowo? Nareszcie mam swoje własne biuro, z własnym… wszystkim! Bo:



Ooooj, będzie się tu działo.


Już jestem umówiony z pewnym specem na konsultacje w temacie “jak najlepiej zrobić tu studio audio/video”. Szykuje się naprawdę fajny i ciekawy czas, gdy tylko pojawią się takie PRO możliwości!


I jeszcze mniej biznesowo: Mikołaj w tym roku odwiedził mnie wcześniej :). Wywołując garść całkiem ciekawych CHYBA refleksji:



Co za tym idzie, pożegnałem się ze swoją ukochaną Toyotką, zastępując ją takim oto potworem. Swoją drogą… poprzedni właściciel mojej GT86 sprzedawał ją przez ponad rok. U mnie sprzedała się w 5 dni. Siła internetów, nie? Rafale, nowy szczęśliwy właścicielu, życzę samych udanych podróży!


A teraz jak zwykle: kasa -> podsumowanie -> linki.


Raport finansowy: przychody

Założenia:



pieniądze (brutto) wpływające na konto w bieżącym miesiącu
usługa mogła być zrealizowana w innym terminie

Pozycje:



Książka “Zawód: Programista”: 4 610,96 zł
Kurs Gita: 22 366,39 zł
Program “DNA: Droga Nowoczesnego Architekta”: 19 667,70 zł
Program DBMaster: 711 905,66 zł
Konferencja Founders Mind – rozliczenie wyjazdu: 1 110,28 zł
DNA: rozliczony fundusz zwrotów: 294 622,72 zł
DNA: zwrot poniesionych kosztów: 113 617,64 zł

W sumie: 1 167 901,35 zł


 



Raport finansowy: wydatki

Założenia:



kwota brutto, znikająca z konta, bez uwzględnienia odliczeń od podatków

Pozycje (linki afiliacyjne):



ZUS: 5 783,00 zł
Stały zespół: 13 929,87 zł

Ania (asystentka / PM / COO)
Magda (slowbiz & gitmastery & marketing)
Julita (księgowa)
Andrzej (montaż video)
Krzysiek (montaż audio)
Agnieszka (korekta tekstów)


PIT-4: 738,00 zł
DNA Droga Nowoczesnego Architekta:

Mentorzy: 220 967,04 zł
grafiki: 2 580,54 zł
rysunki: 1 236,00 zł
montaż: 2 900,00 zł
zgłoszenie znaku słownego: 400,00 zł
zwroty: 9 166,08 zł


DBMaster:

Mentor: 321 959,95 zł
Fundusz Gwarancyjny: 40 000,00 zł
grafiki: 2 041,80 zł
kurier: 26,90 zł
zwroty: 2 397,00 zł


biuro

czynsz: 597,46 zł
Agent nieruchomosci: 5 000,00 zł
Mieszkanie na biuro i studio: pozostała kwota (do 30 tys z października): 227 000,00 zł
firma przeprowadzkowa: 550,00 zł


narzędzia i usługi

Obsługa Klienta (IMKER): 563,34 zł
LibSyn: 58,16 zł
Shoplo (sklep): 60,27 zł
SalesCRM (sklep): 243,54 zł
obsługa płatności online (BlueMedia): 0 zł
obsługa płatności online (Przelewy24): 32,71 zł
obsługa płatności online (TPay): 5 415, 10 zł
telefon Orange: 0 zł
internet T-Mobile: 50,00 zł
XMind Zen: 0 zł (opłacone do 01/2020)
MailTrack: 0 zł (opłacone do 05/2020)
Vimeo: 0 zł (opłacone do 10/2020)
ConvertKit: 0 zł (opłacone do 09/2020)
LeadPages: 0 zł (opłacone do 10/2021)
CoSchedule: 0 zł (opłacone do 09/2020)
Google Storage: 89,99 zł (opłacone do 11/2020)
DropBox: 0 zł (opłacone do 02/2020)
DropBox (dla Ani): 0 zł (opłacone do 01/2020)
infakt: 0 zł (opłacone do 01/2020)
wFirma: 0 zł (opłacone do 09/2020)
ToDoist: 0 zł (opłacone do 11/2020)
SleepCycle: 0 zł (opłacone do 06/2020)
ActiveCampaign: 175,03 zł
Grammarly (dla Magdy): 0 zł (opłacone do 01/2020)
Bear: 0 zł (opłacone do 09/2020)
StreamYard: 97,27 zł
Updraft Plus (WP backup plugin): 0 zł (opłacone do 09/2020)
dhosting.pl: 0 zł (opłacone do 10/2020)
Sonix.ai: 156,50 zł


sprzęt

Oculus Quest + etui: 2 112,41 zł
Głośnik Bose SoundLink Mini II: 699,00 zł


zdrowie

psychoterapia: 880,00 zł


marketing

reklama Facebook: 2 475,99 zł
reklama Google: 0 zł
devstyle grafiki: 98,40 zł
slowbiz grafiki: 344,40 zł


książki

Mark Manson “The Subtle Art of Not Giving a F*ck”: 59,51 zł
Mark Manson “Everything Is F*cked: A Book About Hope”: 65,37 zł
Seth Godin “The Dip” (2 szt): 60,50 zł
The One Thing: 35,57 zł
Steven Pressfield The War of Art: 51,24 zł
Steven Pressfield Turning Pro: 49,31 zł
Steven Pressfield Do the Work: 30,54 zł
Cal Newport “Deep Work”: 50,35 zł


edukacja

Szkolenie Bartek Popiel „Liczy się oferta” Katowice luty 2020: 1 970,00 zł


wsparcie 1 autora na Patronite: 16,00 zł
książka “Zawód: Programista” (obsługuje firma IMKER)

wysyłka: 1 136,52 zł
magazynowanie: 301,35 zł


samochód:

Toyota GT86 benzyna: 902,30 zł
Toyota GT86 opony zimowe Kormoran Snow: 936,00 zł
Toyota GT86 wymiana i utylizacja opon: 130,00 zł
Parking SkyCash: 101,90 zł
Dodge Challenger: 110 000,00 zł
Dodge Challenger benzyna: 328,52 zł
Dodge Challenger opony zimowe Dunlop SP WINTER SPORT 3D: 2 780,00 zł
Dodge Challenger gaśnica / apteczka itd: 105,97 zł
Dodge Challenger wymiana oleju / filtrów itd: 670,00 zł
nauka rajdowej jazdy (na pożegnanie GT86): 800,00 zł


usługi prawne:

Rzecznik patentowy: 2 214,00 zł
ogólne usługi prawne: 2 091,00 zł


inne:

hotel: 384,93 zł



W sumie: 996 096,63 zł


Podsumowanie i plany

Moja działalność w tym roku ma bardzo ciekawe konsekwencje. W samym tylko listopadzie wypłaciłem kilku Mentorom ponad pół miliona złotych! To jest ogromna skala, ogromna odpowiedzialność i ogromna… satysfakcja. Bo ten trend trwa już od dość długiego czasu i nic nie zapowiada, żeby miał się zmienić. Niezmiernie cieszy mnie to, że świetna praca jest tak sowicie wynagradzana.


No i oczywiście także to, że i moja sytuacja w tym wszystkim także jest bardzo korzystna.


Wypłaciłem ponad pół miliona wynagrodzeń, kupiłem mieszkanie, kupiłem samochód… czyli ogromne wydatki. A i tak bilans wychodzi na plus. To jest bardzo wyjątkowa sytuacja i codziennie staram się ją doceniać.



Na wklejonym wyżej wykresie przychodów widać chyba po raz pierwszy efekt, którego od jakiegoś czasu oczekiwałem… ale który nie następował. No i wreszcie następuje. Do tej pory w danym miesiącu zwykle zarabiał tylko jeden produkt. A teraz: zarobiły prawie wszystkie! Oczywiście główny nacisk był położony na DBMaster, więc tutaj mamy bezapelacyjnego listopadowego lidera, ale pozostałe kwoty wcale nie są bagatelne!


Dostaję coraz więcej pytań “a co będzie w 2020 roku?”. I konsekwentnie odpowiadam: w sumie to za bardzo nie wiem. Opowiadałem we VLOGu niejednokrotnie, że nie zwracam większej uwagi na plany i się ich nie trzymam. Obiecane mamy kilka rzeczy: premierę DBMaster, 2. edycję WTF i 2. edycję DNA. Tyle WIEM. Na horyzoncie majaczą kolejne tematy, związane zarówno z devstyle jak i slowbiz oraz niezwiązane zupełnie z niczym. Ale co z tego wyjdzie? Zobaczymy.



No i rozrywkowo: pozwoliłem też sobie na jeszcze odrobinę ekstrawagancji i przyfrunął do mnie Oculus Quest, czyli pierwszy (chyba) VR niewymagający komputera. Jestem w szoku. W SZOKU, powiadam! Ta technologia mnie po prostu zmiażdżyła. Co prawda nie uzależniłem się od gier – choć wszystkie mi się podobają i trochę się tego obawiałem – ale mam nieco refleksji. Jak technologia będzie się nadal w takim tempie rozwijać, to za kilkadziesiąt lat w ogóle nie będzie potrzeby wychodzenia z domu. Ba, wstawania z łóżka! Z jednej strony to źle, bo życie straci wiele smaczków. Ale z drugiej: dobrze, bo będę mógł bez korków śmigać Dodgem ;).



A teraz:


Podsumowanie aktywności devstyle 11/2019

I przy okazji zapytanie:


Chcesz pisać na devstyle? Chcesz dotrzeć do setek/tysięcy polskich programistów?

Jeśli masz wiedzę “do podzielenia się” i chęci dołączenia do naszej Redakcji  to daj znać!

(uwaga: szukamy tekstów technicznych)


Teksty:



Dlaczego niektórzy sądzą, że Scrum jest g* wart? (Bartłomiej KLIMCZAK)
Jesienna regeneracja i kolejne pomysły, czyli Październik 2019. Podsumowanie i raport finansowy.
Cake – jak wdrażać, aby się nie zrażać (Piotr CZECH)

Podcasty (i inne audio):



DevTalk #105 – O SAP z Pawłem Wiejkutem
DevTalk #106 – O biznesie i technologii z Lechem Kaniukiem

VLOGi:



Młody idiota decyduje o moim życiu? [vlog #318]
Pokonał mnie SYSTEM. I to DWA RAZY! [vlog #319]
NAUCZKI [vlog #320]
DWA Mieszkania NIE na wynajem [vlog #321]
Szczęście POWSZEDNIEJE [vlog #322]
Sprzedam TOYOTA GT86 [vlog #323]
Zaufanie, NAIWNOŚĆ czy już GŁUPOTA? [vlog #324]

Video:



Nagranie z Webinaru: Praktycznie o Indeksach z Damianem Widerą
Siła Listy Mailowej – Wywiad w MWF Mała Wielka Firma
Plany w działaniach marketingowych – Wywiad w MWF Mała Wielka Firma
Ciemna Strona Dużych Pieniędzy – Wywiad w MWF Mała Wielka Firma

Wyjazdy / konferencje:



Wystąpienie dla Towarzystwa biznesowego Białystok
Warsztaty z budowania zespołu w ramach Światowego Tygodnia Przedsiębiorczości

Wywiady:



MWF: Jak sprzedać kurs online za 6 mln zł
Podcast gościnny developer wannabe (Jędrzej Paulus)
Wywiad video u Kacpra Podgórskiego Proces Spełnienia #16

====


Dzięki za uwagę i pozdro!


P.S. Jak zwykle, jeśli masz jakiekolwiek pytania: nie wahaj się, tylko je zadawaj! Na co mogę, na to odpowiem :).


The post Nieoczekiwany zryw blisko mety. Czyli listopad 2019: podsumowanie i raport finansowy. appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on December 19, 2019 05:19

Maciej Aniserowicz's Blog

Maciej Aniserowicz
Maciej Aniserowicz isn't a Goodreads Author (yet), but they do have a blog, so here are some recent posts imported from their feed.
Follow Maciej Aniserowicz's blog with rss.