Moje webdevowe lektury

UWAGA! Ten wpis ma już 8 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

Pracując na co dzień z systemami stworzonymi ładnych parę lat temu, a jednocześnie zbyt złożonymi, aby je co jakiś czas przepisywać w całości, nietrudno wypaść z obiegu. Wprawdzie nasz biznes nie narzeka na brak pomysłów, dzięki czemu co jakiś czas musimy korzystać z czegoś zupełnie nowego (jak opisywane przeze mnie jakiś czas temu websockety), jednak i tak następuje to zbyt rzadko, by nie zardzewieć bez douczania się na własną rękę.

Co czytam?

Książki

Tych nie było wiele, ale gdy już były, to okazywały się strzałem w dziesiątkę. Książki, które opiszę, były kamieniami milowymi w moim rozwoju, a miałem to szczęście, że sięgnąłem po nie w momentach, w których mogłem się mocno zaangażować w ich lekturę.

Pierwsza z nich to: Wzorce projektowe. Rusz głową! (Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra). Długo myślałem nad zakupem tej książki. Z jednej strony wiedziałem na pewno, że potrzebuję gruntownej wiedzy o wzorcach projektowych. Był to okres, gdy zorientowałem się, że wiele osób w moim otoczeniu sprawnie nimi operuje w rozwiązywaniu realnych problemów i jednocześnie gdy frustrowałem się tym, że moja wiedza w tym temacie jest na tyle ogólnikowa, że nie rozumiem artykułów o wybranych wzorcach na wikipedii. Z drugiej strony, część osób przestrzegało przed tą książką jako przeładowaną obrazkami. Nie pomagał fakt, że była ona wtedy dość droga. Ostatecznie sprezentowałem ją sobie w grudniu 2012 roku i przeczytałem do końca parę miesięcy później. Obrazków faktycznie jest dużo i jest to książka idiotoodporna. Zawdzięczam jej nie tyle dokładne poznanie popularnych wzorców projektowych, ile zmianę sposobu myślenia. Książka przebudowała zupełnie moją ówczesną wiedze o OOP, wskazując wymierne korzyści w codziennych rozwiązaniach. Po jej przeczytaniu widziałem tyle zastosowań wzorców i ogólnie elastycznego OOP, że – jako neofita – chciałem zacząć wszystko na nie przerabiać. Początkowa fascynacja minęła, jednak nowy sposób myślenia został do dziś i jestem w stanie bez problemu wymienić mnóstwo rozwiązań z projektów, nad którymi pracuję, w których architekturze wykorzystałem wzorce i które – mimo niedoskonałości, które widzę po wielu latach – do dziś nie tylko dobrze się trzymają, ale są też dość odporne i łatwe do zmodyfikowania.

Drugą (i ostatnią) książką jest: Antywzorce języka SQL. Jak unikać pułapek podczas programowania baz danych (Bill Karwin). Na książkę tę trafiłem, gdy miałem już względnie duże doświadczenie z bazami danych i pewnie bym ją pominął, gdyby nie autor, którego kojarzyłem… ze stackoverflow. Jego odpowiedzi na tyle zapadły mi w pamięć jako rzeczowe i wyważone, że postanowiłem dać książce szanse. I nie pożałowałem – książka jest dość zwarta i zawiera opisane na przykładach antywzorce wraz z dokładnym wyjaśnieniem, dlaczego nie należy ich stosować i w czym utrudniają później pracę. Po przeczytaniu książki zauważyłem, że sam stosuję wiele z nich, więc dzięki niej mogłem świadomie przestać z nich korzystać na rzecz lepszych rozwiązań, sugerowanych przez człowieka z ogromnym doświadczeniem w tej (i nie tylko zresztą) dziedzinie.

Internet

Nikogo nie powinno zdziwić, że w przypadku webdevu większość materiałów, z których korzystam, znajduje się w internecie na wszelkiego rodzaju stronach czy blogach.

Jako pierwszy wymienię Stack Overflow. Ciężko znaleźć obecnie osobę, która go nie zna. Stack Overflow jest dla mnie najczęściej pierwszym krokiem do rozpoznania problemu. Odpowiedzi pozwalają na szybkie rozeznanie (w razie bardziej złożonych tematów) lub natychmiastowe rozwiązanie (w przypadku tych prostszych) problemu. Obecnie korzystam głównie biernie i raczej nie wspominam dobrze okresu, w którym starałem się odpowiadać na pytania użytkowników. Presja czasu w moim przypadku zabija całą zabawę w odpowiadaniu (trzeba napisać odpowiedź merytorycznie i bardzo szybko, inaczej po opublikowaniu okazuje się, że kilka osób zrobiło już to samo). Tym niemniej, SO stanowi ciągle ogromną bazę wiedzy na dość wysokim poziomie.

