Żyjemy w dziwnych czasach, w których firmy technologiczne zmieniają nazwy technologii open source (i innych technologii w ogóle) i odsprzedają swoje usługi pod marką lub produktem. Czasami oba.

Rekruter HR, który nie ma w tym żadnej winy, wykorzystuje tę falę i zaczął traktować eksperymenty czy doświadczenia jako wiedzę. Podobna historia mogłaby istnieć, wyobraźmy sobie inżyniera żywności pracującego dla Pepsi. Następnie decyduje się na rozmowę kwalifikacyjną dla firmy Coca-Cola i zadawane jest pytanie: „Czy miałeś jakieś doświadczenie w produkcji coli?”. Oczywiście nie. Inżynier ma doświadczenie w wytwarzaniu napoju, dowolnego napoju. Bez względu na smak!

Jeśli chodzi o branżę technologiczną, mamy listę języków, listę frameworków, listę dostawców usług w chmurze i listę narzędzi. Ogólnie rzecz biorąc, będziesz używać języka w ramach platformy za pośrednictwem narzędzia i wdrażać go u dostawcy chmury.

Starszy inżynier oprogramowania nie pracował już ze wszystkimi istniejącymi językami, ze wszystkimi frameworkami, używając wszystkich narzędzi i znając wszystkie nazwy produktów wymyślone przez dostawców usług w chmurze. AWS RDS to tylko baza danych, GCP Compute to tylko maszyna wirtualna i tak dalej. Ale w opisach stanowisk z dzisiaj pytano: czy znasz AWS? Czy programowałeś już wcześniej w Rust? Ile lat masz doświadczenie w języku Go? Czy masz doświadczenie we Flutterze? To są narzędzia!

Starszy inżynier oprogramowania zna algorytmy, struktury danych i projekty systemów. On/ona wie, jak zoptymalizować monolityczną aplikację, aby przenieść długotrwałe zadania za pomocą kolejek do funkcji bezserwerowych, które są niczym więcej niż kontenerem z odpowiednimi programami wykonawczymi do uruchomienia tego fragmentu kodu. Nie ma znaczenia dostawca chmury, nie ma znaczenia język, a nawet framework. Nie ma znaczenia nazwa produktu. Być może, być może, może to być AWS Lambda, ale nie jest to wymagane.

Z powodu tej rzeczywistości i mojego braku zgody co do tego, jakie będą opisy stanowisk i wymagania, również osoba z działu HR nie rozumiała tych wymagań. Kompiluję wiedzę niezbędną do bycia dobrym starszym inżynierem oprogramowania w 7 (siedmiu) kategoriach, bez marek i produktów. Moim zdaniem właśnie to powinno znaleźć się w opisach stanowisk pracy. Nie języki, frameworki, nazwy produktów ani narzędzia konkretnej marki.

1. — Linux (niezależnie od dystrybucji).

Internet działa pod Linuksem. Mamy Linuksa na urządzeniach, serwerach, routerach, przełącznikach, czujnikach, wbudowanym w podłączone samochody, krótko mówiąc, we wszystkim.

Starszy inżynier oprogramowania powinien wiedzieć, jak działa jądro, jak obsługuje procesy, jak procesy się komunikują, jak działa wirtualizacja, co sprawia, że ​​kontener jest odizolowany od siebie, jak działają systemy plików, co powoduje rozruch systemu i co działo się przed jądrem przejmuje. Jak monitorować procesy w systemie Linux, jak nim zarządzać i jak działa model bezpieczeństwa wbudowany w Linux. To minimum bazowe.

2. – W jaki sposób rzeczy się komunikują?

Rzeczy się komunikują! Twój telefon komunikuje się z telefonem znajomego za pośrednictwem aplikacji do obsługi wiadomości. Twoja przeglądarka ma dostęp do wyszukiwarki Google. Twój tablet uzyskuje dostęp do arkusza kalkulacyjnego zapisanego na dysku przechowywanym u dostawcy usług w chmurze, korzystając z usługi synchronizacji zmian i aktualizacji w czasie rzeczywistym zmian zarówno Ty, jak i Twój współpracownik.

Podkreślając to wszystko, masz aplikacje, serwery, protokoły, łącza fizyczne i całą maszynerię, którą nazywamy po prostu Internetem ;-).

