bookmark_borderStare spaghetti, czysta wódka i wujek Zdzisiek

Ktoś mnie ostatnio nazwał clean code evangelist. Pomyślałem – tytuł zobowiązuje. Trzeba napisać o czystym kodzie.

Co jednak napisać? Wszystko już było. Nic nowego pod słońcem. Krótkie metody, znaczące nazwy i ogólnie takie, takie. Co mógłbym ja, prosty programista, napisać o czystym kodzie pod koniec drugiej dekady XXI wieku? Dekady jaśniejącej tysiącem frameworków JavaScriptowych, dziesięciolecia mikroserwisów, chmury i dev-ops!

Metafory. Metafory zawsze służyły ludzkości. Horacy, Nostradamus, Popek. Wszyscy oni używali mglistego języka przenośni, by oddać esencję. Spróbujmy.

Spaghetti jest dobre, spaghetti smaczne jest, świeże spaghetti jest jak listek bazylii na pizzy, jak zapach wydechu Fiata w wąskiej uliczce Turynu, jak szynka parmezańska obsypana rukolą. Wszyscy lubimy gotować spaghetti. 8 minut i gotowe. Cottura 8 minuti i włala.

Kod spaghetti jest taki sam. Świeżo przygotowany pachnie soczystymi kaskadami ledwie widocznych zależności. Ma smak długich jak przedrelease’owe wieczory metod z posmakiem enigmatycznych nazw zmiennych, nazw dojrzewających w pełnym słońcu wschodzącego deadline’u.

Niestety, spaghetti nieskonsumowane przekształca się w to samo mniej więcej, co skonsumowane.

Spaghetti dojrzałe powoduje zaparcia, bóle głowy, a nawet rozwolnienia. Kod spaghetti tak samo – przydatny jest do spożycia w krótkim jedynie terminie.

Zastanawiając się, jaki pseudonim musiałbym sobie wybrać by zostać polskim Uncle Bob’em doszedłem do wniosku, że mógłbym być wujkiem Zdziśkiem. Na potrzeby tego i kolejnych akapitów – zostanę nim.

Posłuchajcie wujka. Wujek życie zna. Wujek pracował nad jednym projektem do emerytury w zakładzie pracy państwowym, nad projektem rządowym i wujek wie co to znaczy nieświeże spaghetti.

Rada wujka: kod ma być jak wódka.

Tak. Jak wódka ma być!

Wódka, jaka jest, każdy widzi. Jak koledzy z zespołu kod wódkę zobaczą, to przysiądą się, zaczną delektować się kodem wódką, zadowoleni będą, radośni. Kod wódka doskonale się integruje. Kod wódka nie ma zależności – można z ogórkiem, można z colą, wszystko co interfejs zakąska implementuje być może. Kod wódka powoduje najmniejszego kaca, o ile potrafimy go okiełznać.

Reasumując: kod ma być, jak wódka, czysty.

Tako rzecze wuj Zdzich.

bookmark_borderProgramowanie jest łatwe

Wiele osób, które nie miały wcześniej styczności z programowaniem myślą, że jest ono trudne. Częściowo wynika to z przekonania, że ma ono duży związek z matematyką, trochę z nieczytelnego wyglądu niektórych języków programowania, a odrobinę też z tego, że niektórzy ludzie z branży lubią pozować na magików, którzy zaklinają cyfrowe węże.

Prawdę powiedziawszy podstawy programowania są łatwe.

Element pierwszy: zmienne

Koncepcja zmiennej jest prosta, jak konstrukcja cepa. Mamy coś co ma nazwę i wartość oraz typ. Na przykład:

nazwa: ilość pieniędzy na koncie
wartość: 7000
typ: liczba

nazwa: imię mojego dziecka
wartość: Maciek
typ: litery

Element drugi: warunki

Warunki są koncepcją równie prostą, jak zmienne. W zależności od czegoś robimy coś albo coś innego. Banał.

Przykład:

Jeśli 
       data urodzin mojego dziecka jest równa dacie dzisiaj

