Poczytaj mi, wielkipiecu — biblioteczka programisty

Faktem, który w 2017 zdumiewa jeszcze mocniej, niż to, że dalej istnieją gazety jest fakt, że w dalszym ciągu drukowana jest literatura informatyczna. W dodatku tłumaczona! Co jeszcze bardziej oddala treść od punktu w czasie, w którym była względnie świeża. Dotychczas moim głównym zarzutem względem drukowanych książek informatycznych, pomijając oczywiście marnowanie papieru, był brak możliwości kopiowania kodu żywcem. Okazuje się jednak, że setki tysięcy ludzi uczą się programowania z pogadanek na YouTube (!!!), z których kopiować nie da się tym bardziej. Oznacza to zatem, że nie poniósł nas pęd do nowoczesności, a zanik umiejętności przyswajania tekstu dłuższego, niż wiadomość na Facebook Messengerze.

Na szczęście wydawnictwo O’Reilly publikuje swoje książki również w (kopiowalnym) formacie PDF, który pozwala m.in. przekleić kod ćwiczeniowy do własnego pliku. Książki od O’Reilly są zaskakująco przydatne i pouczające. Dzięki nim nauczyłem się Perla, w stopniu w którym stał się on moim ulubionym językiem i narzędziem pracy. Chciałbym więc przytoczyć nową ofertę zbliżonego wydawcy, poznaną w trakcie rozpaczliwych prób rozwiązywania niemożliwych trudności deweloperskich.

„Copying and Pasting from Stack Overflow”

Należy koniecznie zacząć od nieocenionej publikacji „Copying and Pasting from Stack Overflow”, która pozwala zgłębić tajniki wiedzy niezbędnej do zastąpienia wszelkiego śladu kompetencji zbiorem wyświechtanych frazesów z portali technologicznych. Dzięki niej, jedyną potrzebną wiedzą stanie się biegłość w formułowaniu kwerend Google i filtrowaniu dobrych odpowiedzi na SO od złych.

To nie jedyne zalety „Copying…”. Coś dla siebie znajdą tu również programiści, którzy wbrew obecnym trendom rynkowym, jednak posiadają jakieś umiejętności, ale wskutek braków kadrowych (lub absolutnej losowości przydziału zadań), są skazani na pracę w języku lub technologii, których nigdy wcześniej nie widzieli na oczy. „Copying” pozwoli im rozwiązać problemy, poprzez bezkrytyczne kopiowanie odpowiednich fragmentów kodu, nie tylko ufając nieznanym autorom, ale i przeszacowując własne zdolności rzeczywistego zrozumienia wklejanych fragmentów. Dlatego, celem dokonania dalszego postępu, wysoce wskazane jest zapoznanie się z pozycją „Changing Stuff and Seeing What Happens”, która opisuje jedyną skuteczną metodę nauki nowego narzędzia: dokonywanie losowych zmian w cudzym kodzie.

„Changing Stuff and Seeing What Happens”

Gotowe rozwiązania, odkryte dzięki „Copying…”, mogą zostać skrojone na miarę opracowywanego problemu, korzystając z bezcennych rad z najnowszego wydania „Changing…”. Ponadto, w rzadkich sytuacjach, jak np. brak stresu lub poprawnie funkcjonująca pamięć krótkotrwała, nauka z użyciem wzorców „Changing Stuff and Seeing What Happens” pozwala naprawdę nabyć pewne kompetencje z zakresu wykorzystywanej technologii. Praktyka dowodzi jednak, oczywiście, że to osobliwe stany i o wiele bliższy codzienności jest tzw. permanentny alarm, a więc gonita terminów w okolicznościach ujemnych zasobów czasowych.

„Trying Stuff Until it Works”

Dlatego w ofercie znajduje się swego rodzaju fast track względem powyższej publikacji, mianowicie „Trying Stuff Until it Works”. Pozornie subtelna różnica między owymi dwoma podejściami staje się natychmiast wyraźnie widoczna, gdy porówna się je pod kątem wykorzystania świadomości. Szkoła przytaczana przez „Changing” sugeruje metodę badawczą, zorientowaną na poszukiwanie mechanizmów działania wykorzystywanej technologii. Zaś „Trying” postuluje wręcz niemal losowe zmiany, mające w założeniu prowadzić do skutku, po kilkuset podejściach. U postaw owej alternatywnej metodyki leży, popierana przez rosnące rzesze programistów, teza, że próba świadomego przemyślenia rozwiązywanego problemu kosztuje dalece więcej czasu, niż wprowadzanie siłowych zmian, moderowanych wyłącznie przez podkreślane przez IDE błędy składni. Nie musi zresztą zawsze chodzić o czas: krańcowe spetryfikowanie lękiem oraz przesycenie pracującego od kilku godzin mózgu kawą prowadzi notorycznie do kompletnego zastoju kreatywnego, przełączając umysł w tryb wyłącznie odtwórczy. W takich warunkach, znanych pod nazwą „agile”, doskonale sprawdzi się alternatywna metodyka, wykładana przez „Trying…”.

„Regex by Trial and Error”

