W latach 80-tych, najłatwiejszym sposobem na rozpoczęcie walki nerdów było ogłoszenie, że twój ulubiony język programowania jest najlepszy. C, Pascal, Lisp, Fortran? Programiści spędzali całe godziny na wyjaśnianiu, dlaczego ich sposób tworzenia klauzuli if-then-else jest lepszy od twojego.
To było wtedy. Dzisiaj, bitwy dotyczące składni i struktury są w dużej mierze zakończone, ponieważ świat zrównał się w kilku prostych standardach. Różnice między średnikami, nawiasami klamrowymi i czym tam jeszcze w C, Javie i JavaScript są niewielkie. Ciekawe debaty na temat typowania i domknięć nadal istnieją, ale większość z nich jest bezprzedmiotowa, ponieważ automatyzacja wypełnia lukę. Jeśli nie lubisz określać typu danych, jest duża szansa, że komputer będzie w stanie wywnioskować, co dokładnie miałeś na myśli. Jeśli twój szef chce JavaScript, ale ty lubisz Javę, kompilator krzyżowy przekształci całą twoją statycznie wpisywaną Javę w zminiaturyzowany JavaScript, gotowy do uruchomienia w przeglądarce. Po co walczyć, skoro technologia nas wspiera?
Dzisiaj interesująca akcja toczy się w frameworkach. Kiedy usiadłem z innymi członkami wydziału na Uniwersytecie Johnsa Hopkinsa, aby zaplanować nowy kurs, frameworki zdominowały rozmowę. Czy Angular jest lepszy od Embera? Czy Node.js to wszystko?
Zaplanowaliśmy kurs, który miałby zbadać architekturę najważniejszych pakietów oprogramowania, które są podstawą Internetu. To było centrum akcji, godne kursu ankietowego, który miałby zbadać architekturę najważniejszych pakietów oprogramowania stanowiących opokę dzisiejszego Internetu.
W tym sensie frameworki są nowymi językami programowania. To w nich znajdują się najnowsze pomysły, filozofie i praktyczne aspekty współczesnego kodowania. Niektóre z nich gasną, ale wiele staje się nowym fundamentalnym budulcem programowania. Oto siedem aspektów napędzających trend frameworków — i sprawiających, że frameworki stają się nowym ulubionym miejscem walk nerdów.
Większość kodowania to łączenie API
Był czas, kiedy pisanie oprogramowania oznaczało wykorzystanie całej swojej wiedzy o języku programowania, aby wycisnąć jak najwięcej z kodu. Miało sens opanowanie złożoności wskaźników, funkcji i zakresu – jakość kodu zależała od tego, czy robiło się to dobrze. W dzisiejszych czasach automatyzacja załatwia wiele z tych spraw. Jeśli zostawisz w kodzie bezwartościowe instrukcje, nie martw się. Kompilator usuwa martwy kod. Jeśli pozostawisz pointery, garbage collector prawdopodobnie to rozgryzie.
Plus, praktyka kodowania jest teraz inna. Większość kodu to teraz długa linia wywołań API. Istnieje sporadyczne przeformatowanie danych między wywołaniami API, ale nawet te zadania są zwykle obsługiwane przez inne interfejsy API. Nieliczni szczęśliwcy mogą pisać sprytny, walący bitami, żonglujący wskaźnikami kod do wnętrzności naszych maszyn, ale większość z nas pracuje z wyższymi warstwami. Po prostu uruchamiamy potoki pomiędzy interfejsami API.
Z tego powodu ważniejsze jest zrozumienie, jak zachowuje się API i co może zrobić. Jakie struktury danych akceptuje? Jak zachowują się algorytmy, gdy zbiór danych się powiększa? Pytania takie jak te są bardziej kluczowe dla dzisiejszego programowania niż te dotyczące składni czy języka. Rzeczywiście, istnieje obecnie wiele narzędzi, które ułatwiają wywoływanie procedur w jednym języku z innego. Na przykład, stosunkowo łatwo jest połączyć biblioteki C z kodem Java. Zrozumienie API jest tym, co się liczy.
Na ramionach gigantów warto stanąć
Wyobraź sobie, że zostałeś uczniem Erlanga lub innego nowego języka. Zdecydowałeś, że oferuje on najlepszą platformę do pisania stabilnych, wolnych od błędów aplikacji. Jest to miły sentyment, ale przepisanie całego kodu dostępnego dla Javy lub PHP na Twój najnowszy język może zająć lata. Jasne, twój kod może okazać się dramatycznie lepszy, ale czy jest to warte dodatkowego czasu?
Frameworki pozwalają nam wykorzystać ciężką pracę tych, którzy byli przed nami. Może nam się nie podobać architektura, którą wybrali i możemy się spierać o szczegóły implementacji, ale bardziej efektywne jest stłumienie naszych skarg i znalezienie sposobu na życie z różnicami. O wiele łatwiej jest odziedziczyć wszystkie dobre i złe strony bazy kodu poprzez framework. Wybierając drogę macho, pisząc wszystko samemu w swoim ulubionym nowym języku, a nie w jednym z jego bardziej popularnych frameworków, nie będziesz mógł cieszyć się kremem swojego nowego wyboru tak szybko, jak po prostu zdać się na twórców frameworków i ich API.
Znajomość architektury jest tym, co się liczy, a nie składni
Gdy większość kodowania to łączenie wywołań API, nie ma zbyt wiele korzyści z uczenia się idiosynkrazji języka. Jasne, można zostać ekspertem od tego, jak Java inicjalizuje statyczne pola w obiektach, ale o wiele lepiej byłoby dowiedzieć się, jak wykorzystać moc Lucene lub JavaDB, czy też innej kupy kodu. Można spędzić miesiące grokking optymalizacji procedur kompilatorów Objective-C, ale poznanie tajników najnowszej biblioteki Apple core naprawdę sprawi, że twój kod będzie krzyczeć. O wiele dalej zajdziesz ucząc się drobiazgowych szczegółów frameworka niż składni języka, na którym ten framework się opiera.
Większość naszego kodu spędza większość czasu w wewnętrznych pętlach bibliotek. Poprawne opanowanie szczegółów języka może pomóc, ale wiedza o tym, co dzieje się w bibliotekach, może się bardzo opłacić.
Algorytmy dominują
Nauczenie się języka programowania może pomóc w żonglowaniu danymi ukrytymi w zmiennych, ale to tylko zabierze cię tak daleko. Prawdziwą przeszkodą jest uzyskanie poprawnych algorytmów, a te są zwykle definiowane i implementowane przez frameworki.
Wielu programistów rozumie, że spędzanie czasu na ponownej implementacji standardowych algorytmów i struktur danych jest niebezpieczne i marnotrawne. Jasne, możesz być w stanie dostroić je trochę do swoich potrzeb, ale ryzykujesz popełnienie subtelnych błędów. Frameworki były szeroko testowane przez lata. Reprezentują one naszą wspólną inwestycję w infrastrukturę oprogramowania. Nie ma zbyt wielu przykładów na to, kiedy ma sens „zejście z sieci”, odrzucenie na bok ciężkiej pracy innych i zbudowanie algorytmicznej kabiny własnymi rękami.
Właściwym podejściem jest studiowanie frameworków i uczenie się, jak z nich korzystać, aby uzyskać jak najlepsze korzyści. Jeśli wybierzesz niewłaściwą strukturę danych, możesz zmienić liniowe zadanie w takie, które zajmuje czas, który jest kwadratową funkcją rozmiaru danych wejściowych. To duży kłopot, gdy już się rozejdzie po sieci.