To
       będę robić tort

Element trzeci: pętle

Pętle wykonują coś wiele razy. Proste? Proste.

Przykład:

Dopóki flaszka jest pełna
       nalej do kieliszka a potem wypij

Język

Oczywiście na końcu trzeba to wszystko zapisać w jakimś języku programowania. Kiedy ludzie myślą o nauce języka zwykle są przerażeni. Przychodzi im na myśl od razu ta wredna germanistka z podstawówki, rodzajniki, odmiana i czasy. I tysiące, nieskończone tysiące słówek do nauczenia.

Języki programowania są łatwe. Gramatyki prawie nie ma, a słów jest kilka.

Naprawdę.

Definicje zmiennych?

liczba: number;
napis: string;

Warunki?

ilośćCiastek = 5;
 if ( ilośćCiastek > 0 ) {
        jedzCiastka();
 }

Pętle?

while ( flaszka.czyJestPelna() ) {
        człowiek.pij()
 }

Oczywiście to są podstawy. Oczywiście jest dużo gorzej. Jednak nikt mi nie wmówi, że te podstawy są jakieś strasznie skomplikowane, że programowanie to matematyka i gramatyka niemiecka albo jeszcze gorzej.

Programowanie jest łatwe. I fajne!

bookmark_borderProject managerowie go nienawidzą! Programista z korpo odkrył jeden prosty trik jak wysadzić projekt w powietrze przy użyciu Jiry.

Za górami, za lasami, za siedmioma routerami, był sobie projekt. Był dobry. Deadline był odległy, a budżet zatwierdzony. Zespół liczny, doświadczony. Pomysł na produkt miał ręce i nogi.

Co mogło pójść nie tak?

Zabraliśmy się do pracy. Spotkania, telekonferencje, ustalenia. Planowanie za planowaniem, meeting za meetingiem, sprint za sprintem. Szybko okazało się, że głównodowodzący projektem ma osobowość radiowego spikera. Człowiek ten uwielbiał rozmawiać, mówić, przemawiać i omawiać. Nie ma w tym nic złego. Dobrze jest być towarzyskim. Projekt był rozproszony geograficznie, więc siedziało się na słuchawce godzinami, ale jeśli trzeba coś omówić, to przecież naturalne.

Po rozmowie wypadałoby zacząć pracę, a ustalenia spisać. Nasz lider jednak lubił jedynie mówić. Zadania, jakie dla nas tworzył składały się zwykle z jednozdaniowego opisu staniowącego tytuł.

Projekt trwał i trwał, postępy nie były imponujące. Nadszedł sezon urlopowy. Nasz lider również postanowił udać się na zasłużony wypoczynek. Dwutygodniowy. Przed opuszczeniem biura zorganizował – a jakże! – spotkanie, na którym omówił zadania, jakie przed nami stały. Wydawało nam się, że zrozumieliśmy jego intencję. Dla uspokojenia przekazał nam kontakt do dwóch osób, które miałyby rozwiać nasze wątpliwości w razie, gdyby takowe zaistniały.

Przyszedł kolejny tydzień. Zajrzeliśmy do notatek, zajrzeliśmy do zadania (z jednozdaniowym opisem). Po kilkunastu minutach pojawiły się wątpliwości. Po godzinie rozmawialiśmy z pierwszą osobą, jaka miała nas wspomóc. Okazało się, że zrozumiała naszego lidera inaczej, niż my. Zaniepokoiło nas to. Zadzwoniliśmy do kolejnej. I ona zrozumiała inaczej. Tyle tylko, że nie inaczej niż my, ale również inaczej niż pierwsza osoba. Mieliśmy trzy interpretacje i dwa tygodnie bez autora.

Puenta okazała się zaskakująca. Gdy lider wrócił z urlopu i zaczęliśmy drążyć, jak konkretnie mamy wykonać zadanie i na czym ma ono polegać, po kikudziesięciu minutach kluczenia przyznał, że nie wie.

