Legacy code. Jak dobrze zacząć pracę ze starym kodem. Michał Taszycki

👉 Specjalna promocja dla widzów: http://bit.ly/3YUsSvV

W dzisiejszym odcinku rozmawialiśmy z Michałem Taszyckim, Founder kursreacta.pl, o legacy code – czym jest, jak podejść do pracy z nim, a także jak można wykorzystać go jako hobby i pasję. 🙌

Dowiedzieliśmy się, że legacy code to nie tylko stara, nieużywana już baza kodu, ale także cenny zasób, który można w odpowiedni sposób wykorzystać 👌. Michał podzielił się z nami swoją wiedzą i doświadczeniem, dzięki czemu dowiedzieliśmy się, jak skutecznie pracować z legacy code, jak radzić sobie z problemami związanymi z jego utrzymaniem oraz jak można wykorzystać go, aby rozwijać swoje umiejętności i pasję do programowania.

🤖 Jeśli chcecie poznać tajniki pracy z legacy code, to ten odcinek podcastu jest dla Was! Zachęcamy do słuchania i zostawienia komentarza pod postem, aby podzielić się swoimi refleksjami i doświadczeniami w pracy z kodem.

Nikodem: Standardowa procedura, którą umieścimy na pewno pod spodem w komentarzu, do widzenia. 

W opisie! Wiedziałem, że coś jest nie tak!

Dzień dobry, cześć wszystkim, z tej strony Nikodem, witam w kolejnym podcaście DEVision. Dzisiaj w studio jest ze mną Michał Taszycki, cześć Michał! 

 

Michał: Cześć! 

 

Z Michałem będę dzisiaj rozmawiał o legacy kodzie. 

 

Tak. 

 

Zanim przejdziemy do głównego wątku tego tematu, naszą tradycją jest tak, że prosimy gości, żeby się przedstawili, opowiedzieli kilka słów o sobie, więc proszę, opowiedz coś o sobie. 

 

To tak, obecnie jestem trochę przedsiębiorcą, trochę programistą, bo jako przedsiębiorca tworzę kursy online i uczę programować w nowoczesnych technologiach, takich jak React, GraphQL, ale też uczę jak programować Commodore 64, natomiast to jest inna historia, dzisiaj skoro mówimy o legacy kodzie to może ta część mojej kariery, która jest programistyczna, to programistą jestem od około 19 lat i pracowałem w bardzo dużo różnych miejscach, od korporacji gdzie robiłem poważne aplikacje biznesowe, tam było najwięcej legacy kodu. 

 

Chcesz powiedzieć, że w innych przedsiębiorstwach się nie pracuje nad poważnym kodem?

 

Tam się robi poważne aplikacje biznesowe, a w innych miejscach się robi może mniej poważne aplikacje, niekoniecznie biznesowe, no ale różnie bywa. W każdym razie pracowałem w korporacjach, później realizowałem marzenia z dzieciństwa, pracowałem jako game developer, i tam też był legacy code tylko trochę inny, bo pracowałem w takich studiach, w których portowaliśmy gry z różnych platform na inne platformy, na przykład przenosiliśmy Saints Row 2, to był taki klon GTA z Xbox’a na peceta no i tam ten legacy code był trochę w innym stopniu legacy kodem niż w korporacjach, ale o definicjach legacy kodu może później pogadamy, bo to jest temat rzeka, później jak już doszło do mnie, że praca jako game developer jest fantastyczna, daje bardzo dużo satysfakcji, tylko ma jeden mały minus, crunch time. To jest coś, co jest nienegocjowalne, bo jak gry mają jakiś deadline, że trzeba je dostarczyć, to niestety trzeba dostarczyć je na czas, bo inaczej firma zbankrutuje albo ludzie wylecą na bruk i to oznacza to, w połączeniu z faktem, że tak jak we wszystkich innych projektach w IT, nie zawsze potrafimy oszacować, ile coś zajmie, to w grach się to łączy, z tym, że na koniec projektu, albo na koniec dostarczania różnych tam kamieni milowych, trzeba pracować dłużej, pracować po godzinach, pracować w weekendy. No jak już wyszedłem z game dev’u, to zająłem się programowaniem aplikacji mobilnych jako fullstack, wcześniej skupiony bardziej na backendzie w Ruby on Rails, który jest najpiękniejszym językiem programowania, czy w Ruby, w którym się bardzo przyjemnie programuje i Ruby on Rails, w którym bardzo fajnie się robi aplikacje backendowe, a teraz jestem skupiony bardziej na frontendzie i bardziej na ekosystemie javascriptowym, typescriptowym, Node.js-owym. I wszędzie w tych miejscach zawsze miałem styczność z legacy kodem. 

 

Wspomniałeś tutaj, kilkukrotnie padło takie hasło, sam w ogóle zapowiedziałem, że będziemy rozmawiać o legacy kodzie, więc chcielibyśmy przejść do tego i powiedziałeś tutaj, że chcielibyśmy powiedzieć definicję, czym jest legacy kod, właśnie wydaje mi się, że to jest jedno z takich zagadnień, nie wiem, na przykład jak jest różnica między testami jednostkowymi a testami integracyjnymi, co programista to gdzieś indziej postawi tą granicę, podobnie byłoby z definicją legacy kodu jakby zapytać programistę, to każdy będzie miał jakąś swoją definicję, więc chciałbym usłyszeć, jaka jest twoim zdaniem definicja legacy kodu. 

 

Ok, z legacy kodem jest tak, że wydaje mi się, że każdy z grubsza ma jakąś tam intuicyjną definicję i każdy potrafi powiedzieć, jak zobaczy kod, który jest legacy to raczej nie powie, że ten kod nie jest legacy, w tą stronę się ludzie nie mylą, w drugą stronę mogą się pomylić i teraz definicji mamy kilka, możemy wziąć sobie taką dosłowną definicję z angielskiego, że legacy kod, to jest coś, co dziedziczymy, dostajemy w spadku po kimś i teraz możemy dostać po kimś, czyli firma, w której pracujemy dostała kod po jakiejś innej firmie albo nasz zespół po jakimś innym zespole, który pracuje w tej samej firmie, albo na przykład ja zacząłem pracować nad kodem, który ktoś inny dostarczył a później robi git blame i okazuje się, że to jestem ja z przeszłości i to jest jedna z takich definicji, czyli coś, co dostaliśmy. Ktoś inny mógłby powiedzieć, że to jest stary kod, ale to jest ten problem, o którym mówię, gdzie tą kreskę postawić, czy to jest kod sprzed wczoraj, czy to sprzed miesiąca, czy sprzed dwóch lat, 10 lat, czy to może kod w innej technologii albo zwinnej jakiejś tam metodyce projektowania w Domain-Driven, albo w czymś innym budowany, może w innym języku. 

 