Drugim źródłem wiedzy są dla mnie wykopowe tagi #webdev oraz #php. Przeglądam je często w wolnym czasie. Dzięki nim dowiedziałem się o wielu stosowanych obecnie technologiach, których prawdopodobnie szybko zawodowo nie zastosuję, jednak wiedza o ich istnieniu przydaje się czasem w doborze narzędzi do rozwiązania danego problemu. Toczą się tam też dyskusje pozamerytoryczne związane z pracą zawodową w webdevie i pozwala to poznać opinie wielu doświadczonych ludzi. Tagi te przeglądam od 2014 i polecam każdemu śledzenie ich lub przeglądanie przez przynajmniej parę minut dziennie.

They write the right stuff

UWAGA! Ten wpis ma już 8 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

Niedawno znalazłem w sieci tytułowy artykuł: They Write the Right Stuff. W dużym skrócie opowiada o rozwoju szeroko rozumianego oprogramowania wykorzystywanego w misjach promów kosmicznych.

Przydługi wstęp opisujący automatyczny proces wznoszenia statku kosmicznego, następnie mające wywoływać wrażenie statystyki dotyczące odpowiedzialnego za to oprogramowania oraz krótki opis tła.

Właściwy początek artykułu również nieco nudny – przedstawienie kilku osób zaangażowanych w kod, którzy zapewniają o perfekcjonizmie kodu, za który są odpowiedzialni. Dla kontrastu następuje porównanie z wszechobecnym oprogramowaniem, z którym stykamy się w niemal każdej dziedzinie życia oraz stwierdzenie, że wszystko to jest tworzone szybko i niechlujnie. Nic nowego, do tego momentu prawie zrezygnowałem z dalszego czytania. Ale to właśnie odtąd zaczyna się sedno artykułu – proces tworzenia oprogramowania dla NASA.

Sprawa jest opisana bardzo dokładnie: od szczebla finansowego, po zarządzanie, projektowanie, zapewnianie jakości oraz samo programowanie.

Najwyższa warstwa to opis żywcem wyjęty z dowolnego, dużego korpo – przeładowane informacjami prezentacje dla przedstawicieli sponsorów projektu, narzekanie na ilość czasu, składanie pisemnych zapewnień. Z tego wszystkiego wyróżniają się zdecydowanie spotkania menedżerów odpowiedzialnych za oprogramowanie z uczestnikami misji, którą ono obsługuje – tak, aby poznać osobiście ludzi, którzy mogą zginąć, jeżeli soft będzie posiadał błędy. O tym, jak dużą presję musi to wywoływać najlepiej mówi fakt, że wszyscy menedżerowie wymienieni w artykule zmienili branże.

Projektowanie opisuje klasyczny model waterfall. Wszystko musi być przedyskutowane, ustalone i opisane w najdrobniejszych szczegółach. Osoby wypowiadają się z dumą o tym, że każda najmniejsza zmiana wymaga ponownego uruchomienia machiny projektowej. Trochę mnie to zdziwiło, podobnie jak chwalenie się używaniem bugtrackera.

Zapewnienie jakości odbywa się w dziale weryfikacji, odseparowanym w strukturze firmy od działu programistycznego. Wspomniana jest też praktyka weryfikacji już w trakcie pisania kodu, przez dodatkową osobę. Każdy znaleziony błąd jest zapisywany w bugtrackerze wraz z wszystkimi podstawowymi informacjami.

Dział programistyczny składa się z normalnych, „nudnych” ludzi: dorosłych programistów z rodzinami, dziećmi, posiadających zrównoważony stosunek pracy do życia prywatnego. Nie ma nadgodzin i niespodziewanego pośpiechu, zaś indywidualiści są stąd natychmiast eliminowani.

Z każdego znalezionego błędu wyciągane są wnioski, czasem aż do przesady. Wnioski nie oznaczają w tym przypadku osobistych konsekwencji – w przeciwieństwie do typowych korporacji, tutaj nie szuka się dupochronów i winnych. Winny jest zawsze proces i to proces, który dopuścił do powstania błędu musi zostać zmieniony tak, aby sam z siebie mógł tego typu sytuacje wykluczać. Brzmi strasznie skrupulatnie, ale jest to zrozumiałe – błędy w przypadku misji kosmicznych mogą kosztować ludzkie życie i miliardy dolarów, więc obarczanie winą pojedynczych osób przy takiej skali nie ma sensu.

Opisany proces wygląda naprawdę dobrze, chociaż oprogramowanie dla NASA to jednak skrajny przypadek rynku software’owego. Pieniądze nie są tu problemem, deadline’y nie są narzucane, lecz ustalane praktycznie przez samych developerów, oraz tylko jeden projekt naraz. Problemy te same, lecz warunki w porównaniu z resztą rynku (krytykowanego na początku) nieco utopijne.

Co jest najciekawsze w artykule? To, o czym dowiedziałem się mniej więcej w połowie jego czytania, gdy z ciekawości spojrzałem na datę opracowania. Miało to miejsce w 1996, 20 lat temu. Na kilka lat przed rozpoczęciem się mojej własnej przygody z komputerami i na kilkanaście przed tym, gdy zacząłem zawodowo zajmować się programowaniem i zderzać z identycznymi problemami. Niewiele się zmieniło, prawda?