Co kilka lat narzędzia zmieniają się całkowicie, i co kilka lat ten sam niewielki zestaw idei okazuje się tłumaczyć, co poszło nie tak.
Problem okresu połowicznego rozpadu
Wiedza techniczna nie starzeje się w jednolitym tempie, a ta różnica to najbardziej przydatna rzecz, jaką organizacja może zrozumieć o szkoleniu swoich inżynierów.
Wiedza o frameworkach i bibliotekach starzeje się szybko. Technika przypisana do konkretnej wersji, poznana dziś, często jest przestarzała w kilka lat, czasem szybciej. Wiedza o platformach i dostawcach starzeje się niemal równie szybko, a konkretne komendy i interfejsy zmieniają się bez przerwy.
Pod spodem leży warstwa, która niemal się nie poruszyła. Jak komputer wykonuje instrukcje. Ile kosztuje struktura danych. Dlaczego niektóre algorytmy się skalują, a inne nie. Co system operacyjny robi z pamięcią i z oczekiwaniem. Jak sieci faktycznie dostarczają wiadomość.
Szkolenie ludzi wyłącznie w szybko starzejącej się warstwie oznacza przeszkalanie ich co trzy lata, na zawsze.
To nie argument przeciwko szkoleniu praktycznemu. To argument o proporcjach. Większość korporacyjnego rozwoju technicznego wydaje mocno na warstwę o najkrótszym czasie życia i niemal nic na warstwę, dzięki której kolejne narzędzie da się nauczyć w tydzień, a nie w kwartał.
Co obejmuje ten kierunek
Zakres: algorytmy, struktury danych, systemy operacyjne, sieci i teoria obliczeń.
Cztery obszary.
Algorytmy i struktury danych. Ile kosztują operacje, która struktura pasuje do jakiego wzorca dostępu i jak rozumować o skali.
Systemy. Procesy, pamięć, planowanie zadań, pliki i abstrakcje ukrywające sprzęt.
Sieci. Jak przemieszczają się dane, co może pójść nie tak i dlaczego systemy rozproszone są trudne w konkretny sposób.
Teoria obliczeń. Co jest obliczalne, co jest wykonalne w praktyce i gdzie leżą twarde granice.
Złożoność, czyli jedna idea, która się zwraca
Jeśli organizacja uczy tylko jednej koncepcji z tego kierunku, powinna to być właśnie ta.
Złożoność algorytmiczna opisuje, jak rośnie praca wykonywana przez algorytm w miarę wzrostu danych wejściowych. To rozróżnienie nie jest akademickie. To różnica między kodem, który działa w testach, a kodem, który zawodzi na produkcji.
Trzy praktyczne konsekwencje.
Dane testowe ukrywają problem. Algorytm, w którym praca rośnie z kwadratem danych wejściowych, wygląda dobrze na tysiącu rekordów i staje się bezużyteczny na milionie. Ta awaria to nie błąd, który pojawia się później. Była obecna od pierwszej linii kodu i była niewidoczna przy skali testowej.
Zagnieżdżona pętla po bazie danych to najczęstszy kosztowny błąd w komercyjnym oprogramowaniu. Zapytanie wewnątrz pętli, gdzie każda iteracja wykonuje własny przelot do bazy, działa akceptowalnie przy garstce elementów i zapada się przy realnym wolumenie. Ten wzorzec pojawia się bez przerwy, w każdym języku, pisany przez ludzi z wieloletnim doświadczeniem, bo nikt nie pokazał im, jak go dostrzec.
Wybór właściwej struktury zwykle daje większy zysk niż optymalizacja kodu. Wyszukiwanie w liście oznacza sprawdzenie każdego elementu. Wyszukiwanie w tablicy haszującej jest praktycznie natychmiastowe, niezależnie od rozmiaru. Zmiana jednej linijki bije przepisanie stu.
Nic z tego nie wymaga matematycznej biegłości. Wymaga nawyku pytania, co się stanie, gdy to urośnie dziesięciokrotnie, a tego nawyku można szybko nauczyć ludzi, którzy już piszą oprogramowanie.
Co naprawdę robi system operacyjny
Warstwa, którą większość pracujących deweloperów traktuje jako niewidoczną, i skąd pochodzi zaskakująco duża część problemów produkcyjnych.
Pamięć. Jak działa alokacja, ile kosztuje garbage collection i kiedy zatrzymuje program, dlaczego lokalność pamięci wpływa na szybkość dużo bardziej niż liczba instrukcji, i co dokładnie dzieje się, gdy proces wyczerpuje dostępną pamięć. Problemy z pamięcią należą do najtrudniejszych do zdiagnozowania awarii produkcyjnych bez tego obrazu.
Procesy i wątki. Co oznacza izolacja, ile kosztuje przełączenie kontekstu i dlaczego dodawanie wątków po pewnym progu spowalnia system zamiast go przyspieszać.
Wejście i wyjście. Powód, dla którego większość aplikacji czeka, a nie liczy. Operacje na dysku i sieci są o rzędy wielkości wolniejsze niż dostęp do pamięci, dlatego istnieją podejścia asynchroniczne i nieblokujące. Inżynierowie, którzy tego nie zinternalizowali, optymalizują obliczenia w programach, które spędzają życie na czekaniu.
Współbieżność. Wyścigi danych, zakleszczenia i fakt, że operacje wyglądające na atomowe w kodzie źródłowym takie nie są. To kategoria błędu, która przechodzi każdy test i zawodzi na produkcji pod obciążeniem, i nie da się jej rozumieć bez tego modelu.
Gdzie to się mieści w domenie
Informatyka to pierwszy z ośmiu kierunków w domenie AI, danych i informatyki Astra Trainer, i leży pod resztą z nich. Inżynieria oprogramowania, data science, chmura i DevOps, cyberbezpieczeństwo i uczenie maszynowe opierają się na tych samych ideach obliczeniowych, a ludzie, którzy je znają, uczą się każdej nowej warstwy szybciej.
Łączy się najbezpośredniej z inżynierią oprogramowania, będącą tym materiałem zastosowanym pod komercyjnym ograniczeniem, oraz z systemami IT i sieciami komputerowymi, gdzie warstwa systemu operacyjnego i sieci to codzienna praca. Zobacz osiem kierunków tutaj.
Dlaczego to ma teraz większe, a nie mniejsze znaczenie
Powszechnym założeniem jest, że narzędzia do generowania kodu czynią fundamenty przestarzałymi. Odwrotny argument jest silniejszy i opiera się na tym, czym staje się ta praca.
Praca przesuwa się z pisania do oceniania. Recenzowanie kodu, którego się nie napisało, i decydowanie, czy jest poprawny, wymaga większego zrozumienia niż jego wytworzenie, nie mniejszego. Wiarygodnie wyglądająca funkcja o złej charakterystyce złożoności to dokładnie coś, co przechodzi pobieżną recenzję i zawodzi przy skali.
Wygenerowany kod jest pewny siebie co do wydajności w sposób, którego nie potrafi uzasadnić. Nie zna twoich wolumenów danych, wzorców dostępu ani budżetu opóźnień. Ktoś musi.
Debugowanie pozostaje trudną częścią. Gdy system zachowuje się nieoczekiwanie na produkcji, pytanie brzmi, co się naprawdę dzieje, a odpowiedź pochodzi z modelu działania maszyny.
Decyzji architektonicznych nie da się autouzupełnić. Wybór między spójnością a dostępnością, decydowanie, co cache'ować, ocena, gdzie postawić granicę: to decyzje, które rozstrzygają, czy system przetrwa, i wszystkie są pytaniami z zakresu fundamentów.
Uczciwe sformułowanie brzmi: te narzędzia podnoszą podłogę dla produkowania kodu i podnoszą wartość umiejętności jego oceny. Organizacje, które przeczytają tylko pierwszą połowę, a nie drugą, przekonają się, którą z nich miały.
Role, nazwane wprost
Inżynierowie oprogramowania na każdym poziomie, bo to jest podłoże.
Inżynierowie systemowi i programiści systemowi.
Inżynierowie wydajności, odrębna specjalizacja i wciąż rzadka.
Inżynierowie systemów rozproszonych.
Inżynierowie kompilatorów i środowisk uruchomieniowych.
Inżynierowie baz danych, gdzie spotykają się struktury danych i pamięć masowa.
Badacze bezpieczeństwa, których praca zależy od rozumienia, co maszyna naprawdę robi, a nie tylko co mówi kod źródłowy.
Architekci techniczni, podejmujący decyzje, które ten materiał wspiera.
Inżynierowie badawczy w systemach uczenia maszynowego, gdzie efektywność przy skali jest całym problemem.
Kogo można w to przeszkolić
Samoucy i absolwenci bootcampów. Największa i najbardziej wdzięczna grupa. Często mają silne umiejętności praktyczne, dobre nawyki narzędziowe i realne doświadczenie w dostarczaniu, z konkretną luką właśnie tutaj. Jej zamknięcie to zdefiniowany kawałek pracy, a nie ogólny program podnoszenia kompetencji, a efekt dla ich sufitu kompetencyjnego jest duży.
Analitycy i naukowcy danych. W stronę wydajności i skali, gdzie zapytania i pipeline'y działające na próbkach zawodzą na pełnych danych dokładnie z tych powodów.
Administratorzy IT i systemów. Mający już wiedzę o systemach operacyjnych i sieciach z operacyjnej strony, potrzebujący warstwy programistycznej.
Inżynierowie z innych dyscyplin. Absolwenci matematyki, fizyki i inżynierii dobrze się przekwalifikowują, bo sposób rozumowania się przenosi.
Inżynierowie QA i testów. W stronę ról inżynierskich, mając silne wyczucie tego, jak rzeczy zawodzą.
Inżynierowie wsparcia. W stronę developmentu, z realną wiedzą, co psuje się na produkcji i dlaczego.
O fundamentach i rekrutacji. Rozmowy rekrutacyjne oparte na algorytmach są szeroko stosowane i szeroko krytykowane jako filtr rekrutacyjny, a wynik w nich koreluje niedoskonale z wynikami w pracy. Ten kierunek istnieje, żeby uczynić ludzi lepszymi w budowaniu i diagnozowaniu systemów, nie żeby optymalizować pod format rozmowy kwalifikacyjnej. Organizacje korzystające z tego materiału powinny mieć jasność, które z tych dwóch celów realizują, bo szkolenie służące jednemu niekoniecznie służy drugiemu.
Co z tego wynieść
Wiedza techniczna starzeje się w różnym tempie, a większość budżetów szkoleniowych wydaje się na warstwę starzejącą się najszybciej.
Złożoność to pojedyncza koncepcja o najwyższej wartości, bo przewiduje awarię przy skali, zanim kod zostanie napisany.
Większość produkcyjnych problemów z wydajnością to problemy pamięci, oczekiwania lub współbieżności, a wszystkie trzy żyją w warstwie systemu operacyjnego, którą większość deweloperów traktuje jako niewidoczną.
Generowanie kodu podnosi wartość osądu, a osąd oznacza tu fundamenty.
A ludzie, którzy zyskują najwięcej, już piszą dla ciebie oprogramowanie, z luką, która jest konkretna, widoczna i szybka do zamknięcia.
Dlaczego uczyć fundamentów, a nie aktualnych frameworków?
Bo wiedza o frameworkach starzeje się w kilka lat, a leżące pod nią idee obliczeniowe przetrwały dekady, a ludzie, którzy je znają, uczą się każdego nowego frameworka w ułamku czasu.
Jaka jest najbardziej przydatna pojedyncza koncepcja?
Złożoność algorytmiczna. Tłumaczy, dlaczego kod przechodzący testy zawodzi przy wolumenie produkcyjnym, dlaczego zapytanie w pętli zapada się przy realnych danych i dlaczego wybór właściwej struktury danych zwykle bije optymalizację kodu.
Dlaczego koncepcje systemu operacyjnego mają znaczenie dla deweloperów aplikacji?
Bo większość produkcyjnych problemów z wydajnością to problemy pamięci, wejścia-wyjścia lub współbieżności. Aplikacje zwykle spędzają czas na czekaniu, a nie liczeniu, a optymalizowanie obliczeń w czekającym programie niczego nie daje.
Czy narzędzia generujące kod czynią fundamenty mniej ważnymi?
Czynią je ważniejszymi. Praca przesuwa się z pisania kodu do oceniania kodu, którego się nie napisało, a wygenerowany kod nie zna twoich wolumenów danych, wzorców dostępu ani budżetu opóźnień.
Kto zyskuje najwięcej na tym szkoleniu?
Samoucy i absolwenci bootcampów, często z silnymi umiejętnościami praktycznymi i konkretną, możliwą do nauczenia luką właśnie tutaj, a zaraz za nimi analitycy danych trafiający na problemy skali i administratorzy systemów przechodzący do developmentu.