Słyszałem też taką opinię, że na przykład to jest test, który, przepraszam, to jest kod, który nie jest pokryty testami. 

 

Tak, to jest definicja Michaela Feathers’a z jego książki “Working Effectively with Legacy Code” i to jest taka Biblia pracy z legacy kodem, którą każdy powinien przeczytać, tam jest dużo takich sposobów, jak można zająć się tym legacy kodem, żeby to miało ręce i nogi, przykłady są w C++ bodajże i nie wiem, czy w Javie, ale jest tam dużo przełożenia na inne języki programowania. Wracając jeszcze do tego czasu, to takie ekstremum, maksymalnę opinię, którą słyszałem, to że legacy kod to jest kod, który właśnie został zapisany. Jak już napiszesz kod to on staje się legacy i tyle. Można się zgodzić, czy nie, jak myślisz? 

 

Nie, wydaje mi się, że bym się nie zgodził, jeżeli jeszcze nad danym kodem będę, w sensie to też pytanie, co znaczy, że kod został napisany, że zmergowałem, zrobiłem git merge i tyle, że już w tym momencie staje się kod legacy? Nie powiedziałbym. 

 

To jest ciekawa perspektywa, ja też czuję, że to nie jest jeszcze tak, że, jak napisze kod to już jest legacy. 

 

Dopóki wiem jak kod działa i nie muszę wczytywać się w kod, żeby wiedzieć, co tu się dzieje z tym kodem, to na pewno nie nazwałbym go legacy. 

 

Tak i tu zbliżasz się do mojej personalnej definicji, która mówi, że legacy kod to jest taki kod, który dostaliśmy od kogoś innego, to może nie jest takie ważne, bo tym kimś mogę być ja z przeszłości. 

 

Coś ty tutaj napisał?

 

Dokładnie. To jest kod, z którym z jakiegoś powodu czuję się niekomfortowo, bo na przykład napisałem go dawno temu albo dostałem go świeżo od kogoś innego, albo nie ma testów, albo nie ma dokumentacji, albo w środku czają się smoki, bo tak też może być, tam może być napisany brzydko, zwłaszcza że kiedy ktoś inny go pisał, a nie ty, to wtedy jest najgorzej. 

 

Najgorzej jest, jeżeli patrzysz, ktoś brzydko to napisał, już na niego klniesz, a później się okazuje, że to ty. 

 

Tak, ale wracając do tej definicji, ktoś, kto może być również tobą z przeszłości. No i ważniejsza rzecz, że ten kod już jest, bo kodem legacy nie może być kod, który dopiero napiszemy, ale już jest powiedzmy od jakiegokolwiek czasu, natomiast on już sobie działa, najlepiej jest zdeployowany na produkcji i dostarcza komuś jakąś wartość, użytkownicy na przykład polegają na tym kodzie, żeby korzystać z funkcjonalności aplikacji, firma, która jest posiadaczem tego kodu zarabia na nim grube pieniądze, na przykład nasza pensja jest wypłacana z jakichś pieniędzy, na które ten kawałek kodu jakoś tam zarabia, no i te dwie rzeczy, że mamy kod, z którym czujemy się niekomfortowo, mamy kod, który już działa i problem zaczyna się, kiedy musimy coś w tym kodzie zmienić. 

 

Wydaje mi się, że najważniejsze tutaj o czym nie wspominałeś, że to właśnie wymaga jakiejś zmiany, wymaga jakiegoś, nie wiem, czy to jakiejś poprawy wydajności, czy dodanie jakichś nowych funkcjonalności, bo przecież komu przeszkadzał stary kod, który istnieje i działa bez zarzutów? 

 

Nikomu nie powinien, co nie zmienia faktu, że ten kod będzie legacy kodem, bo już jest i można by się czuć niekomfortowo, kiedy do niego zasiądziesz. 

 

Kiedy na niego musisz patrzeć. 

 

Tak, no i aż cię na przykład korci żeby coś tam zmienić, bo tam czają się rzeczywiste smoki, ale póki on działa, póki on robi to, co ma robić, no to szkoda wydawać pieniądze, wydawać czas i wysiłek na to, żeby coś z nim robić no i dopiero kiedy musimy z jakiegoś powodu go ruszyć, to wtedy warto wiedzieć jak pracować z takim legacy kodem, bo na przykład w większości przypadków to nie jest tak, że możemy taki kod zostawić i on sobie żyje, może nie licząc jakiegoś tam kodu napisanego w Cobolu, na którym stoją wszystkie banki albo jakichś bardzo starych systemów w poważnych aplikacjach biznesowych w korporacjach, takie rzeczy też się zdarzają, no i ten kod sobie żyje 30 lat. Programiści, którzy znają się na danej technologii już dawno umarli na przykład. 

 

Albo zmienili pracę. 

 

Albo zmienili pracę i trzeba się nim w jakiś sposób zajmować, natomiast obecnie to ciężko jest, żeby mieć taki kod, który już sobie działa i żeby nic z nim nie robić, bo trzeba łatać jakieś dziury bezpieczeństwa, trzeba update’ować biblioteki, bo inaczej kiedy zasiądziemy do tego kodu, po na przykład miesiącu i próbujemy tam zainstalować wszystkie zależności to się nie udaje i trzeba nad tym jakoś tam panować, więc no nad kodem obecnie to raczej trzeba w większości przypadków pracować stale, stety albo niestety. 

 

Powiedziałeś tutaj kilkukrotnie, że taki legacy kod to jest kod, z którym nie czujemy się komfortowo i teraz chciałem w jakiś sposób nawiązać do definicji, o której ja wspomniałem, mianowicie o kodzie, który nie ma testów albo ma powiedzmy jakoś źle napisane testy, ale nie wiem, w jaki sposób nawiązać, bo tak myślę i w sumie to się zgodzę, gdybym dostał teraz jakiś kod, który jest powiedzmy, stary, napisany przy pomocy jakichś starszych technologii, ale nawet jeżeli byłby dobrze testowany to wydaje mi się, że dalej mógłbym się czuć w jakiś sposób niekomfortowo i dalej bym go nazwał legacy kodem. 

 

Tak, zgadzam się, zgadzam się, testy w legacy kodzie są bardzo ważne. Jeśli one już są, to jak dla mnie to dalej może być legacy kod, natomiast to znaczy, że ktoś za nas już odwalił trochę pracy, którą i tak byśmy musieli prawdopodobnie zrobić, jeśli chcielibyśmy efektywnie pracować z takim kodem legacy. 

 

No tutaj też nie chciałbym, znaczy chciałbym właśnie zaznaczyć, że w sumie to jakbym miał wybrać czy mam dostać legacy kod bez testów i z testami to na pewno bym się zgodził na ten z testami. 

 