To najjaskrawszy, z jakim miałem do czynienia, przykład jednego z grzechów programistów – pobieżnego opisywania tasków. Oczywiście nie można być pedantem i opisywać ich przesadnie szczegółowo, ale pewien sensowny poziom detalu i dbałości jest wymagany, by projekt nie eksplodował spotkaniami.

Zastanówmy się. Bierzemy do ręki, na warsztat nowe zadanie. Czytamy opis i połowy z niego nie rozumiemy. Co robimy? Idziemy do autora. Jeśli autor jest z biznesu, to pewnie jest na spotkaniu i nie idziemy, a wysyłamy mail. Czekamy albo bierzemy inne zadanie. Jeśli inne są równie dobrze opisane, to piszemy kilkanaście maili zanim uda nam się zabrać do roboty. Jeśli natomiast autor jest programistą z zespołu to idziemy do niego i… odrywamy go od pracy w skupieniu, przychodząc z naszym  pytaniem.

W obu scenariuszach tracimy czas. Wszyscy. Czas i efektywność.

Opis zadań powinien być precyzyjny, napisany prostym językiem i wystarczająco dokładny, żeby zrozumiała go osoba, która nie posiada naszej wiedzy, a wiedzę wspólną dla członków zespołu. Nie możemy wychodzić z założenia, że jak nie wie to dopyta. To nieefektywne, szkodliwe, złe. To tworzy kulturę rozproszeń, chodzenia od biurka do biurka w nieustającym rytuale dopytywania, ustalania, marudzenia jeden drugiemu. Programista powinien móc jak najdłużej pracować w skupieniu. Tylko tak tworzy się sprawnie dobrej jakości oprograowanie.

Opisuj taski. Opisuj je dobrze. Jeśli nie umiesz ich dobrze opisać, to może nie wiesz w ogóle co jest do zrobienia?

bookmark_borderJęzyk angielski, czyli najważniejszy język programowania

Na przestrzeni dziejów, językom przytrafiają się rozmaite role do odegrania. Łacina, przez wpływ Kościoła, stała się międzynarodowym językiem średniowiecza. Chiński, będąc pierwszym przed wieloma innymi w Azji, który zyskuje formę pisemną, wpływa na Japonię, która do dziś w dużej mierze korzysta z chińskich znaków. Niemcy, rozwijając kulturę miejską szybciej od nas, pierwsi wymyślają pewne słowa, które trafiają później do polszczyzny – na przykład ratusz (w staroniemieckim Rathus).

Dominacja technologiczna krajów anglosaskich sprawiła, że zarówno w komunikacji morskiej, jak i lotniczej językiem oficjalnym stał się angielski. To samo wydarzyło się z technologią informacyjną. Wszystkie omal języki programowania składają się z słów kluczowych wyrażonych w języku Shakespeare’a. Komendy, które wpisujemy w konsoli to również słowa angielskie. Chcemy tego, czy nie – językiem branży IT jest język angielski.

Nie ma w tym nic odkrywczego. Co drugie ogłoszenie o pracę dla programisty zawiera na liście wymagań znajomość angielskiego. Jest to wymaganie wyrastające z potrzeby współpracy z zagranicznymi klientami albo członkami rozproszonych zespołów wielonarodowych. W wielu krajowych firmach nie wymaga się angielskiego. I choć z pozoru ma to sens, to konsekwencje mogą być poważne.

Każdy chyba, kto studiował, pisał podobne do poniższych koszmarki:

class Zwierze {
  oddychaj() {
    console.log('Sap sap')
  }
}

class Kot extends Zwierze {
  miaucz() {
    console.log('Miau miau');
  }
}

class Pies extends Zwierze {
  szczekaj() {
    console.log('Hau hau');
  }
}

let pies = new Pies();
let kot = new Kot();
pies.szczekaj();
pies.oddychaj();;
kot.oddychaj();
kot.miaucz();

Mieszanie języków jest powszechnie uznawane za nieeleganckie i nie spotkałem się jeszcze z takim kodem w żadnej firmie, w której pracowałem, czy to polskiej, czy zagranicznej.

