Dawno mnie tu nie było, ale był też istotny tego powód. Niby człowiek wiedział, ale się łudził i fakt przejęcia Idea Banku przez Pekao spadł na mnie dość nieoczekiwanie, zwłaszcza, że miało to miejsce w południe w sylwestra 2020. Do tamtej pory pracowałem rozwijając aplikacje backoffice’owe w PHP, w Pekao ten język praktycznie nie istnieje poza jakimiś marginalnymi zastosowaniami (zresztą nie wiem, czy ma on rację bytu gdziekolwiek indziej w bankowości poza grupą Leszka Czarneckiego), więc pierwsze tygodnie oznaczały dla mnie miotanie się pomiędzy decyzją o pozostaniu w Pekao i zmianą języka, a zmianą pracy na inną i pozostaniu przy PHP. “Miotanie się” to bardzo adekwatne w tym wypadku określenie – nastrój w tej kwestii zmieniał mi się czasem co tydzień w skrajnych kierunkach. W Pekao dominuje szeroko pojęty .NET, więc dla mnie oznaczałoby to nie tylko zmianę języka, ale zaczynanie praktycznie od zera w większości powiązanych technologii. Tak na szybko listując: język ze słabo typowanego, skryptowego na silnie typowany, kompilowany, DBMS z PostgreSQL na SQL Server, serwery HTTP z Apache/nginx na IIS, środowisko uruchomieniowe z linuksowego na windowsowe, IDE z Eclipse na Visual Studio, do tego dużo drobniejszych rzeczy, jak razor pages, inny ORM, powszechnie używane zasoby sieciowe zamiast NFS/SFTP, itd. Dużo tego. Zupełnie inaczej wyobrażałem sobie też przepięcie na nowe technologie – część kolegów zaczęła swoją technologiczną konwersję praktycznie z dnia na dzień. W moim przypadku ostatecznie było inaczej – system, który tworzyliśmy w IB, podlegał migracji do systemów Pekao, więc było to priorytetem i potrwało do listopada 2021, a ja w tym czasie mogłem się spokojnie oswoić z nowym stackiem technologicznym i zacząć przyswajać wiedzę z tego zakresu, jeszcze wtedy na wolnych obrotach.
Pracę w projektach .NET-owych zacząłem na poważnie w grudniu 2021, więc ostatnio minęły pełne 4 miesiące pracy przy nich, taki większy okres próbny. Postanowiłem więc, że póki mam to jeszcze na świeżo, to opiszę moje wrażenie z takiej przesiadki.
Pierwszy miesiąc to głównie przyzwyczajanie się do silnie typowanego języka. Po ponad 10 lat pracy w PHP trzeba było zmienić przyzwyczajenia nawet w tak podstawowych kwestiach, jak dobór typów danych (i wyleczenie się ze wszechobecnych w PHP, mieszanych tablic asocjacyjnych). Nie było to jednak jedyne przyzwyczajenie do zmiany: samo środowisko uruchomieniowe rządzi się innymi prawami i niektóre rzeczy są rozwiązane w sposób, który nigdy we wcześniejszym stacku nie przyszedłby mi do głowy (koordynator transakcji rozproszonych jako osobna usługa jest moim faworytem do tego rankingu).
Z silnym typowaniem z perspektywy czasu jest jednak jak z przejściem ze skrzyni manualnej na automatyczną – na początku wkurza zahaczanie nogą o szeroki hamulec i odruchowe wpadanie lewej nogi w dziurę, gdzie powinno być sprzęgło, jednak po czasie docenia się to, że pewne rzeczy wyłapywane są już na etapie kompilacji. Początkowo było to dla mnie nieco uporczywe i zdawało mi się zbędnym narzutem, jednak nie zauważałem pewnego istotnego faktu: wcześniejsze projekty znałem dość dobrze i w przypadku zmian na poziomie modelu wiedziałem, gdzie szukać obszarów do refaktoryzacji. Gdy jednak nie ma się jeszcze takiej wiedzy, to w przypadku PHP często błędy wychodziły dopiero podczas uruchomienia pominiętego kodu. Tutaj projekty są dla mnie nowe, więc takiej wiedzy nie mam, a przeszukiwanie kodu źródłowego nie zawsze jest na tyle efektywne, aby zidentyfikować wszystkie konieczne miejsca.
Silne typowanie ma jeszcze jeden plus – dzięki niemu autouzupełnianie w IDE i ogólnie asystent kodu stoją na zupełnie innym poziomie, niż w PHP. Tutaj na każdym etapie zmienne mają znany edytorowi typ, więc praktycznie wszędzie mamy dostęp do podpowiedzi, co w przypadku PHP – nie było tak oczywiste.
Pisanie aplikacji webowej w C# z użyciem ASP.NET MVC to też pole do zmiany przyzwyczajeń. Dużo się tu dzieje w middleware’ach. W PHP korzystałem z Zenda i operowanie na surowej tablicy wartości z POST, lekko tylko przerobionej (np. przefiltrowanej) przez framework było dla mnie naturalnym podejściem. Tutaj królują modele, które są automatycznie mapowane z danych POST/GET. Za tym idzie mnóstwo innych rzeczy, jak np. sprzęgnięta walidacja, itd. Po krótkim przyzwyczajeniu jest to dużo wygodniejsze, niż praca na surowych danych z POST.
Konstrukcja języka C# mi się podoba. Są rzeczy, których brakowało mi w PHP (część z nich jednak w międzyczasie została wprowadzona w wersji 8 – gdzie one były przez tyle lat mojej pracy? :P), na przykład named parameters. Dłużej musiałem przysiąść nad powszechnie używanymi wyrażeniami lambda, których czasem w PHP się używało, ale w zupełnie inny sposób. Podobnie z typami generycznymi, z których prototypem (szablonami) miałem do czynienia dawno temu, gdy pisałem w C++. Do tego mnóstwo różnych, drobnych rzeczy, których nie znałem, a których używa się na co dzień (jak chociażby postępowanie z Nullable, bardziej zaawansowane używanie list, itd.).
A propos list, nie można zapomnieć o LINQ. Bardzo spodobało mi się to rozwiązanie, po opisanym wcześniej ogarnięciu wyrażeń lambda można wiele zrobić z kolekcjami w łatwy i krótki sposób. Dodatkowo, w zastosowaniach bazodanowych, w połączeniu z IQueryable czułem jak się w domu ze względu na przyzwyczajenie do zendowych selectów.
Polubiłem też wykorzystywany tu ORM i sposób tworzenia modelu. I choć widzę, że mam w tym temacie jeszcze mnóstwo do nauczenia, to jest przede wszystkim dużo szybciej niż w PHP, zarówno z mapowaniem struktury bazy danych na model, jak i chociażby z migracjami bazodanowymi. Pamiętam, że podobnie miałem, gdy w 2012 przesiadłem się z CodeIgnitera na Zenda i jego active record i Zend_Db_Select. Zresztą ostatnie miesiące bardzo przypominają mi 2012 – przyswajam dużo nowej wiedzy w krótkim czasie, wtedy zdaje się, że porównywałem pierwsze pół roku pierwszej pracy na etacie do całego drugiego stopnia studiów pod kątem przyswojonej wiedzy.
Nie mogę w tym zestawieniu pominąć debugowania aplikacji w Visual Studio. Coś, co działa z automatu i czego używa się codziennie to dla mnie zdecydowanie nowość. Wcześniej, w PHP, używałem xdebug do debugowania kodu krok po kroku lub do profilowania tylko w wyjątkowych sytuacjach, gdy logika była na tyle zaawansowana, że ciężko było ją debugować przez wypluwanie wartości lub wtedy, gdy trzeba było przyjrzeć się z wysokiego poziomu wykonywaniu kodu i systemowego i systemowo go zoptymalizować. Zresztą sama konfiguracja xdebug w PHP była dość problematyczna, szczególnie na obwarowanych zabezpieczeniami komputerach bankowych i takowej infrastrukturze sieciowej. Nie mówiąc już o szybkości działania tak debugowanej aplikacji.
Co do samego Visual Studio, to spodobał mi się gitowy merge tool, który jest znacznie wygodniejszy, niż wcześniej preferowane przeze mnie ręczne rozwiązywanie konfliktów – tutaj mam kod z dwóch stron konfliktu na podzielonym ekranie, mogę pojedyncze linie włączać do rozwiązania konfliktu checkboksami, a dodatkowo edytować go w połączonej wersji. Coś wspaniałego. Rozczarował mnie natomiast brak narzędzia do częściowego stage’owania zmian w gicie. Zostało podobno wprowadzone w VS 2022, więc chętnie wypróbuję, jednak póki co korzystam z VS 2019, więc pozostaje mi nadal dobrze znana obsługa gita z konsoli.
Podsumowując, z przesiadką na nowy stack technologiczny jest lepiej, niż przewidywałem. Nadal jestem na samym początku drogi, więc najbliższe miesiące to na pewno czas dalszej nauki w tym kierunku, jednak sam jestem zdziwiony, że wcześniejsze przyzwyczajenia i uprzedzenia w sumie dość szybko odpuściły. Zawsze byłem też z tych, którzy mocno się do takich rzeczy przyzwyczajają i ciężko było mi zwizualizować sobie trwałą, nieincydentalną przesiadkę np. na zupełnie inny język programowania. Nie doceniałem w tej kwestii jednak doświadczenia, które na pewno ma tu spore znaczenie – znając dobrze zasadę działania aplikacji internetowych, język to tylko narzędzie, sam sposób myślenia, programowanie obiektowe i sposób rozwiązywania problemów są w zasadzie takie same i cieszę się, że przekonałem się o tym na własnej skórze.