No tak, byłoby troszkę mniej roboty na początku, ale trzeba chyba poruszyć jeden temat, że skąd się bierze lęk taki w stosunku do legacy kodu. 

 

Pewnie stąd, że zmienię coś i coś zepsuję, to jest takie chyba najbardziej. 

 

Tak, wydaje mi się, że tak jest, bo to, co zauważyłem, że większość programistów, czy programistek, które mają właśnie jakieś takie obawy przed legacy kodem, to są zwykle ludzie mniej doświadczeni, zwykle bardziej początkujący i zwykle ludzie, którzy mają jeszcze jakieś tam doświadczenie i zjedli na kodzie zęby, to tego kodu się trochę mniej boją. Wydaje mi się, że to też się bierze stąd, że fajniej jest chyba pracować nad czymś od zera. No bo zwłaszcza początkujący mają takie wydaje mi się podejście albo częstsze jest takie podejście wśród początkujących, że fajnie by było, gdybym miał tyle możliwości, że mógłbym nową, świeżą aplikację zrobić z jakimiś moimi bibliotekami, moim podejściem i tak dalej, bo programowanie to jest bardzo kreatywna działka, robimy coś od zera, przelewamy myśli na słowa, komputer te słowa przerabia w elektrony powiedzmy i coś się dzieje, więc jest to bardzo kreatywne i tym bardziej jest kreatywne im mamy więcej do zrobienia i w tym legacy kodzie tej kreatywności jest trochę mniej, a przynajmniej jest ona trochę inna, natomiast legacy kod ma dużo zalet moim zdaniem, bo jak zaczynamy pracować od zera to nie mamy ograniczeń żadnych, jak ktoś próbował jakiegoś kreatywnego zajęcia kiedyś, napisać jakiegoś blog posta albo, nie wiem, książkę, albo narysować coś, no to zwykle jest taki problem, mamy białą kartkę, jak tu zacząć, co zrobić, tyle możliwości, ciężko którąś wybrać i trzeba sobie samemu nadawać jakieś ograniczenia. Legacy kod takie ograniczenia nadaje, bo mamy jakieś funkcjonalności, których pod żadnym pozorem nie możemy zepsuć i jeśli chcemy coś tam dodać, to musimy się najpierw upewnić, że jednak będziemy mieli ten komfort, że coś nas przed tym będzie chronić no i tutaj wchodzą testy całe na biało. 

 

Właśnie chciałem już przejść do tego powiedzmy procesu, jak wygląda praca nad takim legacy kodem. Jak może wyglądać w ogóle takie zadanie, powiedzmy, że przychodzi do ciebie twój przełożony, ci oznajmia, że potrzebujemy ten stary kod jakoś przerobić albo dopisać funkcjonalność do starego kodu, do legacy kodu.

 

To pierwszy odruch: Panie, to się nie da. 

 

To jest standardowe chyba, trzeba usiąść i policzyć czy zyski będą większe niż koszta, to tak, ale załóżmy, że są. 

 

Tak, później przechodzisz przez te 5 stadiów, tam ten gniew, niedowierzanie, jak już się pogodzisz z tym, że musisz wejść do tego kodu, zwalczyć te smoki, to takim najprostszym algorytmem pracy z legacy kodem, to jest pierwsza rzecz, zabezpieczyć się przed przypadkowymi zmianami tego kodu, czyli w jakiś sposób chronić istniejącą funkcjonalność, więc najprościej, jak to zrobić, to zrobić dużą liczbę testów automatycznych, no i teraz czy to będą testy jednostkowe, czy to będą testy integracyjne, czy to będą testy end-to-end, to jest rzecz drugorzędna. To zależy od tego, jaki kawałek legacy kodu uda nam się wydzielić najmniejszy, żebyśmy mogli zacząć pracować i dostarczyć tę funkcjonalność. Bo jak wydzielimy funkcję legacy, to testy jednostkowe wystarczą, jak jakiś moduł, który jest powiązany z innymi modułami, to jakieś testy integracyjne, które coś tam sprawdzą, no a jak w środku czają się rzeczywiście smoki, węże i wszystko jest ze sobą powiązane, to trzeba jednak test end-to-end zrobić, ale to, co jest fajne w kodzie legacy, którego nie ma w innych kodach, które są świeżutkie, to jest to, że kod legacy już istnieje, już działa na produkcji, już zarabia pieniądze, więc ta funkcjonalność już tam jest, nawet jak nie ma testów, nawet jak nie ma dokumentacji, to zachowanie tego kodu jest zapisane w kodzie, więc musimy je tylko wyłuskać stamtąd, najprostszą metodą, najprostszą, ale nie najłatwiejszą, jest zastosowanie techniki zwanej smoke test, czyli testy dymienia, nomenklatura się z elektroniki wzięła, jako taki szybki test, który potrafi sprawdzić jakiegoś elektronicznego dynksa, czy on będzie działał, podłączasz go do prądu, jak dymi to nie działa. Natomiast w informatyce to jako smoke testy to się mówi NAS testy, w których traktujemy kod jako czarną skrzynkę, nie patrzymy do środka, nie musimy rozumieć jak działa, tylko dajemy jakieś dane wejściowe, czyli argumenty funkcji i nagrywamy dane wyjściowe, czyli funkcja wypluła taki string z takimi danymi, więc ten string ląduje w unit teście, jak to będą testy integracyjne albo end-to-end, to musimy jakiś snapshot albo modułów, albo jakieś rzeczy, które wpływają do tych modułów z naszego modułu, który testujemy albo zrobić jakiś snapshot całej aplikacji, te testy będą działały wolniej, ale cóż, pracujemy z tym, co mamy, nie zastanawiamy się, generujemy tych testów najwięcej jak się da, tak, żeby dążyć do tego, żeby pokryć, mieć stuprocentowe pokrycie kodu testami, i to też zależy jak bardzo ta część kodu legacy jest ważna, jak to jest jakaś bramka płatności, jak wywalimy to funkcja zacznie tracić miliony z każdą godziną to lepiej, żeby te testy były jak najgęstsze, natomiast jak to jest jakaś prosta funkcjonalność, to możemy przymrużyć oko i uznać, że czujemy się pewnie z mniejszym pokryciem, natomiast w tych takich bardziej krytycznych rzeczach no to stuprocentowe pokrycie to jest jakiś tam pierwszy krok, kolejnym krokiem może być puszczanie jakiejś maszynki do generowania testów mutacyjnych, w dużym skrócie to polega na tym, że ten kod, który testujemy zostaje poddany mutacjom, czyli gdy w kodzie na przykład występuje jakaś liczba 50, to to narzędzie zmienia, generuje nowe wersje tego kodu z minus 50, zerem, z miliardem, z minus miliardem i różnymi takimi rzeczami, z nullem, stringiem i tak dalej i w różnych takich miejscach kodu na przykład dodaję if’y, usuwa if’y, generuje jakieś warunki brzegowe w pętlach for tak, żeby ten kod zmutował, był inny no i odpala testy na tym i teraz jak twoje testy nadal przechodzą na tym złym kodzie, to mutant żyje, jak testy się wywalają, to mutant ginie i twoim zadaniem jest teraz zabić wszystkie mutanty, jak to zrobisz to masz dużo większą pewność, że masz pokrycie nie tylko tam linijek kodu, nie tylko jakichś tam instrukcji, ale rzeczywiście, że twój kod sprawdza takie ważne, istotne rzeczy, które mogą się wywalić w tym kodzie w trakcie, kiedy ty będziesz już na nim później pracował, no i to jest ten pierwszy krok, robimy smoke testy, generujemy ich bardzo dużo, nie wiemy nadal co ten kod robi, ale już wiemy, że jak testy będą przechodzić to zachowanie kodu się nie zmieni. No i teraz możemy zakasać rękawy i zająć się tą kreatywną częścią. 

 