Starszy programista powinien wiedzieć, jakie maszyny wysyłają sygnał z jednego punktu na kuli ziemskiej do drugiego. Sposób, w jaki ta komunikacja odbywa się na zasadzie łącze po łączu, oraz sposób, w jaki maszyny przekazują pakiet między sobą, aż dotrze do miejsca docelowego. Powinieneś także wiedzieć, jaki ładunek znajduje się w paczce i jaki protokół jest w niej zawarty. W jaki sposób ten protokół przenosi informacje z aplikacji. Oraz o tym, jak różne aplikacje uruchamiały się na tej samej maszynie bez informacji o wycieku informacji z jednej aplikacji do drugiej. Powinien wiedzieć o adresach IP i protokołach operatorów, takich jak TCP i UDP, oraz o tym, jak routing odbywa się przy użyciu tych protokołów.

Podstawa, na której wszyscy polegamy, polega na tym, że: protokół operatora, taki jak TCP i protokół routingu, taki jak IP, działają! Ładunek z protokołu aplikacji, takiego jak HTTP, jest przesyłany z jednego punktu do drugiego.

Starszy inżynier oprogramowania powinien także wiedzieć, w jaki sposób protokół HTTP przenosi dane, wyszukuje informacje przy użyciu identyfikatora URI i wysyła prawidłowe informacje do odpowiedniego klienta w ramach z góry określonego połączenia zwanego gniazdem, które łączy klienta z serwerem, używając kilkakrotnie , różne ścieżki fizyczne w celu dostarczenia różnych pakietów.

3. — Jak aplikacje działały na podstawie tych procesów

Komputery są urządzeniami ogólnego przeznaczenia, dziś możemy zaprogramować komputer do praktycznie wszystkiego, ale posługują się one bardzo trudnym do odczytania językiem zaprojektowanym przez producenta procesora, będącym kodem asemblera dla tego modelu procesora. Z tego powodu mamy kompilatory (i interpretery), które tłumaczą bardziej czytelny kod, taki jak Python, na kod maszynowy. W rzeczywistości nie jest to takie proste, możemy mieć całą gamę implementacji językowych. Niektóre są dobre do niektórych rzeczy, inne są dobre do innych rzeczy. Czasem potrzebujesz wydajności, czasem na przykład szybkiego ukończenia projektu. Ponadto, w tym samym argumencie, niektóre programy działają w niektórych systemach operacyjnych, a inne w innym systemie operacyjnym.

Spójrzmy na przykład na niedawny przypadek użycia przez Apple innej architektury na swoich komputerach, ale można uruchomić Pythona w systemie Windows z procesorem CISC, a także ten sam kod Pythona na architekturze ARM na komputerze z systemem macOS. Ta „magia” polega na tym, że niektóre języki są kompilowane, a niektóre są interpretowane w czasie wykonywania. I na tym się nie kończy. Niektóre języki są zaprojektowane tak, aby traktować dane jako rzecz dynamiczną, ta sama zmienna może być liczbą, a później w programie zmienić się na słowo. Inne języki mają silny paradygmat typów i zmienna, która jest najpierw zadeklarowana jako liczba, zawsze będzie liczbą w programie. Wszystko to oznacza, że ​​starszy programista rozumie wszystkie różnice i implikacje wynikające z różnych języków, nawet jeśli sam nigdy nie kodował w tym języku.

Ważne jest, aby wiedzieć, że Twój program uruchomi się w procesie i będzie zarządzany przez bieżący system operacyjny. Nie jest to nieuczciwy program, który robi, co chce. System operacyjny narzuca ograniczenia, takie jak chroniona pamięć i ograniczony dostęp do innych procesów, a w niektórych przypadkach także do systemu plików, plików wejścia-wyjścia itp., musisz znać środowisko, w którym się znajdujesz, co sprowadza się do pierwszej wiedzy które musi posiadać starszy programista.

4. — Jak istnieją protokoły aplikacji

Niektórzy dyrektorzy generalni, a nawet inżynierowie, mają tendencję do ewangelizacji technologii. Bycie dostawcą chmury, frameworkiem, językiem, a nawet narzędziem. Ale w rzeczywistości minęło kilka dekad, odkąd standaryzowaliśmy protokoły aplikacji działające w Internecie. Mamy HTTP, HTTPS, FTP, UDP, RTSP i inne. Być może bufory protokołu (protobuf) korzystające z gRPC są nowe, ale bardzo rzadko zdarza się, że robisz swoją aplikację bez użycia niektórych z cytowanych wcześniej lub nawet po prostu używając HTTP (S Może).

