Jak mówi przysłowie – jeden obraz wart jest więcej niż tysiąc słów. Czym jest dług techniczny? Tym właśnie co na obrazku powyżej. Jest tymczasowym rozwiązaniem, które w miarę upływu czasu stało się problemem.
Czasami dług techniczny jest małym, czasami dużym zaniedbaniem. Im dłużej jednak zwlekamy z doprowadzeniem spraw do porządku, tym większe ryzyko, że nastąpi eksplozja, w wyniku której nasz projekt albo nasza firma pokryje się warstwą cuchnących ekskrementów. Bowiem dług technologiczny (czy też dług techniczny) jest w istocie jak dług – im dłużej odroczymy płatność, tym więcej odsetek przyjdzie nam zapłacić.
Można by zapytać – kto byłby tak bezmyślny, nieroztropny, niedbały i beztroski, by pozostawiać jakieś tymczasowe rozwiązanie na dłuższy czas! I słuszne byłoby to pytanie. I uzasadnione byłoby to oburzenie. Tyle tylko, że jak mówi programistyczna mądrość – tymczasowe rozwiązania są najbardziej trwałe. Czemu?
Bywa, że nie ma czasu. Bywa, że nie ma zasobów, sił. Albo jednych i drugich brak jednocześnie. Gdy tymczasowe rozwiązanie już powstanie, nie ma znów sił i czasu oraz zasobów, by się go pozbyć i zrobić rzecz zgodnie ze sztuką. Goni nas kolejny deadline, pojawia się następny projekt, a krótkotrwałe obejście, „hack”, żyje swoim życiem… Przez lata czasami, aż nie stanie się niebezpieczne, aż nie zagrozi biznesowi.
Dług techniczny, dług technologiczny istnieje w każdym projekcie IT. W innych formach zjawisko to pojawia się wszędzie. W naszym domu, kiedy zaczyna istnieć jakiś kąt, gdzie rośnie nieporządek – jak w przysłowiowym zamiataniu pod dywan – rośnie, rośnie, aż w pewnym momencie orientujemy się, że w całym mieszkaniu jest bałagan. W naszym ciele, kiedy kilka komórek wymyka się spod kontroli i zaczyna mnożyć, a po latach okazuje się, że lekarz diagnozuje nowotwór. Jak również w biznesie – na przykład, kiedy pracownik w podeszłym wieku, zajmujący się od lat częścią jakiegoś istotnego procesu biznesowego przechodzi na emeryturę lub umiera, a wraz z nim ginie wiedza i umiejętność wykonywania zadań, które okazują się kluczowe. I nagle cała firma wpada w tarapaty.
Dług technologiczny to ziarno chaosu. Odpowiedzialnością programistów oraz kierowników IT jest kontrolowanie go, niedopuszczanie do jego nadmiernego rozrostu. W przeciwnym wypadku, jeśli tylko pozwolimy mu wypuścić pędy, zapuścić korzenie, dług techniczny nas zniszczy – naszą pracę, naszą firmę, nasze życie. Nie pozwólmy mu rosnąć…
Programista 15k – legenda polskiej branży IT, wzorzec sukcesu wykonany ze stopu pracowitości (90%) i pychy (10%), przechowywany w Raszynie pod Warszawą. To o nim pisane są artykuły o clickbaitowych nazwach. To przed nim drżą korporacyjne budżety. To o nim myśli rodzina, gdy słyszy, że jesteś programistą. Jak piękne jest życie programisty 15k? Czy jest usłane najczulszymi płatkami róż, oddzielonymi starannie od kolców?
Jak wykuwa się 15k
Programista 15k, wyjaśnijmy na początek nieświadomym, to osoba zarabiająca w tym zawodzie 15 tysięcy zł. Nomenklatura nie precyzuje, czy brutto, czy netto, czy B2B, czy UoP, ale bez względu na to, są to bardzo przyzwoite pieniądze w naszym nadwiślańskim kraju. Pieniądze pozwalające żyć wygodnie.
Programista taki – spróbujmy go scharakteryzować – z pewnością jest doświadczony. To nie jest osoba z rocznym czy dwuletnim, lecz raczej kilku, kilkunastoletnim doświadczeniem, oscylującym w okolicy 10 lat. Jest to koder, który z niejednego repozytorium klonował kod. Zna dobrze kilka technologii, umie się porozumieć z biznesem, ma dobrą prezencję. Jego CV imponuje i uwodzi rekruterów.
Co robi?
Ciężko powiedzieć co w zasadzie tak konkretnie robi programista 15k, bo oferty o wysokich stawkach pojawiają się właściwie w każdej specjalizacji. Obecnie najczęściej będą to specjaliści DevOps (o ile można ich nazwać programistami). Bycie full-stackiem jest dobrą ścieżką w kierunku 15k. Jednak również backendowcy, czy frontendowcy znajdą oferty pozwalające na dołączenie do tego elitarnego grona.
Jedno jest pewne co do zadań stojących przed takim koderem – albo musi być wybitny, a projekt jest nieprzeciętnie wymagający albo musi być doświadczony i dobry, a projekt jest nudny, nużący lub mało perspektywiczny, ewentualnie ryzykowny. W życiu nie ma nic za darmo. Pierwsza opcja jest oczywista, wymagający projekt wymaga nietuzinkowych koderów, a tych jest niewielu i mogą dyktować warunki. Efektem jest wysoka płaca.
W czym więc problem?
Problemem jest drugi przypadek – projekty nudne, żmudne, mordercze. Tak miażdżące programistów, że uciekają z firmy. Rośnie rotacja. Wdrożenie nowych zajmuje czas, a przy okazji znika z przedsiębiorstwa i projektu wiedza. Trzeba temu przeciwdziałać. Przekupujemy więc kolejnych kandydatów. Sprawiamy, że nigdzie indziej nie dostaną więcej i ich wytrzymałość na frustrację wzrośnie, bo ciężko jest jednak dobrowolnie zrezygnować z dajmy na to jednej trzeciej zarobków.
Jest co prawda jeszcze jedna możliwa ewentualność– potrzeba szybkiego zatrudnienia dużej ilości pracowników. Wtedy, by zachęcić kandydatów do natychmiastowej decyzji podbija się stawki, to jednak krótkotrwała i tymczasowa sytuacja…
W czym zatem problem? Otóż wbrew pozorom jest ich kilka.
Po pierwsze pieniądze. Owe 15 tysięcy to dużo i mało jednocześnie. Dużo, bo stanowi omal sufit wynagrodzeń w IT, a jednocześnie pozwala na wygodne życie. Do wygodnego życia łatwo się przyzwyczaić. Z kolei przez lata podwyżek i awansów programiści przywykli do stopniowego zwiększania dawek najbardziej uzależniającego z narkotyków. Programista 15k chciałby się zatem w jakiś sposób rozwijać, ale właściwie nie ma takiej możliwości. Rozwój finansowy? – nie może znaleźć lepiej płatnej pracy. Rozwój techniczny? – musi zrezygnować z pieniędzy, by zdobywać doświadczenie.
Jedyne możliwości zmiany sytuacji finansowej na lepszą to założenie własnej firmy lub zostanie managerem (co może tymczasowo znacząco obniżyć wynagrodzenie). Alternatywą jest trwanie na stanowisku, które oferuje dobre pieniądze, ale eroduje umiejętności, często przy tym krusząc duszę. Ludzie natomiast – a szczególnie ludzie, którzy od lat szli w górę – zawsze chcą więcej. Pojawia się wówczas frustracja.
Ten ból widoczny w oczach obserwowałem parokrotnie. Tych biednych, bystrych koderów, którzy przeszli już cały labirynt i nie znaleźli wyjścia. Kolejne projekty w weekendy, podcasty, szkolenia, inwestycje, wszystkie te próby przebicia sufitu sprawiają, że część z nich gorzknieje. Młodzi programiści, u progu kariery, mają błysk w oczach, nadzieję na tłuste lata, na wzrost, rozwój. Doświadczeni mają niestety często zmęczenie i strach w tych mądrych, dojrzałych oczach – strach, że nic ich już nie czeka, poza kolejnymi sprintami, buildami i bugami.
Bowiem IT to wbrew pozorom branża marzycieli. W wielu z nas tkwią nadal nastoletni chłopcy zafascynowani potęgą komputerów. Jedni z pokolenia, które obserwowało przegraną Kasparova z Deep Blue, inni z pokolenia, które patrzyło na szok i desperację Lee Sedola, gdy zwyciężało go AlphaGo. Każdy z perspektywą, że już niedługo zbudujemy RoboCopa, a najlepiej Motoko Kusanagi z Ghost In The Shell – że spod naszych palców wyjdzie kod przełomowy, że oprogramujemy autonomiczne samochody i inne genialne gadżety. Programiści 15k to zwykle ci, którzy wiele już napisali, a mało z tego co napisali sprawiło im prawdziwą dumę (mimo, że było wartościowe dla gospodarki). To ci, którym do emerytury pozostało trzydzieści lat, a którzy nigdy już w swoim zawodzie nie awansują, to ci, którzy umieliby napisać coś ambitnego, ale nie mają w Polsce takich projektów, to ci którzy stanęli na szczycie i mimo, że są szczyty wyższe, to muszą z niego zejść, przeprawić się przez rzekę i zacząć wspinać się na kolejny, inny, a sił im już brak…
Angular.js był przełomowym frameworkiem, który zredefiniował nasze myślenie o front-endzie i znacząco podniósł produktywność. Kolejna jego wersja, łamiąca kompatybilność oraz opublikowana z poślizgiem otworzyła pole do ekspansji Reacta. Czy Angular zaprzepaścił swoją szansę na dominację? Czy Angular umiera?
Portal The State of JavaScript publikuje regularnie świetne raporty na temat ekosystemu współczesnego JavaScriptu. Analizowana jest popularność i satysfakcja z używania front- i back-endowych frameworków, bibliotek do testowania oraz zarządzania stanem i danymi w aplikacji.
Wzmianki o Angularze nie są optymistyczne. Poniżej diagram zainteresowania frameworkiem, ukazujący wyraźny trend spadkowy:
Tutaj z kolei widzimy spadek satysfakcji z pracy z Angularem:
Zadowolenie z pracy z frameworkiem jest według raportu The State of JavaScript tak niskie, że większość programistów, która ma z nim doświadczenie nie chce go ponownie używać. 21.9% ankietowanych osób zna i lubi Angulara, ale kolejne 35.8%, które również Angulara używało nie chce tego robić w przyszłości.
Aż 32.4% osób nie jest zainteresowanych zaznajomieniem się z frameworkiem.
Statystyki NPM wydają się być dla Angulara równie nieubłagane:
Warto zauważyć, że Angular nie tylko nigdy nie dogonił popularności Reacta, przynajmniej w tym zestawieniu, ale wręcz stracił przewagę nad Vue.
Na polskim rynku pracy wyraźnie dominuje React i Angular, aczkolwiek w ostatnich miesiącach daje się zauważyć zarówno pączkowanie ofert z Vue, jak i bardzo dobrze płatne oferty z Angulara. Może to świadczyć o spadku popularności tego drugiego – być może developerzy nie wierzą już we framework i nie chcą z nim pracować, dlatego trudno znaleźć chętnych do pracy i podbija to stawki. Możliwe też jednak, że Angular lepiej się przyjął w środowisku dużych korporacji, które mają potężne budżety…
Ciężko o jednoznaczną opinię i wyrok. Nie czas może jeszcze stawiać kreskę na Angularze, ale warto być czujnym i obserwować rynek.
Tworzenie oprogramowania jest jednym z najbardziej złożonych przedsięwzięć, jakich podejmuje się nasza cywilizacja. Nie dotyczy to co prawda każdego projektu, istnieją rzeczy proste, trywialne, ale nawet za nimi ciągnie się ogon bibliotek, systemów operacyjnych, procesorów i całej koncepcji programowania, wraz z algorytmami, maszyną turinga i językami formalnymi. Są jednak również projekty same w sobie niezwykle skomplikowane – systemy tradingowe, symulacje fizyczne, oprogramowanie symulujące zwijanie białek…
Rękodzieło
Mimo całej tej złożoności, jest w programowaniu duch rękodzieła.
Pracujemy nieraz nad arcydziełami koronkowej abstrakcyjnej twórczości, rozpiętymi na setki tysięcy linii kodu w sposób jakbyśmy toczyli wazę za czasów dynastii Han.
Poniżej przykładowa waza. Piękna rzecz, ale od czasu panowania dynastii Han, 206 BC–220 AD, trochę czasu minęło…
Co złego w toczeniu wazy? Niby nic. Tyle, że w przypadku wazy można, jak sądzę, nadać jej jakiś początkowy kształt, a potem malować kolejne fragmenty nieco improwizując. Tutaj smok, tam feniks, jakiś ornamencik.
I często wychodzi ładnie.
Gorzej jednak, kiedy przełożymy to na programowanie. Robimy jakieś MVC, tam dwa przyciski, tu jakiś dropdown, pod spodem kontrolerek i repozytorium i jakoś to będzie.
I czasami wychodzi ładnie.
Warto by jednak było, zanim zaczniemy implementować, lepić, klecić i klepać, zastanowić się, co tak w zasadzie system ma robić. Bo co waza ma robić, to wiadomo, a czy będzie miała dwa smoki i i trzy feniksy, czy też pięć ornamentów i jednego smoka, to już detal, o ile się je ładnie namaluje. Trochę też krócej się tworzy taką wazę. Gorzej jednak, jak w trakcie lepienia naszej wazy-MVC przychodzi klient i mówi, że chce czajnik. I jeszcze raz za dwa tygodnie i dodaje, że elektryczny…
Agile w dwójnasób
Wydawać by się mogło, że brak planu na początku projektu może wynikać z dominacji Agile na rynku. Promuje ona tworzenie jak gdyby ad hoc, w krótkich odcinkach czasu. Sądzę jednak, że brak planu to coś naturalnego, amatorskiego. Tak projekty tworzą studenci. Siadają do kompilatora i próbują. Próbują, piszą, nie planują. Miło jest coś zacząć, dać się pochłonąć entuzjazmowi. Mniej sympatycznie jest tworzyć plan, analizować, przewidywać problemy, a potem tego planu się trzymać.
Jest taka słynna grafika w świecie Agile. Ilustruje tworzenie MVP na przykładzie budowania samochodu. Znalazłem swego czasu ciekawszą:
Przez pewien czas sądziłem, że w istocie jedynie dolny rysunek ukazuje właściwą drogę, a tradycyjny przykład z hulajnogą, rowerem, motocyklem i samochodem jest błędny.
Tymczasem oba są poprawne. W zależności jednak od sytuacji.
Wyróżniłbym dwa modele tworzenia produktu:
kreatywny
konserwatywny
Produkt tworzony kreatywnie może wyewoluować w dowolnym kierunku. Przykładowo – projektujemy pierwszy smartphone. Nie wiemy jak ma wyglądać. Produkt może ewoluować znacząco, a feedback od klienta jest kluczowy i ma prawo kompletnie zmienić produkt.
Produkt tworzony konserwatywnie jest czymś, co już istnieje na rynku i nie planujemy go rewolucjonizować (albo czymś coś wręcz wiemy jak ma wyglądać, bo wynika z regulacji rynku, ustawy itp.). Chcąc zbudować nowy model samochodu nie ma sensu tworzyć hulajnogi. Możemy poeksperymentować z nadwoziem, wyposażeniem, ale nie z samą koncepcją auta.
Prototyp
Wydawać by się mogło, że prototypowanie jest czymś oczywistym. Pisarze tworzą pierwsze szkice, które potem udoskonalają, ubierają w szczegóły, a czasami zupełnie przerabiają. Malarze zwykle zaczynają obraz od zarysowania głównych jego elementów, również tworząc na początku coś w rodzaju prototypu. Projekty samochodów zawsze zaczynają się od produkowanych w jednym, czy kilku egzemplarzach wersji demo. Tymczasem w oprogramowaniu bywa różnie.
Widziałem projekty, gdzie nigdy niczego nie prototypowano. Proces tworzenia oparty był o pełną implementację w każdym sprincie. Zupełnie bezrefleksyjnie marnotrawiono czas, choć można było narysować na kartce propozycje rozwiązań i dojść do konsensusu miesiące szybciej.
Moim zdaniem każda aplikacja, która posiada interfejs graficzny (co stanowi sporą część, jeśli nie większość rynku) MUSI zacząć się od designu, następnie przejść w „klikalny” prototyp, by w końcu zostać w pełni zaimplementowana.
Stworzenie designu ułatwia zrozumienie produktu i zadawanie właściwych pytań. Większość osób jest wzrokowcami i potrzeba im wizualnej reprezentacji tego, nad czym mają podjąć pracę.
Prototyp z kolei pozwala dostarczyć klientowi coś namacalnego w czasie o wiele szybszym od pełnej implementacji. Rozwiązuje to frustrację biznesu związaną z czekaniem na pierwszy rezultat. Nic pewnie nie irytuje bardziej, niż słuchanie przez dwa miesiące technicznych sprawozdań bez możliwości ujrzenia wyniku pracy, jeśli zainwestowało się kilkadziesiąt lub kilaset tysięcy złotych w rozwój produktu.
W wielu firmach specialiści od UI i UX są bagatelizowani lub w ogóle się ich nie zatrudnia. To błąd. To gigantyczne przeoczenie. Ich praca to nie tylko rysowanie okienek – ich wysiłek ułatwia wszystkim zrozumienie produktu oraz pracę nad nim. Projekty zaczynajmy od szkicu, designu, przechodźmy do prototypu, a kończmy na implementacji!
Pandemia COVID-19 odsłoniła zarówno piękne, szlachetne, jak i ponure cechy rodzaju ludzkiego. W dobrych czasach łatwo być miłym. Stąd przecież mądre powiedzenie, że przyjaciół poznaje się w biedzie. Wrógów również w biedzie się poznaje.
Od kilku już lat dało się słyszeć głosy krytyki wobec programistów w Polsce. Słynny już artykuł „IT arystokracja” wszedł do słownika frazeologicznego naszego pokolenia. Przyprawiono w nim programistom gębę rozwydrzonych dzieciaków klikających w komputer i zarabiających piętnaście tysięcy na rękę. Nomen omen – programista15k stał się równie nośnym hasztagiem, co IT arystokracja hasłem.
Póki bezrobocie malało, a gospodarka rosła, było to jeszcze do przełknięcia dla większości osób spoza branży. Obecnie jednak, gdy wykluczenie z rynku wielu branż zasiało panikę, a na horyzoncie tli się gospodarcza pożoga – łaska dla IT się skończyła.
W coraz większej ilości miejsc czytam zjadliwe komentarze:
wam to łatwo mówić, bo sobie pracujecie zdalnie
w końcu się skończy eldorado dla programistów
teraz i wam się dostanie, książęta z IT
wywalą was to się przekwalifikujecie na magazynierów i zobaczycie jak życie wygląda
w kryzysie widać kto nic nie robi i jest zbędny
skoczą się konsole i piłkarzyki
Gorycz wykrzywia usta, bo nie czuję, by programiści otrzymywali swoje wynagrodzenia bezprawnie, żeby te pieniądze gwałtem, przemocą wyciągali od Bogu ducha winnych ludzi. Większość z nas ciężko pracowała przez ostatnie lata, uczyła się wytrwale nieraz przez dekady i wnosi solidny wkład w gospodarkę. Dzięki nam powstają systemy automatyzujące produkcję, ułatwiające pracę, dające rozrywkę. Posady w IT nie są państwowymi synekurami, ale miejscami, gdzie weryfikuje się umiejętności pracowników, nieraz bezlitośnie, w trwających godzinami testach. Programisci mojego pokolenia nie mieli nawet od kogo nauczyć się zawodu, bo ich ojcowie i matki programistami nie byli. Większość z nas to prawdziwi self-made mani.
Wielką szkodą jest, że społeczeństwo widzi w nas często jedynie rezultat naszych działań – mieszkanie, samochód, czy człowieka przed komputerem. Bardzo bym chciał, żeby dostrzeżono też lata studiów, dekady pasji i zaangażowania, skrzywione kręgosłupy, zaczerwienione oczy, młodość przed kompilatorami, wyrzeczenia, trud tej pracy łączącej w sobie wymagania wielu dziedzin (kreatywność, sumienność, matematyczny rygor, lingwistyczne zacięcie). I żeby nie zignorowano wpływu IT na jakość życia – tego, że dzięki programistom nie trzeba już stać w kolejce na poczcie po odbiór listu, w kolejce do okienka w banku, by wysłać przelew, że można rozmawiać z rodziną w UK na Skype, obejrzeć serial na żądanie, a nie w danej godzinie, słuchać dowolnej omal piosenki bez polowania na album w sklepie muzycznym i jechać przed siebie bez postoju i zaglądania w mapę oraz pytania przechodniów o drogę…
Czytanie kodu źródłowego jest trudniejsze, niż jego pisanie. Przyzna to każdy kto pracował z odziedziczonym repozytorium i próbował zrozumieć jego działanie. Przebijanie się przez tysiące linii kodu, przez setki definicji funkcji i zmiennych, w próbie zrozumienia co autorzy mieli na myśli jest ciężkim, męczącym, okrutnie wyczerpującym zadaniem.
Dlaczego tak jest?
Czy zrozumienie przepisu kuchennego jest trudne?
Czy jest trudniejsze od napisania go?
Czy zrozumienie przepisu kuchennego sprzed trzydziestu lat jest trudniejsze od zrozumienia przepisu sprzed tygodnia?
Nie sądzę.
Czemu więc czytanie kodu źródłowego staje się trudniejsze z każdym kolejnym miesiącem od jego powstania? Dlaczego nowy kod jest czytelny, a stary niezrozumiały? Jaka może być przyczyną “gnicia oprogramowania” i nienawiści do legacy code?
Zastanówmy się nad czynnością
czytania kodu źródłowego. Co robimy próbując zrozumieć program, wgryźć się w
kod?
Działamy jak komputery, tylko
mniej wydajnie. Przeglądamy kod, czytamy go, napotykamy na zmienne i funkcje.
Nie będąc maszynami nie jesteśmy w stanie spamiętać każdej wartości oraz ciągu
konstrukcji. Próbujemy więc “zrozumieć” kod. Napotykając na nazwę
zmiennej staramy się domyślić, co oznacza i w jakim kontekście jest używana.
Nazwy funkcji lub procedur również próbujemy zrozumieć, najlepiej bez wnikania
w ich treść.
Dokładnie tak samo działamy w
świecie rzeczywistym. Gdy w przepisie napotykamy na słowo “marchew”
wyobrażamy sobie marchew. Rozumiemy ideę marchewki bez zapoznawania się że
szczegółami takimi jak jej masa, kolor, DNA, czy temperatura.
Kod źródłowy jednak – mimo starań
obozu oprogramowania zorientowanego obiektowo – nie jest jak świat rzeczywisty.
Odstaje od niego znacząco.
W świecie rzeczywistym dysponujemy ogromną, lecz ograniczoną ilością słów w naszych słownikach. Języki naturalne przetwarzane są przez ludzkie mózgi zupełnie inaczej niż kod źródłowy przez kompilatory. Krzesło na przykład to dla człowieka nie tylko konkretne krzesło, ale idea krzesła jako takiego. W większości przypadków zbędne nam są szczegółowe informacje na temat obiektów by przetwarzać i rozumieć język naturalny, w którego zdaniach te obiekty, reprezentowane przez słowa, występują. Tam z kolei gdzie jest nam potrzebna precyzja definicji (jak w prawie na przykład) napotykamy na spore problemy.
Świetnym przykładem ilustrującym, co by było gdybyśmy przetwarzali język naturalny tak jak komputery przetwarzają kod źródłowy jest ten filmik:
Wróćmy do czynności czytania kodu przez programistów. Cóż robi developer? Czyta nazwę zmiennej lub funkcji i próbuje zgadnąć, co ona oznacza. Póki kod jest “czysty” i niezbyt stary instynktowne zrozumienie jest stosunkowo poprawne. Czytanie idzie mu dobrze i praca z kodem jest sprawna.
Kłopot zaczyna się, gdy nie jest w stanie poprawnie domniemać znaczenia nazw.
Problem jest jednak znacznie poważniejszy. Jest to jedna z fundamentalnych trudności w rozwoju oprogramowania. Częściowo oddaje to poniższy cytat:
There are only two hard things in Computer Science: cache invalidation and naming things
Phil Karlton
Chodzi o nazewnictwo.
Nazewnictwo jest punktem styku pomiędzy światem maszyn i ludzi. Jest jednocześnie przepaścią między jednym, a drugim. W świecie rzeczywistym, gdzie język ludzki rozumiany jest przez mózgi, które są w stanie instynktownie zrozumieć klasy obiektów / idee przedmiotów rzadko tworzone są nowe słowa. W kodzie źródłowym nowe słowa tworzone są nieustannie.
Co dzieje się, gdy tworzymy nowe
słowo w ludzkiej mowie? Uczymy się go. Powstaje nowe słowo – na przykład „komputer”
– i wszyscy ludzie na świecie uczą się, że oznacza ono taką, a nie inną rzecz.
Nie ma znaczenia, czy mowa o MacBooku, Dellu XPS, ENIACu, czy PC-cie. Nie
tworzymy odrębnych słów opisujących komputery stojące w każdym z departamentów firmy,
nie tworzymy innych słów na różne modele MacBooka mające inną wielkość pamięci
RAM. Nie ma takiej potrzeby. Nowe słowa tworzymy rzadko. Za nowym słowem kryją
się duże grupy obiektów.
Inaczej jest w przypadku kodu
źródłowego. „Użytkownik” znaczy co innego w każdym omal programie, jaki do tej
pory napisano. W jednych jest to imię i nazwisko, w innych również data urodzenia,
w jeszcze innych płeć. W niektórych imię i nazwisko może się składać tylko z liter
łacińskich, w pewnych mieć maksymalnie 20 znaków. I tak dalej, etc.
Mówiąc krótko: w kodzie źródłowym niczego nie da się nazwać poprawnie. Żadna nazwa, jak dobrej byśmy nie wybrali, nie będzie odpowiadała znaczeniu słów wyjętych z języka naturalnego, ze świata ludzi.
Możemy być tylko zbyt precyzyjni („user”) lub zbyt ogólni („userWithNameAndSurnameAndSexAndDateOfBirth). Nigdy omal nie będziemy idealnie precyzyjni w nazywaniu zmiennych, czy funkcji. Nigdy te nazwy nie będą znaczyły tego, co nam się wydaje. Zawsze musimy nawigować się do definicji i czytać implementację. Za każdym razem, gdy dołączamy do istniejącego projektu musimy „nauczyć się jego języka”. Nauka nowego języka jest zawsze trudna, żmudna i męcząca. Dlatego właśnie, ze wszystkich wymienionych powyżej przyczyn, czytanie kodu źródłowego jest trudne.
Zarobki programistów w Polsce obrosły legendą. Gazety rozpisują się o nich regularnie. Bywa, że w tonie chwalebnym, bywa, że w tonie nagannym. Jedni ich bronią, twierdząc, że programiści to pożyteczni specjaliści. Inni atakują – wyczekują pęknięcia „bańki” i zrównania zarobków z innymi zawodami. Wiele osób zadaje sobie jednak pytanie – dlaczego programiści zarabiają tak dużo?
Zacząć by należało od tego, że sytuacja w Polsce jest
dość specyficzna. Większość osób zajmujących się w naszym kraju oprogramowaniem
pracuje dla zagranicznych klientów. Napływ kapitału (głównie z Europy
zachodniej) wzmożył popyt na programistów i w naturalny sposób podniósł cenę
ich pracy. Kwestią otwartą jest, jak długo sytuacja ta potrwa, ale na pewno
jest korzystna dla Polskiej gospodarki w tym sensie, że eksportujemy nasz
talent techniczny otrzymując w zamian, mówiąc językiem PRLu, dewizy – czyli
zagraniczne waluty, a także przy okazji importujemy zachodnie praktyki
zarządzania projektami, doświadczenie organizacyjne i nawiązujemy kontakty
biznesowe z bogatszymi krajami wspólnoty europejskiej.
Często mówi się, że w przeciwieństwie do innych zawodów, programiści w Polsce, pracując dla zagranicznych klientów zarabiają „po zachodniemu”. Prawdę powiedziawszy jest nawet lepiej. Pensje programistów w Portugalii, czy Włoszech są wręcz niższe, niż w Warszawie, czy innych dużych miastach Polski. Z drugiej strony średnie wynagrodzenia są nadal niższe niż w Berlinie, Paryżu, czy – szczególnie – Zurychu lub Nowym Jorku.
Sukces Polski (oraz szerzej – Europy wschodniej) wynika z wysokiego poziomu edukacji, bliskości kulturowej z krajami zachodu, niewielkiej odległości geograficznej, niezłej znajomości angielskiego oraz oczywiście niższych wynagrodzeń. Na chwilę obecną sytuacja wygląda tak, że kluczowe projekty odbywają się w centrach korporacji, te mniej istotne w krajach takich jak Polska, czy Rumunia, a te najbardziej kosztowo zoptymalizowane w Indiach. Ulotki dla inwestorów prezentują Europę środkową jako kompromis między jakością i ceną.
Z drugiej strony istnieje w Polsce pokaźna grupa programistów, którzy pracują za kwoty co prawda wyższe od średniej krajowej, ale również dalekie od słynnych 20 000 PLN. Grupa ta nadal jest słabiej wynagradzana od kolegów z krajów zachodu. Lepiej rzecz jasna od wielu zawodów w Polsce, jednak ciężko ją uznać za realnie zamożną.
Sytuacja w Europie
Programiści w Europie zarabiają bez wątpienia nieźle,
jednak w stosunku do innych grup zawodowych ośmielę się stwierdzić, że nie
odbiegają od średniej tak jak specjaliści w Polsce. W pewnej mierze wynika to z
konkurencji środkowo-europejskiej. W pewnych krajach niemile widziane jest duże
rozwarstwienie dochodów. W innych po prostu miejsc pracy dla programistów nie ma
aż tak wielu, bo bardziej opłacalnym i „wygodnym” jest bycie zarządcą – a sporo
krajów Europy zachodniej stoi wyżej w światowym podziale pracy.
Kraje, które w stosunku do kosztów życia płacą programistom najlepiej to Szwajcaria, Wielka Brytania, Niemcy i Francja. Kraje, w których być programista się nie opłaca to na przykład Włochy, czy Portugalia.
Sytuacja na świecie
Na dwa kraje warto zwrócić szczególnie baczną uwagę: USA
i Chiny.
Na USA z uwagi na tzw. military-industrial complex, czyli nieformalny sojusz pomiędzy przemysłem zbrojeniowym, a armią. Na Chiny z podobnego powodu, ale o tym za chwilę.
stany Zjednoczone dysponują nowoczesną – w wielu obszarach najnowocześniejszą na świecie – armią. Jest to armia nieustannie modernizowana, przesiąknięta nowinkami technicznymi, wyposażona w sprzęt pełen elektroniki.
Dość powiedzieć, że GPS był opracowany na potrzeby armii USA. Dla pełni obrazu można wspomnieć o dronach oraz przypomnieć, że roboty Boston Dynamics budowane były na zamówienie DARPA – agencji zaawansowanych projektów badawczych w obszarze obronności.
Ma to niebagatelny wpływ na rynek pracy inżynierów oprogramowania w USA. Boston Dynamics, Lockheed Martin, Facebook – wszystkie te firmy i wiele innych, zatrudniających setki tysięcy programistów stanowi fundament obronności kraju. Od automatycznych systemów jak drony, czy roboty, po wywiad i cyberbezpieczeństwo, tworzą one ogromny popyt na programistów za oceanem.
Z wolna podobnie sytuacja zaczyna się kształtować w Państwie Środka. Wzrost Chin powodujący inflację ambicji chińskiego narodu sprawił, że przywództwo zaczęło stawiać śmiałe cele. Jednym z kluczowych obszarów w Chińskich planach jest sztuczna inteligencja. Innym, oczywistym, jest rozwój armii. Rzut oka na oferty pracy w Szanghaju, czy Shenzhen pokazuje, jak mocno Chiny stawiają na AI.
Wbrew powszechnej w Polsce opinii, że Chińczycy pracują „za miskę ryżu” wynagrodzenia programistów z ofert pracy w większym mieście posiadającym przedsiębiorstwa z branży militarnej (Chengdu) oscylują wokół 20 000 RMB miesięcznie (ok 11 200 PLN). Daleko im oczywiście do wynagrodzeń oferowanych w Stanach, ale z powodu tych samych czynników, co w USA, można się spodziewać wzrostu popytu.
Dlaczego to się opłaca?
– Nie rozumiem, czemu programista zarabia 15 000, kiedy ja zarabiam 4 000 – powie osoba spoza branży.
Tymczasem to proste.
Informatyzacja robi w zasadzie dwie rzeczy:
automatyzuje
pewne czynności sprawiając, że można zatrudnić mniej osób
czyni możliwym
rzeczy wcześniej nieosiągalne
Punkt pierwszy, przykład – swego
czasu by sporządzić raport sprzedaży w jakimkolwiek sklepie, trzeba było usiąść
przed stosem kartek i wykonać dziesiątki, setki operacji matematycznych. Dziś
wystarczy kilka kliknięć i mamy wartości i wykresy, a to wszystko w kilka
sekund. Jeśli w jakimś przedsiębiorstwie istniała osoba zajmująca się
przygotowywaniem raportów (będących powtarzalnymi operacjami przetwarzania
danych) można ją zwolnić. Raz opracowane narzędzie do generowania raportów posłuży
tysiącom przedsiębiorstw, zaś wykonanie i aktualizacja tych narzędzi zajmuje o
wiele mniej czasu i wymaga mniej etatów od tych, które dzięki owemu narzędziu
stały się zbędne.
To tylko najbardziej prymitywny
przykład automatyzacji. Dużo lepszym są choćby roboty spawające szkielety
samochodów w fabrykach:
Zaprogramowany raz robot wykonuje pracę za darmo. Spawacz za każdą minutę bierze pieniądze.
Punkt drugi dotyczy nowych możliwości. Przykłady można mnożyć. Najlepszym bodaj będzie smartfon. Dzięki pracy między innymi programistów możemy dziś nawigować w terenie, słuchać muzyki, komunikować się ze światem i robić dziesiątki innych rzeczy na kilkuset gramowym urządzeniu wielkości połowy banana. Płacimy za nie producentom nieraz tysiące złotych. Dla wyprodukowania takiego cudeńka warto zatrudnić programistów.
Właśnie dlatego programiści mogą
zarabiać dużo. Nie tylko nie ma ich nadmiaru na rynku pracy, lecz także są w
stanie generować dla firm zysk o wiele większy, niż przedstawiciele pozostałych
profesji.
Pewnych nawyków ciężko się pozbyć. Mówi się często o tym,
jak ważne są pierwsze odruchy, jakich nabieramy podczas nauki gry na
instrumencie. Samoucy natrafiają często na trudności na późniejszym etapie, gdy
zmuszeni są oduczyć się błędnych zachowań. Dlatego wynajmujemy dzieciom
nauczycieli lub posyłamy je do szkół muzycznych…
Programowanie jest niezwykle dynamiczną dziedziną, z którą jako kraj przez wiele lat nie mieliśmy styczności. Choć na poziomie akademickim pewne techniki i rozwiązania mają już swoje lata i niektórzy twierdzą, że nihil novi sub sole, to jednak wciąż rodzą się nowe strategie radzenia sobie z problemami, nowe pomysły, technologie i języki.
Większość programistów w Polsce nauczyła się programować na studiach. I choć brzmi to niebywale – w większości z nas wciąż tkwią nawyki z tamtego okresu. Nie są to nawyki chlubne. Krajowe uczelnie jak można się dowiedzieć z dowolnego rankingu nie są najlepszymi uniwersytetami świata, a realia wydziałów informatycznych są chyba jeszcze gorsze, niż polskich akademii ogólnie.
Oczywiście mówi się wiele o
sukcesach naszych studentów, o wysokich pozycjach polskich programistów w
rankingach i tak dalej, ale niestety odpowiedź na pytanie – jakie więc świetne
produkty stworzyliśmy? – ogranicza się do gier CD Project oraz platform UXPin, Brand24,
czy CodeWise. Oczywiście pod cudzymi markami piszemy o wiele więcej, ale wbrew
tłumowi pozwolę sobie być sceptyczny, co do naszych umiejętności – nie u nas
urodził się Torvalds, ani Stroustrup, Dijkstra, czy Knuth. Trzeba nam pokory i
praktyki.
Uczelnie zatem wpoiły nam złe nawyki. Jakie konkretnie?
1. Przedwczesna optymalizacja
Jak rzekł wspomniany tu już Donald Knuth – przedwczesna optymalizacja jest źródłem wszelkiego zła. Tymczasem na nauce klasycznych algorytmów oraz progresji ku wydajności skupia się program nauczania informatyki na uczelniach. Uczy się studentów sortowania bąbelkowego, by potem pokazać im lepsze, wydajniejsze. Wiele przedmiotów dotyczy głównie na optymalizacji – uczymy się o drzewach BST, o algorytmach grafowych, niektórzy również o kompresji. Wpaja to w studentów przeświadczenie, że wydajność jest okrutnie ważna, najważniejsza. Tymczasem w projektach biznesowych rzadko tak jest.
2. Brak edukacji w zakresie planowania dużych projektów
Ze studiów pamiętam dziesiątki projektów małych, ani jednego wielkiego. Nie organizuje się grupy kilkunastu osób, by wykonały coś dużego, ale zleca pojedynczym studentom malutkie programiki do napisania w pojedynkę. Nie daje to szans na nabycie umiejętności zarządzania wielkim projektem, radzenia sobie z problemami większymi od pojedynczego programisty – a tylko takie projekty spotykamy później w firmach. Dzielenie projektów na etapy, estymacja zadań, ustalanie priorytetów – te kwestie są w edukacji akademickiej nieobecne.
3. Samotnictwo a.k.a. brak umiejętności pracy w grupie
Jak w poprzednim punkcie wspomniałem – projekty na polskich uczelniach są małe, przeznaczone dla jednego studenta na tydzień lub miesiąc, czy dwa. Pociąga to za sobą spore konsewkwencje nie tylko na płaszczyźnie zarządzania projektem. Programiści samotnicy nie mają szans nauczyć się pisać czystego kodu. Pisząc krótko i w pojedynkę nie mogą pojąć wykładu o czystym kodzie, jeśli taki się pojawi. Te problemy dopadną ich dopiero w pracy. Tak samo zresztą jak umiejętność kooperacji z kolegami. Na studiach widziałem wielu, nieraz świetnych, studentów, którzy kompletnie nie potrafili pracować we dwójkę, nie mówiąc o większej grupie. Narcystyczni, outsiderscy, z przerośniętym ego – tacy ludzie dopiero w pracy napotykają na olbrzymie trudności, przez studia przechodząc nieraz z wielkimi sukcesami.
4. Piśmienni, ale nie „czytelni”
Wiele, jeśli nie większość, projektów biznesowych posiada rozbudowane repozytoria istniejącego kodu. Rzadko zdarzają się greenfields, w których można sobie pozwolić na kreatywność i tworzenie z pominięciem lektury cudzego kodu. Czytania jednak studia nie uczą. Poza zrozumieniem algorytmów, gdzie raczej o zrozumienie konceptualne idzie, a nie o czytanie konkretnego zapisu w wybranym języku programowania, nie ma na akademiach przedmiotów związanych z czytaniem kodu źródłowego ze zrozumieniem. Jest to tymczasem kluczowa umiejętność w codziennej pracy każdego profesjonalnego programisty.
5. Dokumentacja? Komu to potrzebne?
Nie licząc pracy magisterskiej i kilku raportów – nigdy na uczelni nie musiałem dokumentować stworzonego oprogramowania. Oczywiście nie każdy aspekt projektu opisywać słownie należy, ale podejście, z jakim się spotkałem na uniwersytecie polegało na oczekiwaniu, by kod działał, niekoniecznie jednak na opisaniu go. Liczył się rezultat, wynik, wyjście, przy zadanym wejściu. Nigdy nie stawiano nacisku na to, co jest w oprogramowaniu niezwykle istotne i stanowi żywotny interes przedsiębiorstw – na utrzymywalność, dokumentację, na transfer wiedzy.
Co zatem robi świeżo upieczony junior magister, o ile jedyne czego się nauczył to program studiów? Nie dokumentuje, pisze bałaganiarski kod, nie wie jak estymować, nie ma pojęcia o ustalaniu priorytetów, nie wie jak się dogadać z kolegami, boi się deadline’ów i nie umie rozmawiać z biznesem, pisać kod potrafi, ale czyta z trudem.
Obyśmy dożyli czasów, gdy akademie zreflektują się, jak ułomne są efekty ich pracy i podejmą próby uzdrowienia sposobu w jaki uczą…
Wycofanie się programisty z wyceny, którą zrobił może oznaczać kilka rzeczy, a każda z nich jest zła… Po pierwsze możliwe, że programista jest leniwy i ją zawyżył. Druga opcja, to niestaranne jej przygotowanie. Trzecia wreszcie to, że programiście takiemu brak odwagi cywilnej i woli skłamać, niż powiedzieć gorzką prawdę.
2. Lepiej tego nie ruszajmy
Powyższe zdanie sygnalizuje przede wszystkim zły stan projektu. Jakaś jego część jest tak krucha, że strach ją zmieniać. Jednak jest to również symptom kiepskiej jakości programisty, bo osoba doświadczona powiedziałaby raczej – modyfikacja tego fragmentu projektu jest ryzykowna – po czym spróbowała sytuację naprawić.
3. To 10 minut roboty
Niewinne, ale jednak łgarstwo. Nawet niewielkie zmiany w kodzie, przy złożoności technologii i narzędzi, jakich używamy w rozwoju oprogramowania nie zajmują 10 minut. Jeśli programista obiecuje takie dziesięciominutowe rozwiązania, to najpewniej składa również inne obiecanki-cacanki.
4. Czysty kod to kwestia gustu
Znany z innych obszarów życia relatywizm – nie ma brzydoty, bo komuś coś się podoba. Cóż – czysty kod jest jak czyste miasto. Kiedy widzimy wybite szyby i opadające tynki; kiedy widzimy bełkotliwe nazwy zmiennych i rozwlekłe metody – wiemy, że jesteśmy w mieście, wiemy, że jesteśmy w kodzie brudnym, upadłym, gnijącym. Nie ma tu miejsca na relatywizm. I nie można bronić swojego niechlujstwa relatywizowaniem.
5. To tak było od zawsze
Konserwatyzm jest może dobry w pewnych dziedzinach życia, ale na pewno nie w rozwoju oprogramowania. Nasza branża premiuje dynamiczne zmiany i jeśli ktoś trzyma się starych rozwiązań bez rzeczowego uzasadnienia, a tylko na podstawie tego, że są stare – nie jest dobrym reprezentantem naszego zawodu.
6. Jest bałagan, ale nie mamy czasu na refaktor
O ile są zawody i branże wymagające działania tu i teraz, jak na przykład bycie strażakiem, o tyle – za wyjątkiem “gaszenia pożarów” na produkcji – rozwój oprogramowania nie jest tą branżą, a programowanie tym zawodem. Jeśli jest bałagan, to znaczy, że struktura kodu, projektu przeszkadza nam w pracy. Jeśli programista doprowadza do takiego stanu, to już jest sygnał alarmowy. Jeśli w dodatku tego stanu nie umie zakończyć – rozmawiając z biznesem, wygospodarowując czas, poświęcając wysiłek na uporządkowanie chaosu – to już oznacza, że jest po prostu bałaganiarzem szukającym wymówek, a nie efektywnym profesjonalistą.
7. Nie było czasu na testy
Jeśli nie było czasu na testy, to po co był czas na pisanie kodu? Kod bez testów jest gorszy niż brak kodu w ogóle, bo działanie szkodliwe jest gorsze od zaniechania działania. Co więcej – jeśli nie było czasu na testy, to najwidoczniej nie został on przez programistę uwzględniony na etapie planowania albo też pojawiły się problemy, które podczas implementacji przemilczał, podejmując bez wiedzy biznesu decyzję o obniżeniu jakości.
Reguła DRY jest obok YAGNI, SOLID, czy KISS jednym z
najpopularniejszych akronimów pisanych wielkimi literami, które wypłynęły na
sposób w jaki staramy się tworzyć oprogramowanie. Jest prosta, intuicyjna i
przyswajana przez programistów na wczesnym etapie edukacji. Tyle, że zrodzona w
zupełnie innych okolicznościach, niż te z którym dziś mamy do czynienia stała
się martwa.
Jej truchło leży na środku sceny i zatruwa nas swoimi oparami.
Prosty pomysł
Nie jestem historykiem
programowania i nie dysponuję pewnością co do genezy reguły DRY, ale wyobrażam
sobie, że powstała w czasach programowania proceduralnego. W każdym razie
proceduralnością pachnie, wręcz cuchnie.
Prosty to pomysł. Banalnie
prosty. Mamy sobie kod. Kod należy organizować w procedury, czyli wycinać bloki
kodu, które są używane wielokrotnie. Jeśli w jakimś bloku się powtarzamy, to
działamy źle, powinniśmy wydzielić go i przekształcić w procedurę.
Ciągle mało
Od czasu programowania proceduralnego trochę się pozmieniało. Przede wszystkim nastąpiła wielka eksplozja paradygmatu obiektowego. Złożoność oprogramowania wzrosła. Biznes miał już swoje systemy automatyzujące księgowość, sumujące przychody, generujące raporty. Trzeba było pisać przeglądarki internetowe, komunikatory, systemy tradingowe dla giełd i snake’a na 3310. Poza ostatnim – były to coraz większe wyzwania.
Tyle tylko, że reguła DRY pasuje do programowania obiektowego jakby mniej. W zasadzie w ogóle nie pasuje, jak się dobrze zastanowić.
Co się dzieje, gdy próbujemy w obiektowym kodzie unikać powtarzania się? Pierwsze co przychodzi do głowy to dziedziczenie: piękny akademicki koncept, który załamał się pod ciężarem rzeczywistości. Pies się wabi, kot ma imię, zróbmy klasę zwierzę. Zrobiliśmy. Szybko okazuje się, że pies się wabi, ale jednak imiona ma inne niż kot, że wabi się, ale kot jakoś gorzej reaguje na własne imię, że zwierzę ma imię, ale nie do końca, bo tylko zwierzę domowe. Robimy klasę zwierzę domowe i dzikie. O cholera – przecież prawie nikt nie nazywa swoich rybek.
Drugie popularne rozwiązanie to żartobliwa oznaka senior developera. Co robi senior developer, gdy przychodzi do chaotycznego projektu? Tworzy folder utils.
Klasy gromadzące wspólne, niepasujące nigdzie indziej kawałki kodu znajdują się obecnie w większości projektów. W niektórych z nich widziałem nawet rozrosłe do 8-16 tysięcy linijek „commony”. Tych polipów da się uniknąć i tak naprawdę powinny zostać rozmasowane z głową na różne fragmenty projektu, ale ich głównym źródłem jest próba stosowania reguły DRY – wydzielenia gdzieś, gdziekolwiek, bo tak najłatwiej, kodu, który się powtarza.
Mikroserwisy –
gwóźdź do trumny
Kiedy zapytałem kolegi, który odszedł z Amazona – firmy, która traktowana jest jako modelowa i pionierska, jeśli chodzi o stosowanie architektury mikroserwisów – jak organizują części wspólne, skąd wiedzą, że inny zespół nie napisał już czegoś podobnego, odparł:
Nie szukamy. Piszemy swoje rozwiązanie. Przy tej skali jest to tańsze i szybsze.
Skala, ogrom systemów, z jakimi przychodzi nam się dzisiaj mierzyć sprawia, że konieczne staje się dzielenie ich na mniejsze. W zasadzie od zawsze było to jedną z podstaw programowania, ale w architekturze mikroserwisów oraz komponentowym podejściu do aplikacji webowych (Angular, React) trend ten uwyraźnia się i przybiera na sile.
I w gruncie rzeczy jest to dużo bardziej obiektowe oraz zgodne z naturą, niż dziedziczenie. Organizmy są do siebie podobne, ale ciężko powiedzieć, żeby były takie same. Oko człowieka nie jest tym samym okiem, co oko psa, czy sokoła. Tylko z pozoru i powierzchownie można zakładać, że jest możliwe współdzielenie. Nie jestem ekspertem z dziedziny genetyki, ale nie wydaje mi się, że gdyby wyciąć z człowieka fragmenty DNA, których nie współdzieli z małpą stałby się automatycznie orangutanem. Silne jest we mnie podejrzenie, że choć wiele w tym podobieństw, czy identycznych fragmentów kodu, to jednak subtelności, kilka „linijek” różnicy sprawia, że dziedziczenie trzeba wziąć w duży, znaczący cudzysłów.
Jak żyć?
Wygląda na to, że reguła DRY dobrymi intencjami wybrukowała nam piekiełko. Czy czas ją odrzucić? Być może. Na pewno warto ją jednak przemyśleć. Warto pamiętać, że w wielu scenariuszach nie powinna być dla nas rekomendacją, że nie jest uniwersalnym narzędziem. Powtarzalność kodu może sygnalizować problemy, a równie dobrze może być najlepszym możliwym rozwiązaniem.
Czy dwukrotne powtórzenie identycznego kodu jest złe? Jeśli w tej samej klasie, pewnie jest. Jeśli w tym samym module, być może. A jeśli w projekcie składającym się ze 100 000 linii kodu, w odległych od siebie modułach? Chyba nie.
Czy częściowe powtórzenie kodu jest złe? Cóż, może nie jest złe arbitralnie, a zależy to od tego, czy da się zbudować odpowiednią abstrakcję, która pozwoli tego uniknąć? Często stosujemy pewne zasady ortodoksyjnie. Dobrze jest jednak zostać centrystą. Wybrać złoty środek. Reguły w programowaniu to zwykle zaledwie sugestie. Nie kierujmy się nimi ślepo.
Nasza strona internetowa używa plików cookies (tzw. ciasteczka) w celach statystycznych, reklamowych oraz funkcjonalnych. Dzięki nim możemy indywidualnie dostosować stronę do twoich potrzeb. Każdy może zaakceptować pliki cookies albo ma możliwość wyłączenia ich w przeglądarce, dzięki czemu nie będą zbierane żadne informacje. Ustawienia ciasteczekAKCEPTUJ
Ochrona danych i polityka ciasteczek
Ochrona danych
Ta strona korzysta z plików cookie, aby poprawić wrażenia podczas przeglądania witryny. Z tych plików cookie pliki cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są one tak samo niezbędne do działania podstawowych funkcjonalności strony. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