W końcu zabieramy się za robotę, przecież szef nie płaci za metodę prób i błędów. 

 

No tak, ale metoda prób i błędów to jeszcze jest, jeszcze przed nami, bo teraz jak już mamy te testy, testy nas chronią. 

 

Można już bezpieczniej wejść w kod i można faktycznie zacząć się z nim bawić, bo jeżeli zepsujemy coś, zmienimy coś, czego nie powinniśmy tykać, to nasze testy to wyłapią. 

 

Dokładnie. 

 

Trochę bezpieczniejsze takie podejście do tematu. 

 

Tak no i teraz w zależności od tego, nad czym pracujemy to możemy się bawić, możemy zrobić tak zwany research and development, czyli robić jakieś spike’i, które nam sprawdzą, czy tą funkcjonalność, którą chcemy dostarczyć, powinniśmy zrobić ruszając tą część kodu, czy tamtą, czy w taki sposób, czy w inny sposób i tutaj przychodzi taka inna technika zwana mikado method, czyli po polsku gra w bierki. Polega to na tym, że zaczynasz, wchodzisz w ten kod jak czołg i próbujesz dostarczyć tę funkcjonalność po prostu, to, co ci przyjdzie do głowy robisz, modyfikujesz, zmieniasz i tak dalej, no i napotykasz różne rzeczy, na przykład błąd kompilacji, napotykasz jakieś zależności, czegoś brakuje, czegoś nie brakuje i zapisujesz sobie te rzeczy na kartce jako takie kroki cofasz te zmiany i próbujesz uwzględnić te rzeczy, które masz zapisane na kartce, idziesz sobie takim ciągiem i buduje ci się taki graf zależności, rzeczy, które musisz zmienić w kodzie, czyli zrobić jakiś refactoring, żeby móc dopiero dostarczyć tę funkcjonalność. No i to jest to jakieś narzędzie pracy z tym kodem, jak to są proste rzeczy, które musimy zmodyfikować, można pójść na żywioł, jak to są bardzo skomplikowane rzeczy to jednak warto mieć jakiś system pracy z takim kodem no i ta mikado method, czyli ta gra w bierki, czyli wyciągasz jedną bierkę i patrzysz czy się rozsypują rzeczy, jak się rozsypią, to nie, cofasz i próbujesz jeszcze raz. 

 

Szkoda, że w bierki nie było takiej opcji, jakby się rozwaliło to cofam i jeszcze jeden ruch wykonuję. 

 

Albo na przykład robisz pair programming no i jak twoja bierka rozwali wszystko to druga osoba ma swój ruch i próbuje inną gierkę wyciągnąć i cały czas zapisujecie te wszystkie rzeczy, które się dzieją na kartce no i później robi się taka rzeczywiście prosta droga do celu, to jest takie, idziesz kawałek, cofasz się, idziesz kawałek, cofasz się, idziesz kawałek, cofasz się i w końcu dochodzisz do takiego ciągu, szeregu kroków, które możesz zrobić, żeby rzeczywiście dostarczyć tę funkcjonalność. A no i zapomniałem o najważniejszej rzeczy, no mamy te smoke testy, ale jak dostarczamy nową funkcjonalność to trzeba jeszcze testy, które sprawdzą tą funkcjonalność dostarczyć no i dobrze to zrobić test-driven development, czyli najpierw napisać testy, tak, żeby one wymusiły tę implementację, i to też nam tak pozwala jasno sprecyzować, co będziemy robić, także później, jeśli już dostarczymy tę funkcjonalność, to mamy jasne potwierdzenie, że te testy, które były na czerwono nagle zaczynają przechodzić no i na koniec dostajemy właśnie całą tą serię testów, tych smoke testów, które nam broniły starą funkcjonalność oraz nowe testy, które bronią tej nowej funkcjonalności i tu może pojawić się pewien inny problem, że to nowa funkcjonalność może stać w sprzeczności z poprzednim zachowaniem programu, czyli część testów, tych smoke testów, które broniły starego zachowania zaczną nam failować, co wtedy? 

 

Wtedy pytanie, jak bardzo stoją w sprzeczności do siebie te dwa testy, wydaje mi się, że ja zacząłbym od notyfikacji starych testów, w sensie no, jeżeli stare zaczęły failować to chyba dobrze, bo zmieniliśmy funkcjonalność, której miały bronić. 

 

Może dobrze, może nie, to jest, jeśli my możemy podjąć tę decyzję to spokojnie możemy tak zrobić, jak powiedziałeś, natomiast są takie problemy, jak dostaliśmy projekt od jakiejś w ogóle innej firmy i tak dalej, albo pracujemy w jakiejś domenie, o której nie mamy zielonego pojęcia. 

 

Dobra, może być faktycznie problematyczne, bo jeszcze nie wiadomo, kto korzysta z naszych efektów i kto korzysta z tej funkcjonalności, mogło być tak, że okazuje się, że oni wcale się nie zgodzili na zmianę funkcjonalności i dalej potrzebują, żeby działało po staremu. 

 

