Jak język programowania potrafi zdeterminować karierę? – 🔈 Root Cause by Vived #7

Jakie są najpopularniejsze języki?

Temat trochę wyświechtany, ale pewnie od niego nie uciekniemy. Najbardziej szanowanym rankingiem tego typu jest TIOBE, aczkolwiek prywatnie zdecydowanie bardziej lubię odnosić się do wyników zaprezentowanych przez choćby GitHuba czy StackOverflow – jako, że są to narzędzia które używa większość z nas, wydają mi się najlepiej oddawać typowo “przemysłową” stronę branży. 

Przykładowo, w TIOBE na drugim miejscu rankingu popularności jest język C, co o ile pewnie oddaje stan faktyczny, to jednak chyba nie oddaje dobrze rynku pracy (JavaScript jest tam dopiero na siódmej pozycji). Rankingi GitHuba i Stacka w pierwszej trójce mają za to Pythona, Javę i JavaScripta – i o ile kolejność miejsc na podium się między nimi różni, to myślę, że większość zgodzi się, że to właśnie one dzielą i rządzą tym, jak w 2021 wytwarza się oprogramowanie.

Aczkolwiek żeby nie było, że prawie tutaj same komunały – na zakończenie tematu popularności języków programowania mam dla Was świetnie animowane statystyki prezentujące, jak rzeczona zmieniała się przez lata. Jestem w stanie się założyć, że niejednokrotnie będziecie mocno zaskoczenii.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

Ewolucja języków programowania

Często mówi się, że sporo “nowości” w językach programowania pochodzi wprost z lat 60-tych, i w większości przypadków nie ma problemów, żeby np. prześledzić historię korutyn z do jakiegoś zapomnianego papera z czasów, gdy komputery zajmowały cały pokój. Jednak bardzo wiele z tych teoretycznych założeń potrzebowało lat, żeby znaleźć swoje zastosowanie w przemyśle. Przykładowo, ostatni boom na inwestycje w modele współbieżności (gorutyny, korutyny, Loom) spowodowany został przez zahamowanie rozwoju pojedynczych rdzeni procesora, w związku z czym społeczność musiała zabrać się za realizację istniejących pomysłów w praktyce. Sam proces ewolucji języków bardzo dobrze wyłuszczył w 2020 Roman Elizarov, świetnie znany społeczności kotlinowej. Artykuł ten obrazuje, jak zmiany w branży powodowały przez lata rozwój narzędzi, które używamy na co dzień.

Wprawdzie w samym odcinku święta wojna między programowaniem obiektowym, a funkcyjnym nie wybrzmiała zbyt mocno, ale jeśli chodzi o języki programowania jest to zdecydowanie punkt zapalny, który rozgrzewa programistów do czerwoności od zawsze, ze szczególnym naciskiem ostatniej dekady. Dlatego też dwa następne materiały związane będą właśnie z tym tematem. 

Po pierwsze – punkt widzenia programowania obiektowego bardzo dobrze podsumował w zeszłym roku esej opublikowany na blogu StackOverflow. Przedstawia on jak bardzo fakt braku ścisłej definicji czym OOP jest doprowadził zarówno do jego niezwykłego sukcesu, jak i po jakimś czasie obrócił się mocno przeciwko niemu. Skoro jednak sam twórca (no… może pierwszy istotny popularyzator) terminu “programowanie obiektowe” przez lata zmieniał swoje zdanie na to czym ono jest… to jak biedny szary programista ma się nie pogubić.

Co do programowania funkcyjnego zaś, nie wiem czy istnieje w ostatnich latach ważniejsze publikacja dla całego trendu znim związanego niż “Why Functional Programming Matters” Johna Hughesa. Oryginalnie spisane w formie akademickiego papera w latach 90-tych stało się dokumentem fundacyjnym nowoczesnego podejścia do FP. Całość w wersji papierowej jest jest trochę “przyciężkawa”, dlatego chcącym poznać myśl przewodnią Hughesa polecam nagranie jego prezentacji o tym samym tytule. 

Skąd bierze się Legacy?

W odcinku, którego oryginalnym tematem były języki programowania, zaskakująco dużo mówiliśmy o systemach legacy. Temat wracał jak bumerang, i wcale się z naszej perspektywy nie wyczerpał, dlatego chciałbym móc go trochę poszerzyć w ramach notatek.

Po pierwsze, niesamowicie polecam Paper Software Aging – tydzień temu podrzucałem poradnik jak się takowe dokumenty czyta, także akurat będziecie mogli przetestować sobie tą wiedzę w praktyce. Jest to bardzo wnikliwa, a równolegle przystępna analiza powodów, dla których nie da się w zasadzie napisać oprogramowania odpornego na starzenie się. Autorzy przyjęli bardzo szeroką perspektywę – przyglądają się powodom zarówno stricte technologicznych, jak i biznesowo-organizacyjnych.  Dodatkowym chichotem jest fakt, że całość pochodzi z 1994 roku. Pokazuje to, jak ponadczasowe są niektóre problemy z którymi się mierzymy.

Modernizacja systemów legacy jest problemem złożonym, ale też nie musimy biegać jak kurczaczki z odciętą głową. Jako branża wypracowaliśmy już sporo metod na podchodzenie do procesy wykopywania się z naszego “dziedzictwa”, a bardzo dobrą kompilacje znajdziecie np. na blogu Martina Fowlera. Jest to lektura dość długa, ale da Wam bardzo szeroki pogląd na wachlarz metod których możecie użyć jeśli staniecie przed takim wyzwaniem. 

PS: Sam też kiedyś popełniłem dość pokaźne case-study opisujące, jak takowa migracja wyglądała w jednym z projektów w którym pracowałem. Uważam, że wyszło naprawdę udanie, także zapraszam do lektury.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

Polecanki książkowe

A jak już o działaniu na zastałym kodzie mowa – to na sam koniec mam dla Was dwie polecajki książkowe, które pomogą właśnie w tym.

Pierwszą publikacją jest klasyk Working Effectively with Legacy Code. Od czasu swojej premiery w 2004 roku nie znika z list najczęściej polecanych pozycji związanych z inżynierią oprogramowania. Trudno się dziwić – książka zapewnia programistom możliwość efektywnego rozwiązywania typowych problemów ze starszym kodem, bez konieczności przechodzenia przez niezwykle kosztowne zadanie przepisywania całego istniejącego codebase. Pragmatyczne porady Michaela Fethersa pomagają znaleźć odpowiedni balans podczas czyszczenia stajni Augiasza.

Pamiętajmy jednak, że mamy problemy nie tylko z kodem legacy – nawet “nowocześnie napisane” projekty bardzo często są trudne do zrozumienia dla osoby z zewnątrz, zwłaszcza jeśli przez lata już się trochę rozrosły. W wypadku, gdy musicie szybko “rozeznać się” w odziedziczonym kodzie, nieocenioną pomocą będzie książka Software Design X-Rays autorstwa Adama Tornhila. Adam używa statystyki, aby odkryć zarówno problematyczny kod, jak i wzorce zachowań tworzących go programistów. Okazuje się, że np. tylko analizując historię zmian w kodzie (jakie pliki zmieniają się razem, a jakie w izolacji) można czasem zrozumieć zamysł oryginalnych twórców lepiej, niż osoby od długiego czasu pracujące w projekcie . Software Design X-Rays to jedna z moich ulubionych branżowych książek, po której lekturze zapewniam, że poczujecie się jakbyście nabyli nowe supermoce.