Starszy programista o tym wie i wie, że niezależnie od stosu technologicznego, jest on ograniczony przez ograniczenia HTTP, masz tylko kilka CZASOWNIKÓW i przez długi czas używane są tylko GET i POST. Nie ma znaczenia, czy robisz to „najpierw aplikacja”, „najpierw urządzenia mobilne”, „najpierw internet”, czy „najpierw komputer stacjonarny”, nie ma to znaczenia. Komunikujesz się za pomocą protokołu HTTP. Twój podstawowy serwer WWW obsługuje tylko ograniczoną liczbę jednocześnie podłączonych klientów. Twoja monolityczna aplikacja Full-Stack nie będzie skalowana. Jeśli to MVP, to OK. Ale będziesz musiał się zmienić. I zmienić wiele. Im więcej złych decyzji zostanie podjętych, tym więcej czasu stracisz, próbując stworzyć coś niewykonalnego. A starszy programista od początku wie, że jest to niewykonalne, posłuchaj swojego starszego programisty. Jeśli on/ona był jednym.

Nie przyjmuj kultury korporacyjnej, zgodnie z którą CTO jest zawsze odpowiedni dla dyrektora, dyrektor ma zawsze rację dla menedżera, menedżer ma zawsze rację dla kierownika technicznego, kierownik techniczny jest zawsze odpowiedni dla inżyniera, a inżynier nie nie mam żadnego głosu. On/ona odejdzie.

Dobry starszy inżynier oprogramowania zna technologię leżącą u podstaw stosu technologii, nie przejmuje się szumem ani tym, czego wszyscy używają. Nie przekonuje się prezentacją wideo ani prezentacją na stronie promującej stos technologii. On/ona wie co robi. Co technologia zapewnia, a czego nie. Ponownie posłuchaj swojego starszego programisty, jeśli go masz.

5. — Algorytmy i struktury danych

Wierzcie lub nie, ale istnieje ograniczona liczba sposobów przetwarzania danych. Dane można przechowywać, przeszukiwać, sortować, aktualizować i niszczyć. Istnieje tylko jeden sposób przedstawienia tych danych. Z 0 i 1.

Sposoby przechowywania, wyszukiwania, organizowania, zmieniania i usuwania danych są już zdefiniowane. Na przykład, aby uporządkować, masz drzewa binarne, listy połączone, listy podwójnie połączone, tabele mieszające i kilka innych. To samo dotyczy przechowywania, wyszukiwania, zmiany i usuwania.

Starszy inżynier oprogramowania zna te algorytmy, te bardziej złożone, wydajniejsze, te, które zużywają więcej pamięci, te, które zużywają mniej pamięci i tak dalej. Nie musi już znać języka programowania, tych pojęć uczy się jeszcze zanim zaczniesz kodować. Kodowanie jest przejawem tej wiedzy. Jeśli starszy programista zna Swifta i Pythona, ale nie zna Rusta, to NIC nie znaczy. Oznacza to tylko, że nauczy się tego za kilka tygodni. Ponieważ kodowanie jest przejawem głębszej wiedzy, czyli myślenia obliczeniowego i nastawienia na rozwiązywanie problemów. A jeśli jest starszym programistą, posługuje się już kilkoma językami. Każdy język, jakiego potrzebujesz, jest więcej niż zdolny do nauczenia się i używania, bez względu na to, jak dziwny jest lub pozornie trudny.

Jeżeli Senior Software Developer zna już jakieś języki (tak, w liczbie mnogiej) to jest Seniorem i nowy język nie będzie dla niego problemem.

6. — Sposób utrwalania danych

Podobnie jak w przypadku algorytmów, istnieje tylko kilka rozwiązań umożliwiających przechowywanie danych. Każdy z nich na jakąś konkretną rzecz. Od dziesięcioleci trwają badania nad sposobami przechowywania danych transakcyjnych. Innymi słowy, możesz zagwarantować, że jeśli wynik polecenia INSERT zwróci wartość true, możesz mieć pewność, że dane tam będą, niezależnie od tego, ile milisekund upłynęło od chwili, gdy poprosiłem o te dane, lub czy całe centrum danych zostało później wyłączone. Nazywamy to ATOMOWYM. Są to relacyjne bazy danych. Zdecydowanie najbardziej efektywny sposób przechowywania i utrwalania danych, jaki istnieje obecnie.

Istnieją również alternatywy, a ja omówię jeszcze dwie: przechowywanie bloków i przechowywanie dokumentów. Obecnie panuje szum wokół przechowywania dokumentów, wydaje się, że każdy chce używać bazy danych NoSQL, ale baza danych NoSQL jest właśnie tym, co wskazuje nazwa, bazą danych, która nie jest oparta na transakcjach „see-quel”, kiedy WSTAWIASZ w niej rzeczy, nie ma gwarancji, że dane zostały zapisane. Ostatecznie dane zostaną zachowane, ale nie wiadomo, ile czasu później. Może się zdarzyć, że jeśli będziesz potrzebować danych zaraz po ich wstawieniu lub aktualizacji, otrzymasz starą odpowiedź.