Tak, wiesz, to może być taki problem, o którym kiedyś czytałem, że ktoś usprawnił działanie programu, żeby nie zużywał tyle procesora i jakiś użytkownik zgłosił buga, bo miał jakiś skrypt, który wykrywał większą temperaturę procesora, który coś mu uruchamiał i zależał od tej jakiejś z funkcjonalności, która była zupełnie niepotrzebna temu programowi, więc nie zawsze można zakładać, że użytkownicy będą zadowoleni ze zmian, kiedy naprawisz im jakiś błąd, bo może ich oprogramowanie, które zależy od tego oprogramowania, zależy od tego błędu albo na przykład to, co my uznajemy za błąd się okaże jakieś nieprawidłowe, no i dobry przykład, nie wiem, robimy program do księgowości, generujemy jakieś faktury i trzeba naliczyć jakieś właściwe stawki VAT dla odpowiednich produktów i dla odpowiednich rodzajów działalności, to można się pomylić, po to zatrudniamy księgowych, żeby oni wiedzieli takie rzeczy, żeby panowali nad tym, co się zmienia w prawie, więc warto wtedy pójść z listą takich testów, które przechodzą, które się wywalają i pójść do takiego product ownera, w tym przypadku księgowego i spytać czy tutaj ma być 8% w takim przypadku, czy tutaj ma być 23, no i księgowy mówi “No tu tak, tu tak, tu to w sumie obojętne, a tego nie powinno być, a to w ogóle nie wiedziałem, że ten program to robi, ciekawostka”. I to ci już mówi, które testy możesz totalnie wywalić, które możesz zastąpić tymi nowymi, a które na pewno muszą zostać. No i jak już uda nam się dostarczyć tę funkcjonalność, wszystkie testy przechodzą, jesteśmy na zielono, to możemy przejść do standardowego kroku: test-driven development, refactoring, czyli staramy się upiększyć ten kod tak, żeby osoba, która odziedziczy go po nas trochę mniej na niego klęła, żeby miała trochę łatwiej. 

 

Albo my z przyszłości. 

 

Tak, dostarczać nowe funkcjonalności i ważna część tego refactoringu w legacy kodzie to jest refactoring tych testów, które były nam potrzebne, żeby zacząć pracę. No bo te smoke testy, to są idealnie takie testy do wyrzucenia, bo one rzeczywiście bronią nam tego kodu, ale nic się z tego nie dowiemy, dowiemy się, że jak takie dane będą, to takie dane wyjściowe się zdarzą, takie jakieś eventy w naszej aplikacji polecą i różne takie rzeczy, no i warto popracować trochę nad tymi testami i spróbować wyciągnąć jakieś sensowniejsze testy, które są ładnie opisane, zrobić jakieś unit testy, jakieś testy integracyjne, jakieś testy end-t-end, które będą bardziej opisowe, bo testy, które tylko nam bronią jakiejś aplikacji przed działaniem, to jest pół sukcesu, dobrze by było, jakby te testy po odpaleniu się, raz przeszły, a dwa, żeby te napisy, które są zielone, to żeby były zgodne z rzeczywistością, bo my pracując nad tym projektem, tym legacy kodem, poznajemy to, co ten kod rzeczywiście robi w trakcie pracy nad nim, no to warto tę wiedzę zapisać w jakimś sensownym miejscu, więc albo w dokumentacji, która często się przedawnia, albo lepiej w żywej dokumentacji, czyli w tej całej, w tym całym szeregu testów, który mamy i który już wiemy, że jeśli opisy się będą zgadzać, testy będą przechodzić, to ta dokumentacja będzie opisywać rzeczywistość. 

 

Właśnie tutaj poruszyłeś super kwestię, mianowicie dokumentacja, tak jak mówisz, bardzo często dokumentacja się przedawnia, bardzo często jest niespójna z tym, co faktycznie się dzieje w naszej aplikacji albo jeszcze gorzej może być tak, że w ogóle dokumentacji nie ma. 

 

Czy to jest gorzej? 

 

Właśnie się zastanawiam. 

 

W legacy kodzie często właśnie niekoniecznie jest gorzej, czyli w sumie w każdym kodzie niekoniecznie jest gorzej, ja osobiście mam zdanie takie, że jak dokumentacja istnieje to dobrze by było, żeby ta dokumentacja była jednak mocno zintegrowana z testami, bo wtedy mamy potwierdzenie, że ta dokumentacja jest zgodna z rzeczywistością bo jeśli nie mamy takiej kultury pracy w zespole, że jakaś część naszego czasu jest poświęcona na pisanie tej dokumentacji i rzeczywiście wszyscy o to dbają, no to wtedy bardzo szybko ta dokumentacja się przedawnia i można spotkać też na przykład komentarze w kodzie: Napraw mnie w czwartek. Czwartek był 10 lat temu. 

 

No tak, niestety zdarza się tak, że w kodzie pojawia się właśnie jakieś to-do, które jest już przestarzałe albo w ogóle nie ma prawa bytu. Niestety masz tutaj rację. 

 

Komentarz: pod żadnym pozorem nie deployować na produkcję. 

 

Takiego jeszcze nie widziałem, ale zdarzają się inne różne takie śmieszki, natomiast zastanawiałem się nad samymi testami, o których tutaj wspomniałeś, że one też powinny odzwierciedlać jak najbardziej to, co się dzieje w kodzie i te opisy, które są przy testach też powinny być aktualne. Pytanie, jak często się zdarza coś takiego, że trafiasz na testy, które może i przechodzą, może faktycznie bronią jakiejś funkcjonalności, ale są już niezgodne z opisem, bo ktoś na przykład zmienił kod, testy przestały przechodzić, poszedł, poprawił testy, ale kompletnie nie zmienił opisu.

 

No to dużo zależy od kultury pracy w danej firmie, ale też w danym języku programowania, to zauważyłem, czy w danej technologii, bo na przykład jak pracujesz w Ruby, konkretnie powiedzmy w Ruby on Rails albo w jakichś tam zbliżonych technologiach do tego, no to tam kultura pisania testów jest bardzo, bardzo wysoka i ma duże tradycje i tam jak kilka lat temu pracowałem w Ruby on Rails, to z kim nie gadałeś na konferencji, to ludziom do głowy by nie przyszło, że można pisać kod bez testów. I to było takie naturalne, piszesz kod, piszesz testy, tylko jedyne pytanie było, czy robisz test-driven development, czy testy piszesz po fakcie. Z testami, opisami tych testów jest podobnie jak z nazwami funkcji, i wiemy, że funkcji klas i wszystkich innych rzeczy no i wiemy, że to jest jeden z dwóch najtrudniejszych problemów w informatyce, czyli nazewnictwo, dwa: inwalidacja cashu i problemy off-by-one. 

 

Zastanawiam się ile ostatnio czasu spędziłem nad wymyślaniem poprawnych nazw zmiennych, zdecydowanie za długo mi zeszło. 

 