Utrzymana w podobnym duchu, acz niewymagająca paraliżującego lęku, jest książka „Regex by Trial and Error”, czyli doskonałe uzupełnienie do miniprzewodnika po wyrażeniach regularnych. Wiadomo powszechnie, że mimo swojej niewątpliwej kompletności, kilkunastostronicowa książeczka nt. wyrażeń regularnych, nie odzwierciedla swoją objętością nakładu pracy, czasu i frustracji niezbędnych do osiągnięcia biegłości w ich użyciu. Ową lukę zdecydowanie wypełnia ośmiusetdwudziestopięciostronicowa pozycja „Regex…”, dosadnie mierząc się z niezaprzeczalną tezą, że poprawne wyrażenie regularne da się napisać za pierwszym razem wyłącznie przez przypadek. Ponownie zorientowana na podejście badawcze, przebojem łączy ową metodykę z podejściem „agile”, stosującym chaos, rozpacz i bezowocne, losowe próby.

„Memorizing Six Git Commands”

Ogrom wiedzy, oferowany przez powyższe publikacje, z pewnością pozwoli przebojem rozpocząć i kontynuować pracę deweloperską. Aby poprawnie wykorzystać potencjał narzędzi do pracy grupowej, tworzony kod w mig połączymy z systemem kontroli wersji, dzięki bezcennej pozycji „Memorizing Six Git Commands”. Nowatorskie podejście do systemu Git odgórnie rezygnuje z zadania, które skazane jest na porażkę: nie próbuje ani przez chwilę wyjaśnić, jak działa Git, ignoruje mylące pojęcia i zbędne, jak HEAD, przestrzenie nazw, grafy, reflog, czy synchronizacja pozioma „fast-forward”. Skupia się na najważniejszym zbiorze sześciu zwyczajowo identycznych, ale jakimś cudem niemożliwych do zautomatyzowania komend, ze szczególnym uwzględnieniem przygotowywania commitów przed wysłaniem zmian na zdalną gałąź. To proste i genialne. Skoro dokumentacja Gita to i tak żart, a „kontrola wersji” jest kłamliwą fikcją, nie warto podejmować staromodnych prób opartych o zrozumienie wykorzystywanych narzędzi. Przecież jeżeli cokolwiek pójdzie źle, jedynym rozwiązaniem i tak jest zawsze ściągnięcie tego samego repozytorium obok i przeklejenie popsutych plików. Git w sześciu komendach to lektura obowiązkowa!

„Writing Code that Nobody Else Can Read”

Kontrola wersji oczywiście naraża nas na, niebezpieczny i przestarzały, koncept recenzji kodu. Tutaj z pomocą przychodzi nam „Writing Code that Nobody Else Can Read”. Będąc ambitną wycieczką po meandrach wyobraźni, wspomaga proces kształtowania praktyk programistycznych tak, by tworzony kod jak najlepiej odzwierciedlał nasz sposób myślenia, przy okazji trzymając się jak najdalej od czyjegokolwiek innego. W myśl zasady, że podczas recenzji, kod dziesięcioliniowy skutkuje dziesięcioma komentarzami, a pięciusetliniowy – jednym (brzmiącym „wygląda dobrze”), „Writing” szczegółowo omawia również metody tworzenia kodu logicznie niezbędnego, ale objętościowo przekraczającego czyjąkolwiek wolę wkładaną w poprawne przeprowadzenie recenzji. Dodatek „B” ułatwi nam również wybór najbardziej nieprzystającego do zadania języka.

„Forgetting How Your Own Code Works”

Celem ciągłego doskonalenia i samorozwoju, umysł musi dysponować wolnymi przestrzeniami na przyswajanie nowej wiedzy i praktyk. Właśnie w tym celu napisano przewodnik „Forgetting How Your Own Code Works”, dzięki któremu uda się, nierzadko jeszcze podczas trwania samego projektu, usunąć wiedzę z zakresu tworzonego rozwiązania. Nadmierne przywiązanie do detali jest szkodliwe – powinniśmy zawsze dbać o szeroką perspektywę. Wolne umysły są wolne nie tylko od zbędnych zmartwień ale i od zbędnej wiedzy.

„Pointless Meetings”

Wreszcie, algorytm stworzony z użyciem „Trying Stuff Until it Works”, wprowadzony do projektu za pomocą „Memorizing Six Git Commands”, zapisany z wykorzystaniem praktyk z „Writing Code that Nobody Else Can Read”, a następnie zapomniany dzięki „Forgetting How Your Own Code Works”, będzie wkrótce wymagał wytłumaczenia nowym/przyszłym członkom projektu w ramach tranferu wiedzy. Tego typu inicjatywy będąc nam niestraszne dzięki najnowszemu wydaniu „Pointless Meetings”. Opisuje ono nie tylko spotkania z góry skazane na porażkę, jak i te systemowo zbędne z definicji. Te drugie z powodzeniem mogłyby zostać zastąpione mailem, ale codzienny strumień obowiązkowych, pozbawionych treści newsletterów dawno już sprawił, że maili nikt już nie czyta z wykorzystaniem świadomości. Nowe wydanie „Pointless Meetings” zawiera również dodatek poświęcony symulowaniu zaangażowania w trwające spotkanie, bogaty w inspirujące cytaty, jak „czy możemy na chwilę wrócić do poprzedniego slajdu?”.

Podsumowanie

Wszystkim polecam lekturę powyższych publikacji, ze swej strony dokonam również autopromocji i wspomnę, że do końca marca, zakup dowolnej z owych książek uprawnia do rabatu na moje ostatnie dzieło – „Writing overrated blog posts”! Cheers!

PS: okładki, poza ostatnią, nie moje :)

za inspiracją od https://dev.to/