W pewnym minimalnym stopniu każdy programista angielski zna. Bez niego ciężko utrzymać się w branży, w której cała niemalże dokumentacja techniczna jest w nim wyrażona. Subtelny problem, który niełatwo na pierwszy rzut oka zauważyć polega na głębokości znajomości języka.

Nie da się pisać czystego kodu nie znając dobrze angielskiego.

Jak wiemy kod powinien być czytelny. Nazwy zmiennych adekwatne, metody krótkie, zwięzłe, klasy odpowiedzialne za to, co ich nazwy sugerują. Niestety, jeśli programista nie czuje się z językiem angielskim naprawdę komfortowo, to dość szybko dopadnie go problem z nazwaniem nawet nieprzesadnie skomplikowanych rzeczy w kodzie.

Wszyscy znamy urocze pomyłki w gastronomii:

Żeby być jednak uczciwym, nie jesteśmy w IT wolni od grzechu. Podczas telekonferencji ze współpracownikami z zagranicy mój kolega powiedział swego czasu it’s in the first akapit – zapominając, że przecież akapit w języku angielskim nie istnieje, bo jest to paragraph. Choć równie urocze pomyłki zdarzają się ze strony klientów. Pewna Włoszka kazała mi, kilka lat temu, pewną rzecz semplificare zamiast simplify

Continue reading „Język angielski, czyli najważniejszy język programowania”

bookmark_borderOsobowość programisty

Nie po to zostałem programistą, żeby rozmawiać z ludźmi – mawiają niektórzy. Programiści lubią czasem pozować na niezrozumiałych, heraklitejskich mędrców, stojących ponad masami nieświadomych użytkowników. Będąc wśród swoich, przynajmniej niektórzy z nas, pieszczą swoje ego spoglądając na niedoświadczonych kolegów z góry. Internet pełen jest zresztą memów ukazujących starszych programistów w blasku i chwale, juniorów zaś, razem z praktykantami jako niedoświadczonych  półgłówkow.

Kiedy pokazujemy juniorowi starą technologię

Źródło: https://thecodinglove.com/when-we-show-an-old-technology-to-a-junior-developer

Między nami, deweloperami toczy się walka, walka o dominację. Ile to razy widziałem już skracanie kodu przy użyciu mało znanych elementów języka, by pokazać, że jest się większym ekspertem. Zmniejszanie wycen, by udowodnić innym, że jesteśmy bardziej wydajni. Chodzenie na rekrutacje dla sportu. Delegowanie juniorom zadań nie prostych, a żmudnych.

W jednej firmie, w której pracowałem na stanowisku młodszego programisty pracował ze mną kolega. Nazwijmy go Przemek. Kolega Przemek również był młodszym programistą. Pewnego dnia jednak, z racji dłuższego o bodajże rok stażu pracy, awansowano go. Dwa tygodnie po tym wydarzeniu, pracując nad kodem produktu zapytałem na open-space o, nieznany mi wówczas, typ decimal w C#. Przemek oderwał się od komputera i roześmiał.

Nie wiesz co to decimal? Ty juniorze!

Usłyszawszy to, znad swojego z kolei ekranu, podniósł się starszy programista i roześmiał gromko.

– Przemek, przecież sam mnie o to pytałeś miesiąc temu!

Tymczasem to współpraca i synergia, a nie ego i znajomość kruczków technologicznych budują zgrane, sprawne, produktywne zespoły, które tworzą piękne, zgrabne, wydajne rozwiązania cieszące klientów. Po latach zrozumiałem jedno…

Najważniejszą cechą dobrego programisty jest empatia.       

Empatia to umiejętność wczucia się w inną osobę. Jeśli deweloper potrafi zobaczyć świat oczami innych, będzie w stanie zaprojektować system łatwy i wygodny w użyciu dla zwykłych ludzi. Jeśli potrafi wyjść poza swoją perspektywę, będzie umiał pisać kod źródłowy, który będzie zrozumiały dla innych programistów, przez co modyfikowanie produktu będzie tańsze i sprawniejsze. Mając tę cenną umiejętność będzie też umiał rozmawiać z projektantami aplikacji, z tzw. biznesem.