Ja nad tym spędzam dużo czasu, jedna z najczęstszych rzeczy, które robię dla kursantów w trakcie jakiegoś tam code review to jest zwracanie uwagi na nazwy, bo dobre nazewnictwo może oszczędzić dużo czasu nie tylko tobie, ale wszystkim innym, którzy czytają kod, bo kod się pisze szybko, a czyta się go wielokrotnie, znaczy pisze się go często raz, a czyta się go wielokrotnie i więcej czasu się spędza nad zrozumieniem go i to nie tylko ja go zrozumiem, nawet tam po miesiącu tylko każdy, kto się zetknie z tym kodem musi spędzić jakiś czas na na rozumieniu tego kodu, jak dbasz o dobre nazewnictwo, raz, że piszesz testy, które są zgodne z rzeczywistością, to fajnie, bo masz unit testy, które ci opisują co ta dana funkcja robi, masz dobrze nazwaną funkcję, nazwa się zgadza z unit testami, to nie musisz nawet zaglądać do środka, ale jak funkcja nazywa się w jakiś sposób, na przykład “do something” albo powiedzmy fetch list of users i zwraca bulla to się zastanawiasz, w jaki sposób ona ściąga tych użytkowników i gdzie oni są zapisywani, co jeszcze się dzieje, to od razu ci nasuwa na myśl, że o, w środku pewnie będą jakieś mocne efekty uboczne, funkcja zrobi jakieś dziwne rzeczy, a gdzieś tam się może zapiszą użytkownicy, patrzysz do środka, ona wcale tego nie robi tylko sprawdza, czy na przykład można sfetchować tych użytkowników. 

 

Rozmawiamy tutaj już od jakiegoś czasu o legacy kodzie i tak powiem, jakbym nigdy wcześniej nie był programistą, raczej byś mnie nie zachęcił tym opisem i nie chciałbym raczej wchodzić w legacy code, dlatego jakbyś z twojej perspektywy, dlaczego twoim zdaniem warto pracować z legacy kodem?

 

No tak, prędzej czy później w naszych karierach, kiedyś będziemy musieli zmierzyć się ze smokami i nie będzie testów, nie będzie niczego, no dochodzimy do tego, że praca z legacy kodem i umiejętność pracy z legacy kodem to jest taka bardzo ważna umiejętność, bo kiedyś się z tym zetkniemy w mniejszym lub większym stopniu i to, jak bardzo czujemy się z tym komfortowo, tym łatwiej się będzie nam z tym pracować. No bo tak, czasem się zdarzą projekty, że będziemy mogli sami od zera coś zrobić, będzie super fajnie, super kreatywnie do czasu, aż nie dostarczymy pewnej dużej ilości funkcjonalności i trzeba będzie dodawać kolejnych i nagle nasz piękny kod stanie się legacy. Więc to nie jest może coś takiego, co bardzo przyciąga, co jest takie super fajne, może nie dla wszystkich, nie każdemu może się to podobać, natomiast jeśli chce się być profesjonalnym programistą, profesjonalną programistką, to trzeba umieć pracować z takim kodem i warto jest nauczyć się znajdować przyjemność w pracy z takim kodem. No i można potraktować te wszystkie etapy, ten etap ubezpieczania tego kodu, znajdowania różnych, budowania tych testów to może być coś fajnego, bo to jest teoretycznie jakaś mechaniczna rzecz, którą robimy, zwłaszcza jeśli to są, robimy smoke testy jednostkowe dla jakiejś tam funkcji i tak dalej, którą wiemy, jak zrobić, ale na przykład programuje w React i jesteśmy w wersji 16, kod jest napisany w komponentach klasowych, trzeba je przerobić na funkcyjne, to nie zawsze jest proste i teraz przetestowanie takich komponentów na frontendzie również nie zawsze jest proste. Niektóre można przetestować jednostkowo, niektóre trzeba zrobić w otoczeniu jakichś komponentów, coś tam zmokować, a niektóre trzeba odpalić na jakimś Cypress’ie no i przetestować jako end-to-end, więc tu jest dużo wyzwań, które są ciekawe, więc znalezienie takiego sposobu, żeby dobrze to testować, jak najmniej czasu na tym stracić, czyli zrobić, a się nie narobić, to jest właśnie fajna rzecz w tym legacy kodzie, bo nie musimy, to jest takie odstępstwo od reguły, że musimy pisać ładne testy, nie, smoke testy jak najtańsze, jak najprostsze w React, to większość osób teraz korzysta z Jest, to jest taki framework do testowania w Javascripcie i Typescripcie, no i Jest ma snapshoty, więc nie musimy sobie sami generować tych, na przykład to, co wygeneruje nasza funkcja, nie musimy tego stringa przeklejać do testu i się tym bawić tylko robimy snapshota na przykład tego, co wyrenderuje nasz komponent, nagrywamy go, commitujemy go i testy już za drugim razem, za pierwszym razem generują snapshota, a za drugim razem już przechodzą pod warunkiem, że kod się nie zmieni, to jest ta część, która może być trochę mechaniczna, trochę kreatywna, bo musimy znaleźć sposób na otestowanie tego, no i później zaczyna się ta naprawdę ekscytująca i fajna część, mamy przygodę i musimy zmierzyć się ze smokiem i to jest taki archetyp historii, że to jest droga bohatera, musimy przejść przez lochy, znaleźć smoka, pokonać go i wtedy dostajemy nagrodę, ale mamy taki plus, że już w tym momencie zbudowaliśmy sobie zbroję, która nas chroni i mamy odpowiednią broń i teraz musimy znaleźć sposób na zgładzenie tego smoka albo ujarzmienie go, czyli znaleźć sposób, żeby tak zrefactorować ten kod, żeby wprowadzenie tych zmian, które mamy zrobić było jak najprostsze. 

 

Jeszcze trzecią opcję, przepraszam, że przerywam, ale można by się tak zakraść pod smoka, żeby mu wykraść skarb, a go nie ruszać. 

 

Tak, to prawda. 

 

Tak myślę, że to jest takie dobre, bo czasami jednak ja, jak pracując z legacy kodem zdarzało mi się tak, że jednak wolałem unikać wszystkich pułapek, wszystkiego, dojść tylko do celu, wziąć to, co miałem wziąć i więcej tutaj nie maczać palców. 

 