Starszy programista o tym wie i wykorzystuje to w scenariuszach, w których nie jest konieczne natychmiastowe odczytanie transakcji ATOMIC, a dokumenty można przechowywać i wyświetlać tylko wtedy, gdy są gotowe, np. w sieci społecznościowej. Ale nie w scenariuszu, w którym przeprowadzasz transakcję finansową dotyczącą płatności elektronicznej i musisz upewnić się, że płatność została zrealizowana w tym czasie. Następnie musisz to zrobić w relacyjnej bazie danych. Ponownie, bez względu na nazwę produktu w chmurze Google, AWS lub Azure. Zna technologię, niezależnie od nazwy produktu.

Teraz mało wiem o przechowywaniu blokowym, starszy inżynier oprogramowania rozumie naturę przechowywania, wie, że za kulisami nie przechowujemy bitów, przechowujemy w blokach, plikach, bazach danych (które są tylko plikami) , trwałość, a nawet „pamięć” ulubionego języka, są ostatecznie przechowywane w blokach. Łatwiej jest przechowywać dane w blokach i mieć do nich późniejszy dostęp za pomocą mapy. Wyobraź sobie, że musisz czytać cały dysk za każdym razem, gdy potrzebujemy pliku? Czytania całej bazy danych w celu znalezienia danych dotyczących płatności? Robimy mapy i indeksujemy rzeczy. Zaglądamy do tych indeksów jak czytelnik przeglądający stronę podsumowującą swoją ulubioną książkę, aby zapamiętać, która strona zawiera jego ulubiony cytat. To podsumowanie zawiera ważne bloki, w których przechowywane są dane, a następnie tam przechodzimy.

7. — Jak powstaje oprogramowanie

I wreszcie, starszy inżynier oprogramowania wie, jak tworzone jest oprogramowanie kawałek po kawałku, wie, co jest priorytetem, a co nie. Rozumie podstawy tworzonego oprogramowania i pomoże zespołowi zrozumieć, że niektóre części oprogramowania można dokończyć później. Potrzebuje tylko kilku minut z właścicielem produktu, aby zrozumieć, czym jest oprogramowanie i jak można je rozwijać. Jasne, ewolucja oznacza zmianę, ale to jest całkowicie w porządku. Niewłaściwe jest to, że w środku projektu jakiś dyrektor generalny zeskrobuje cały kod i chce zacząć od nowa. To tylko przypadek ogromnego przesunięcia się do samej firmy. Ale budowanie tego samego produktu, ale z innym stosem technologii, tylko dlatego, że jest to niedopuszczalne.

RUP to śmieci, nikt już go nie używa, to tak jakbyś mówił, że silnik uruchamiasz korbą. Nigdy nie pracowałem i nigdy nie będę. Firmy go używają, ponieważ jeśli mówisz, że go używasz, wyglądasz fajnie.

Przypadków użycia, wymagań, artefaktów, diagramów klas i diagramów sekwencji nadal uczy się na uniwersytetach, ale wszystko to jest do niczego. Której nigdy do niczego nie użyjesz. Można argumentować, że przypadki użycia dobrze pomagają zrozumieć zachowanie klienta lub aktora w programie, ale łatwiej jest przyciągnąć klienta i po prostu go zapytać. Zrobić listę. Do swojego projektu nie potrzebujesz samoprzylepnych rysunków.

To samo z ITIL, wyrzuć to.

To samo dotyczy modeli możliwości, wyrzuć je.

Starszy inżynier oprogramowania zna zasady manifestu Extreme Programming i posługuje się nim.

Starszy inżynier oprogramowania zna zasady Scruma i je wykorzystuje.

Nie Jira, nie Kanban, nie narzędzie… zasady. Dobry starszy inżynier oprogramowania wie, kiedy ceremonia Scruma nie jest potrzebna. A kiedy to nastąpi.

Dobry starszy inżynier oprogramowania uczy się wszystkich tych koncepcji i kiedy są one mieszane w sposób, o którym nawet on sam nie wiedział, skąd i kiedy się tego nauczył. Następnie możesz uznać go za starszego inżyniera oprogramowania. I możliwe, menedżer.

Przed zakończeniem…

Nie jestem właścicielem prawdy, jeśli masz jakieś uwagi, sugestie lub poprawki do tego tekstu, podziel się nimi na moim koncie na Twitterze tutaj.