Jako programiści zawsze powinniśmy próbować doskonalić naszą empatię. Możliwie często pytać samych siebie – czy będzie to zrozumiałe dla innych, którzy nie wiedzą tego co ja? Czy nie będzie to zbyt skomplikowane w użyciu? Czy używam dostatecznie prostego języka? Czy nie komplikuję czegoś nadmiernie?

Rekrutując programistów warto zwrócić uwagę na ich osobowość. Osoby zarozumiałe, tyraniczne, mało empatyczne, nawet jeśli genialne na płaszczyźnie technicznej, mogą więcej problemów stworzyć niż rozwiązać… Nie skupiajmy się jedynie na IQ i znajomości technologii. W większości projektów wyzwania techniczne nie są tak monumentalne, jak mogłyby się wydawać.

Same technologie zresztą – przeminą. To co pozostanie, to kod źródłowy. Napisany przez ludzi, którzy wyobrażali sobie, że ktoś, kiedyś po nich przyjdzie i będzie musiał go zrozumieć, nie znając tak jak oni technologii i uwarunkowań albo przez tych, których ich następcy nie interesowali. Po tych drugich nikt nie będzie chciał pracować, a praca będzie powolna. Nie chcemy tego…

bookmark_borderModyfikowany agile

Nie zliczę, ile to już razy, przez wszystkie przypadki słyszałem odmienianie w ostatnich latach słowo Agile. Jesteśmy Agile, działamy zwinnie, wdrażamy Agile.

Przypomina to kuchenne dywagacje o siłowni. Tak, chodzę na siłkę, tak robię masę, jasne crossfit, cardio, aero, suple.

Tylko muskulatury nie widać. 

I tak samo efektów tej zwinności nie widać. Jak był chaos tak chaos jest, jak estymacje nie szły tak nie idą. A przede wszystkim jak był sztywny scope tak jest i jak deadline’y straszyły tak straszą. Dług techniczny jest zaciągany. Wdrożenia są bolesne. No, ale jesteśmy Agile.

Tylko, czy jesteśmy?

Chyba najgorsze co w Agile nie wyszło, to twierdzenie, że możemy go modyfikować. Tak oto, wracając do analogii siłowni, robimy masę, ale… Nie dbamy o dietę, bo lubimy jeść. Nie robimy ćwiczeń na nogi, bo w piątek idziemy na imprezę. Nie chodzimy na siłkę jak nas głowa boli, bo jeszcze nam żyłka pęknie.

I tak chodzimy przez dwa lata, a zamiast kaloryfera dalej bojler.

Czy można być zwinnym przy sztywnym scope? Czy można wdrażać co sprint jeśli nie ma do tego struktury organizacyjnej? Czy bez pokazywania klientowi co sprint przyrostu można budować lepsze oprogramowanie? Czy w ogóle można być zwinnym jak nie ma jeszcze klienta?

Może tak, może nie.

Na pewno jednak jeśli posuwamy z zasad Agile połowę, nie będzie benefitów, a problemy. Warto by być odpowiedzialnym developerem i nie ulegać zbyt łatwo pokusie zjedzenia ciastka będąc na diecie. Jak wiemy nie można go zjeść i nadal mieć.

bookmark_borderFundamentalny problem rozwoju oprogramowania

Gdyby zapytać, czym zajmuje jest programista? – większość osób odpowiedziałaby – pisaniem kodu programów. Niektórzy, bardziej zorientowani w temacie lub związani z branżą odpowiedzieliby – analizą wymagań, projektowaniem aplikacji, programowaniem, do pewnego stopnia też testowaniem i wdrażaniem. To widać. To perspektywa operacyjna.

To czego jednak nie widać, przynajmniej na pierwszy rzut oka, jest istotniejsze i skutkuje ogromem problemów związanych z rozwojem oprogramowania. 