Tak, to jest dobre, jeśli możemy tak zrobić, to omijamy ten problem, bo nie pracujemy z tym legacy kodem, ale jest to jedna z technik pracy w ogóle z jakimś tam starym kodem, czyli zamiatanie pod dywan i to nie jest zła technika, bo czasem po prostu musimy coś zrobić, nie mamy czasu, żeby zagłębić się w jakąś tam funkcję, która ma 5 ekranów długości, która coś tam robi, my musimy dodać jakąś tam jedną małą rzecz, to jednym z takich sensownych rozwiązań jest zapakowanie całej reszty tego, czego nie musimy dotykać w worek, czyli inaczej mówiąc ekstract method, taki refactoring, pakujemy to w worek, zamiatamy pod dywan i zajmiemy się tym kiedy indziej i ogólnie taka strategia zajmowania się rzeczami kiedy indziej w przyszłości jest najlepszą strategią pracy z legacy kodem pod warunkiem, że mamy tę dyscyplinę, że rzeczywiście będziemy kiedyś po sobie sprzątać. Jeśli rzeczywiście trzymamy się tej zasady skauta, że zostajemy, nasz kod, znaczy inaczej, zostawiamy nasz kod w lepszej postaci niż go zastaliśmy, to takim optymalnym rozwiązaniem jest zmienianie rzeczy i refakturyzacja rzeczy najpóźniej jak tylko się da, bo im wcześniej to robimy, tym mamy mniej informacji o kodzie, mamy mniej doświadczenia z tym kodem i możemy się zapędzić trochę w kozi róg, bo zrobimy jakiś refactoring a później się okaże, że jednak poszliśmy w trochę złą stronę i musimy cofać te zmiany i zmieniać kod dwa razy. 

 

Gorzej jest w sytuacji, kiedy nie trzymamy się dyscypliny, kiedy nad jednym projektem pracuje kilka osób jednocześnie i kilka osób zrobiło to samo i za każdym razem, jeżeli będziemy dokładać po prostu tą cegiełkę, gdzie opakowujemy problem w worek, to nagle tych worków nam się tyle narobi, że trzeba worki wpakować w kolejny worek albo w końcu już zakasać rękawy i usiąść do problemu i go rozwiązać raz a porządnie. 

 

Tak, ale to jest właśnie ta kwestia tej dyscypliny, że siadamy do kodu i zanim dostarczymy tą funkcjonalność to zmieniamy go w taki sposób, że dostarczenie tej funkcjonalności będzie proste, czyli robimy ten refactoring wcześniej i też staramy się troszkę bardziej upiększyć kod, więc jak znajdziemy coś, co się powtarza, coś, co było zrobione na przykład podwójnie niepotrzebnie, albo nie wiem, ktoś bardzo źle nazwał jakąś funkcję, to naprawmy to, bo to jest też opinia, którą się dowiedziałem, że jest kontrowersyjna, że ja uważam, że to nie jest, że nasz pracodawca powinien się totalnie nie interesować tym, czy my refactorujemy czy nie, czy my piszemy testy, czy nie, bo to jest nasz obowiązek, żebyśmy to robili. 

 

Poruszaliśmy tutaj kilka różnych definicji legacy kodu, a co myślisz o takim stwierdzeniu, że każdy stary kod to jest legacy code? 

 

Tutaj muszę się bardzo nie zgodzić, z racji tego, że takim starym kodem zajmuję się też poniekąd zawodowo i hobbystycznie. Otóż ja sobie taki komputer Commodore 64, nie wiem, czy słuchacze widzowie znają taki komputer, jak nie, to zajrzyjcie na swój strych, jest duża szansa, że taki tam leży i to jest komputer, który w zeszłym roku obchodził 40-letnie urodziny, jest to komputer o niesamowitych możliwościach, bo jeśli spojrzeć na to, co on potrafi to tak: ma 64 kb RAM-u, aż 8 bitmap, które mogą się jednocześnie poruszać na ekranie, one są wspomagane sprzętowo, 16 kolorów i 1 MHz ma procesor, czyli jest jakoś 1000 razy wolniejszy niż pierwszy iPhone, ale jest bardzo ciekawy fakt, kilka bardzo ciekawych faktów o Commodore 64, po pierwsze: jest w księdze Rekordów Guinnessa jako najlepiej sprzedający się komputer na świecie, model komputera na świecie, chyba iPad go przegonił, jeśli iPada uznajemy za komputer i wszelkie inne pecety, jeśli myślimy o wszystkich możliwych konfiguracjach pecetów, to oczywiście jest ich więcej, ale model komputera, który jest ustalony i sprzedawany to Commodore 64 nadal jest na topie, miał rozdzielczość 320 na 200, czyli to jest mniej niż jedna ikona na i’Phonie nowym, piksele były grube i fajne i jest bardzo ciekawy fakt dotyczący tego komputera, że nie wiem, czy spotkałeś się z taką rzeczą, że od czasu do czasu musisz upgrade’ować swój system operacyjny albo upgrade’ować, kupić sobie nowy telefon, bo aplikacja działają coraz wolniej. Standardowo, przy każdej aktualizacji. Na przykład taki Photoshop z każdą tam aktualizacją uruchamiał się coraz wolniej no i jakieś takie dziwne rzeczy się dzieją i jeśli chodzi o Commodore 64 to jedna z ciekawych rzeczy jest taka, że cały czas powstają na niego nowe programy, tak średnio około 50 nowych gier, takich porządnych gier z wyższej półki powstaje na Commodore 64 co roku, jakieś 40 dem, czyli takich teledysków powstaje narobionych przez zapaleńców w ciągu roku, jakby liczyć wszelkie grafiki, muzyczki, inne takie rzeczy, no to liczy się to w tysiącach rocznie, tyle rzeczy powstaje na ten komputer, mimo że nie jest produkowany od 94 roku i te wszystkie aplikacje są coraz ładniejsze i coraz szybsze, jak to się dzieje, specyfikacja tego sprzętu się nie zmienia, ale ludzie odkrywają coraz to nowe możliwości, coraz to nowe błędy sprzętowe, które można wykorzystać w taki sposób, że te błędy stają się feature’ami. To są te błędy, o których wspominałeś wcześniej, nie wolno ich usuwać, bo przeszkodzą nam. Tak, to, co jest fajne, że teraz mamy bardzo dużo możliwości, żeby programować ten komputer, kiedy ja zaczynałem to byłem dzieckiem i pierwszy program, który napisałem, to dużo osób, które miało Commodore 64 rozpozna, to było 10 Print Commodore 64 20 go to 10. To był program napisany w Basic, który jest dostępny na Commodore, zaraz po włączeniu tego komputera możesz zacząć to pisać, uruchomić i działa. No i jak zobaczyłem, że tekst się drukuje cały czas w nieskończonej pętli to się wciągnąłem i to później przyszły jakieś tam inne programy przepisywane z czasopism, ale nigdy nie miałem możliwości programowania w assemblerze, bo nie było żadnych książek w moim mieście dostępnych, bo Commodore już przestawał być produkowany, sprzedawany w bibliotece, też żadnych książek nie miałem, Internetu nie miałem wtedy jeszcze, więc skąd tu czerpać wiedzę, moi znajomi nie programowali, zwłaszcza nie na Commodore 64, co najwyżej grali, nie miałem dostępu do demo sceny, wiedziałem, że jakieś fajne produkcj są tworzone, wiedziałem też, że w assemblerze, ale jak się tego assemblera nauczyć. Mogłem sobie telegazetę włączyć co najwyżej, pozdro dla ludzi, którzy wiedzą co to jest telegazeta teraz i przeczytać jakiś artykuł o programowaniu i to było wszystko. I dopiero parę lat temu, w 2014 roku stwierdziłem, że może spróbuję i co się okazało, że mamy bardzo dużo fajnych narzędzi, które umożliwiają programowanie na Commodore 64, bo mamy kompilatory assemblera do kodu maszynowego, mamy emulatory, czyli takie programy, które udają, że są tymi komputerami, działające na wszystkich platformach i co ważne to emulatory umożliwiają nie dość, że symulowanie tego działania prawidłowego komputera, ale też tych wszystkich błędów, które tam istnieją, więc rzeczywiście można na tym programować nie mając tej maszyny i co się okazało, że programowanie w assemblerze, który jest prostym assemblerem na prostym ośmiobitowym komputerze, mam mało instrukcji, jest przyjemne i jest bardzo dobrą odskocznią od takiej pięknej architektury oprogramowania, którą robimy na co dzień, programowania obiektowego, programowania funkcyjnego, a tutaj nie, mamy programować niskopoziomowo, mamy coś pokazać na ekranie, nie mamy nawet mnożenia, musimy jakiś algorytm zrobić z dodawania, odejmowania, przesuwania bitów, żeby to zadziałało, musimy robić jakieś optymalizacje różne dziwne i to jest z takich hobby komputerowych, to jest najlepsza odskocznia, jaką miałem od takiego normalnego programowania i stwierdziłem, że też zacznę uczyć ludzi jak to robić, więc kiedy miałem to na świeżo, bo dopiero co nauczyłem się jakiejś tam techniki, to zacząłem nagrywać takie krótkie lekcje, które mają 5-10, może 15 minut max i uczą cię jednej małej rzeczy, na przykład jak wyświetlić sprite na ekranie. Sprite to jest ta ruchoma bitmapa wspomagana sprzętowo albo jak zagrać sobie jakąś nutę na Commodore, albo jak otworzyć ramkę, czyli poszerzyć rozdzielczość ekranu z 320 pikseli na jakieś tam powiedzmy 400 ileś i różne takie rzeczy się dowiadywałem, nagrywałem o tym lekcje, dodawałem do tego kod źródłowy i założenie było takie, żeby dla ludzi, którzy nie mają czasu, którzy też w dzieciństwie chcieli się tego nauczyć, teraz moją rodzinę, teraz mają obowiązki, nie mają czasu, żeby siedzieć długie godziny nad starymi książkami, tylko żeby sobie obejrzeli 5 minut i żeby mieli takie objawienie “Aha, to tak się otwiera ramkę, aha to tak się wyświetla 64 sprity zamiast 8, tak się robi te triki i zacząłem wydawać takie lekcje i co się okazało, że są ludzie, którzy są tym zainteresowani, czekali tylko na to, żeby mieć takiego powiedzmy Netflixa do Commodore, żeby obejrzeć sobie parę takich lekcji, nauczyć się jak to programować, to był właśnie taki mój pierwszy krok w stronę jakiejś tam przedsiębiorczości, żeby zrobić sobie coś oprócz programowania. 

 

Muszę przyznać, że bardzo ciekawa rozmowa, bardzo mi się podobała. 

 

Dziękuję, cała przyjemność po mojej stronie. 

 

Ogólnie ten sprzęt, przepraszam, ten temat dotyczący programowania na Commodore był dla mnie niezwykle interesujący, bo pamiętam jak za dzieciaka zawsze się interesowałem tym, jak to wszystko działa pod spodem i mieliśmy też jakieś starsze sprzęty w domu, gdybym chciał się dowiedzieć czegoś więcej, mogę cię jakoś znaleźć gdzieś w Internecie? 

 

Tak, na wszystkich mediach społecznościowych, GitHub i tak dalej jestem jako Michał T, pisze się mehowte geneza jest taka, że kiedyś próbowałem nauczyć ludzi mówiących tylko po angielsku, jak wymówić moje imię, to jest najprostszy sposób Michał T, więc jeśli ktoś chce ze mną pogadać to najprościej tak, natomiast jak ktoś chce się nauczyć czegoś o Commodore 64 to zapraszam na stronę 64bites.com slash i nazwa tego podcastu, to tam dostaniecie ode mnie pewnie jakiś prezent, natomiast jeśli ktoś chce dowiedzieć się czegoś więcej takiego praktycznego o legacy to jakiś czas temu nagrałem taką prezentację o legacy kodzie w React’ie i o tym, jak w praktyce przerabiać właśnie stare komponenty klasowe na funkcyjne i to znajdziecie na stronie kursreacta.pl slash legacy. Tam jest ta prezentacja, wystarczy zostawić swój email i od razu możecie zobaczyć prezentację i dostaniecie cały kod źródłowy do zabawy w legacy samodzielnie. 

 

Dobrze. Jeszcze raz dziękuję bardzo za to, że zgodziłeś się nas odwiedzić i opowiedzieć tutaj o właśnie z jednej strony o tym legacy kodzie, o swoich pasjach, o tym, jak programujesz na Commodore 64. Dziękujemy. 

 

Dziękuję za zaproszenie, było mi bardzo miło tutaj gościć. 

 

Dziękuję również naszym widzom i słuchaczom. Mam nadzieję, że odcinek wam się podobał, jak zwykle zachęcam was do pozostawienia lajków, subskrypcji i komentarzy i również zachęcam was do obejrzenia linków, które umieścimy w opisie. Dziękuję, trzymajcie się, cześć! 

 

A ja zapraszam do komentowania czy mieliście Commodore, czy Atari, czy ZX Spectrum i proszę się nawzajem nie hejtować za bardzo.

 

Dzięki! 

________________________________________________________

Podcast DEVision to polski podcast IT dla programistów, którzy chcą rozwijać swoją wiedzę, posłuchać o ciekawych projektach oraz zainspirować się innymi. A to wszystko w przyjemnej formie rozmowy, której możesz słuchać w tramwaju, na siłowni, a nawet w pracy 😉

💌 Zapisz się do naszego newslettera: https://bit.ly/37TTNCK

🌏 Więcej o nas przeczytasz na stronie: https://bit.ly/3Pttiox

Obserwuj nas na social media: 🚀

LinkedIn: https://bit.ly/3PxlHFQ

🎧 Spotify: https://spoti.fi/39xU0fm

🎧 iTunes: https://apple.co/3PsjhrQ

Jeśli Ci się temat spodobał, subskrybuj nasz kanał, bo dopiero się rozkręcamy z gorącymi tematami! 🙂