Świat jest złożony. Nieskończenie omal złożony. Przedmioty złożone są z elementów, elementy z materiałów, materiały ze związków chemicznych, te z cząstek, dalej mamy atomy, cząstki elementarne i tak dalej. Z drugiej strony przedmioty skupiają się w miejsca, miejsca w miasta, dalej mamy regiony, państwa, kontynenty, planety, układy gwiezdne, ich skupiska, galaktyki, gromady galaktyk etc. 

Ludzie operują na uproszczeniach. Widząc świat – szacujemy. Opisując grupę ludzi mówimy: para, kilka osób, kilkoro, tłum. Nie liczymy ilości i nie mówimy 27 osób. Widząc kolory mówimy jasnozielony, ciepły lub zimny, ponury, pozytywny. Nie podajemy matematycznego opisu ilości  czerwieni, zieleni i koloru niebieskiego.

Komputery operują na wartościach. Nie możemy zdefiniować w nich samochodu albo benzyny. Musimy stworzyć abstrakcje tych przedmiotów, wybrać pewne wartości, które je opiszą w sposób uproszczony (objętość, liczba oktanowa), wyselekcjonować relacje między nimi (typ paliwa dla samochodu).

Ludzie I komputery są fundamentalnie odmienni. Oprogramowanie jest pomostem między dwoma światami. Programowanie jest budowaniem warstwy pośredniczącej między katastrofalnie nieprzystającymi do siebie rzeczywistościami.

Konsekwencje takiego stanu rzeczy są ogromne. Z uwagi na te różnice tworzenie oprogramowania jest trudne, długotrwałe i złożone. Z powodu tej odmienności programiści nie mogą się porozumieć z klientami. Z tej samej przyczyny nie powstały do tej pory znane z filmów sci-fi roboty, dlatego nie przeprowadzimy ciekawej rozmowy z Siri, a autonomiczne auta napotykają na problemy.

Co szczególnie zwraca moją uwagę po latach pracy nad tworzeniem oprogramowania to naturalna tendencja ludzka do oszczędzania energii (patrz: Prawo trywialności). Bardzo niewielka część populacji jest skłonna włożyć wysiłek w dogłębne przemyślenie tematu, nad którym pracuje. Większość osób spłyci wszystko najbardziej jak się da. Widać to w problemach programistów z testowaniem wyników własnej pracy. Mało który jest w stanie używać swojego oprogramowania inaczej niż w sposób w jaki je tworzył. Jest to najprostszy scenariusz, bo scenariusz znany. Tworzenie nowego wymaga wysiłku. Ta optymalizacja umysłowa widoczna jest również w pracy projektantów że strony biznesu. Zawsze omal, po jakimś czasie okazuje się, że wielu scenariuszy nie przewidziano, a ograniczono się do najprostszych. W zasadzie na chwilę obecną nawet zakłada się, że wszystkich możliwości nigdy się nie przewidzi (fundamentalnie odmienną zasadę przyjęto w zespole pracującym nad specyficznym projektem w postaci programu promu kosmicznego, a sam proces prac skutkujących – mimo dwóch katastrof – niewielką ilością błędów ciekawie opisano tutaj).

Dla rozwoju oprogramowania potrzebna jest niestety precyzja. Na każdym etapie od projektu przez implementację po testy potrzebny jest wysoki rygor umysłowy. I to jest główny wniosek, jaki płynie z fundamentów, z natury samej oprogramowania. Nie możemy sobie pozwolić na lenistwo. Musimy zawsze, w każdym momencie pracy być tak precyzyjni jak tylko możliwe. W przeciwnym wypadku dopadną nas konsekwencje – błędy, niedopatrzenia, luki. Tak, jak kompilator jest bezlitosny i w starciu z nim może mylić się tylko programista, nigdy zaś komputer, tak samo szeroko pojęty rozwój oprogramowania jest bezlitosny. Co zignorujemy – wróci do nas rykoszetem, raniąc.