Tworzenie aplikacji internetowych na długi okres (ponad 20 lat)

Obecnie opracowuję aplikację internetową do planowania rządowego. Aplikacja działa głównie w przeglądarce, używając ajax do ładowania i zapisywania danych.

Zrobię wstępny rozwój, a następnie ukończę (to praca studencka). Następnie reszta zespołu doda sporadycznie funkcję w razie potrzeby. Wiedzą, jak kodować, ale w większości są ekspertami od planowania przestrzennego.

Biorąc pod uwagę tempo zmian technologii Javascript, jak mogę napisać kod, który będzie działał jeszcze za 20 lat? W szczególności, jakich bibliotek, technologii i pomysłów projektowych powinienem używać (lub unikać), aby zabezpieczyć swój kod na przyszłość?

Planowanie oprogramowania na taką długość życia jest trudne, ponieważ nie wiemy, co przyniesie przyszłość. Trochę kontekstu: Java została opublikowana w 1995 roku, 21 lat temu. XmlHttpRequest po raz pierwszy stał się dostępny jako zastrzeżone rozszerzenie dla programu Internet Explorer 5, opublikowanego 1999, 17 lat temu. Stało się około 5 lat, zanim stało się dostępne we wszystkich głównych przeglądarkach. 20 lat, na które starasz się patrzeć w przyszłość, to prawie czas, w którym istniały bogate aplikacje internetowe.

Od tego czasu niektóre rzeczy z pewnością pozostały takie same. Wiele wysiłku włożono w standaryzację, a większość przeglądarek jest zgodna z różnymi standardami. Witryna, która działała w różnych przeglądarkach 15 lat temu, nadal będzie działać tak samo, pod warunkiem, że działała, ponieważ była ukierunkowana na wspólny podzbiór wszystkich przeglądarek, a nie dlatego, że używała obejść dla każdej przeglądarki.

Inne rzeczy przychodziły i odchodziły - przede wszystkim Flash. Flash miał wiele problemów, które doprowadziły do ​​jego śmierci. Co najważniejsze, była kontrolowana przez jedną firmę. Zamiast konkurencji wewnątrz platformy Flash, istniała konkurencja między Flash a HTML5 - i HTML5 wygrał.

Z tej historii możemy zebrać kilka wskazówek:

• Prostota: rób to, co działa teraz, bez konieczności korzystania z obejść. Takie zachowanie najprawdopodobniej pozostanie dostępne długo w przyszłości z powodów kompatybilności wstecznej.

• Unikaj polegania na zastrzeżonych technologiach i preferuj otwarte standardy.

Dzisiejszy świat JavaScript jest stosunkowo niestabilny, z dużą liczbą bibliotek i frameworków. Jednak prawie żaden z nich nie będzie miał znaczenia za 20 lat - jedynym „szkieletem”, który jestem pewien, że do tego czasu będzie nadal używany, jest Vanilla JS .

Jeśli chcesz użyć biblioteki lub narzędzia, ponieważ naprawdę ułatwia to programowanie, najpierw upewnij się, że jest on oparty na dobrze obsługiwanych standardach. Następnie należy pobrać bibliotekę lub narzędzie i dołączyć je do kodu źródłowego. Twoje repozytorium kodu powinno zawierać wszystko, co jest potrzebne do uruchomienia systemu. Wszystko, co zewnętrzne, jest zależnością, która może się zepsuć w przyszłości. Ciekawym sposobem na przetestowanie tego jest skopiowanie kodu na pamięć USB, przejście do nowego komputera z innym systemem operacyjnym, odłączenie go od Internetu i sprawdzenie, czy możesz uruchomić interfejs użytkownika. Tak długo, jak twój projekt składa się ze zwykłego HTML + CSS + JavaScript oraz być może niektórych bibliotek, prawdopodobnie przejdziesz.

Jeszcze ważniejsze niż przetrwanie twojego kodu przez 20 lat jest to, że twoje dane przetrwają przez 20 lat. Są szanse, że to jest warte zachowania. Jeśli dane są łatwe w obsłudze, zbudowanie na nich alternatywnego systemu z nowszą technologią będzie łatwe.

• Zacznij więc od przejrzystego i dobrze udokumentowanego modelu danych.
• Użyj sprawdzonego, dobrze obsługiwanego systemu baz danych, takiego jak Oracle ^[1] lub SQL Server.
• Używaj podstawowych funkcji, nie próbuj wciskać nowych, efektownych.
• Wolę proste niż sprytne .
• Zaakceptuj, że łatwość konserwacji w przyszłości może nastąpić kosztem takich aspektów, jak wydajność. Na przykład możesz ulec pokusie użycia procedur przechowywanych, ale mogą one ograniczyć przyszłą konserwację, jeśli uniemożliwiają migrację systemu do prostszego rozwiązania pamięci masowej.

Gdy już to zrobisz, przygotowywanie aplikacji na przyszłość jest prostsze, ponieważ jest to otoczka wokół modelu danych i można ją wymienić, jeśli w ciągu 10 lat nikt już nie będzie korzystał z Javascript, i musisz przeprowadzić migrację aplikacji do WASM czy coś. Utrzymanie modułowości i mniej współzależności pozwala na łatwiejszą konserwację w przyszłości.

^[1] Większość komentarzy do tej odpowiedzi zdecydowanie sprzeciwia się używaniu Oracle do DB, powołując się na wiele całkowicie uzasadnionych powodów, dla których Oracle jest trudny w pracy, ma stromą krzywą uczenia się i koszty instalacji. Są to całkowicie uzasadnione obawy przy wyborze Oracle jako bazy danych, ale w naszym przypadku nie szukamy bazy danych ogólnego przeznaczenia, ale takiej, w której podstawową kwestią jest łatwość konserwacji . Oracle istnieje na rynku od późnych lat 70-tych i prawdopodobnie będzie wspierany przez wiele lat, a istnieje ogromny ekosystem konsultantów i opcji wsparcia, które pomogą Ci utrzymać go w działaniu. Czy dla wielu firm to zawyżony bałagan? Pewnie. Ale czy utrzyma twoją bazę danych przez 20 lat ? Całkiem prawdopodobne.

Poprzednia odpowiedź Amona jest świetna, ale są jeszcze dwa dodatkowe punkty, o których nie wspomniano:

• Nie chodzi tylko o przeglądarki; urządzenia też mają znaczenie.

  amon wspomina, że „strona internetowa, która 15 lat temu działała w różnych przeglądarkach, nadal będzie działać tak samo” , co jest prawdą. Spójrz jednak na witryny utworzone nie piętnaście, ale dziesięć lat temu, które po utworzeniu działały w większości przeglądarek dla większości użytkowników. Obecnie duża część użytkowników w ogóle nie będzie mogła korzystać z tych witryn, nie dlatego, że zmieniły się przeglądarki, ale dlatego, że zrobiły to urządzenia. Strony te wyglądałyby okropnie na małych ekranach urządzeń mobilnych i ostatecznie nie działałyby wcale, gdyby programiści zdecydowali się na clickzdarzenie JavaScript , nie wiedząc, że tapto wydarzenie jest również ważne.

• Skupiasz się na niewłaściwym temacie.

  Zmiany technologiczne to jedno, ale ważniejsze są zmiany wymagań . Produkt może wymagać skalowania lub może wymagać dodatkowych funkcji lub zmiany obecnych funkcji.

  Nie ma znaczenia, co stanie się z przeglądarkami, urządzeniami, W3C lub ... czymkolwiek.

  Jeśli napiszesz kod w sposób umożliwiający jego refaktoryzację , produkt będzie ewoluował wraz z technologią.

  Jeśli napiszesz kod w sposób, którego nikt nie rozumie i nie konserwuje, technologia nie ma znaczenia: wszelkie zmiany środowiskowe i tak spowodują wyłączenie Twojej aplikacji, takie jak migracja do innego systemu operacyjnego, a nawet prosta sprawa, jak naturalny wzrost danych .

  Jako przykład pracuję w tworzeniu oprogramowania od dziesięciu lat. Spośród kilkudziesięciu projektów, były tylko dwa, które postanowiłem zmienić ze względu na technologię , a dokładniej, ponieważ PHP bardzo ewoluowało w ciągu ostatnich dziesięciu lat. To nie była nawet decyzja klienta: nie przejmowałby się mniej, gdyby strona korzystała z przestrzeni nazw lub zamknięć PHP. Jednak zmiany związane z nowymi wymaganiami i skalowalnością było wiele!

Nie planujesz trwać 20 lat. Prosty i prosty. Zamiast tego zmieniasz swoje cele na podział na przedziały.

Czy baza danych Twojej aplikacji jest agnostyczna? Gdybyś musiał teraz zmienić bazy danych, mógłbyś. Czy Twój język logiczny jest agnostyczny? Gdybyś teraz musiał przepisać aplikację w zupełnie nowym języku? Czy przestrzegasz dobrych wytycznych projektowych, takich jak SRP i DRY?

Mam projekty na żywo od ponad 20 lat i mogę powiedzieć, że wszystko się zmienia. Jak wyskakujące okienka. 20 lat temu możesz polegać na wyskakującym okienku, dziś nie możesz. XSS nie był czymś 20 lat temu, teraz musisz rozliczać się z CORS.

Więc upewnij się, że logika jest dobrze oddzielona i że unikniesz ŻADNEJ technologii, która zablokuje cię w kontaktach z konkretnym dostawcą.

Czasami może to być bardzo trudne. Na przykład .NET świetnie nadaje się do ujawniania logiki i metody adaptera bazy danych MSSQL, który nie ma odpowiedników w innych adapterach. MSSQL może dziś wydawać się dobrym planem, ale czy pozostanie tak przez 20 lat? Kto wie. Przykład obejścia tego problemu, aby warstwa danych była całkowicie oddzielona od innych części aplikacji. W najgorszym przypadku wystarczy ponownie zapisać całą warstwę danych, reszta aplikacji pozostanie nienaruszona.

Innymi słowy, pomyśl o tym jak o samochodzie. Twój samochód nie przetrwa 20 lat. Ale dzięki nowym oponom, nowemu silnikowi, nowej skrzyni biegów, nowym szybom, nowej elektronice itp. Ten sam samochód może być w ruchu przez bardzo długi czas.

Odpowiedzi @amon i kilka innych są świetne, ale chciałem zasugerować, aby spojrzeć na to z innej perspektywy.

Współpracowałem z dużymi producentami i agencjami rządowymi, którzy polegali na programach lub bazach kodu używanych od ponad 20 lat i wszystkie łączyły jedno - firma kontrolowała sprzęt. Posiadanie czegoś działającego i rozszerzalnego przez ponad 20 lat nie jest trudne, gdy kontrolujesz, co się dzieje. Pracownicy tych grup opracowali kod na nowoczesnych komputerach, które były setki razy szybsze niż maszyny do wdrażania ... ale maszyny do wdrażania zostały zamrożone na czas.

Twoja sytuacja jest skomplikowana, ponieważ witryna oznacza, że ​​musisz zaplanować dwa środowiska - serwer i przeglądarkę.

Jeśli chodzi o serwer, masz dwie ogólne możliwości:

• Różne funkcje obsługi mogą polegać na systemie operacyjnym, który może być znacznie szybszy, ale oznacza, że ​​system operacyjny może wymagać „zatrzymania się na czas”. W takim przypadku należy przygotować kopie zapasowe instalacji systemu operacyjnego na serwerze. Jeśli coś się zawiesi w ciągu 10 lat, nie chcesz, aby ktoś oszalał, próbując ponownie zainstalować system operacyjny lub przepisać kod, aby działał w innym środowisku.

• Korzystaj z bibliotek wersjonowanych w danym języku / frameworku, które są wolniejsze, ale mogą być spakowane w środowisku wirtualnym i prawdopodobnie działają w różnych systemach operacyjnych lub architekturach.

Jeśli chodzi o przeglądarkę, musisz hostować wszystko na serwerze (tzn. Nie możesz używać globalnego CDN do hostowania plików). Możemy założyć, że przyszłe przeglądarki będą nadal uruchamiały HTML i JavaScript (przynajmniej dla kompatybilności), ale to naprawdę zgadywanie / założenie i nie można tego kontrolować.

Trzon większości aplikacji stanowią dane. Dane są wieczne. Kod jest bardziej zbywalny , zmienny, plastyczny. Dane muszą jednak zostać zachowane. Skoncentruj się więc na stworzeniu naprawdę solidnego modelu danych. Utrzymuj schemat i dane w czystości. Przewiduj, że nowa aplikacja może zostać zbudowana na tej samej bazie danych.

Wybierz bazę danych, która może egzekwować ograniczenia integralności. Z biegiem czasu niewymuszone ograniczenia są naruszane. Nikt nie zauważa. Maksymalnie wykorzystuj udogodnienia, takie jak klucze obce, unikalne ograniczenia, ograniczenia sprawdzania i ewentualnie wyzwalacze do sprawdzania poprawności. Istnieje kilka sztuczek polegających na nadużywaniu indeksowanych widoków w celu egzekwowania ograniczeń unikatowości między tabelami.

Może więc musisz zaakceptować fakt, że aplikacja zostanie przepisana w pewnym momencie. Jeśli baza danych jest czysta, migracja będzie niewielka. Migracje są niezwykle kosztowne pod względem robocizny i spowodowanych wad.

Z technologicznego punktu widzenia dobrym pomysłem może być umieszczenie większości aplikacji na serwerze, a nie w formie JavaScript na kliencie. Prawdopodobnie będziesz w stanie uruchomić tę samą aplikację w tym samym wystąpieniu systemu operacyjnego przez bardzo długi czas dzięki wirtualizacji . To nie jest naprawdę miłe, ale jest to gwarancja, że ​​aplikacja będzie działać za 20 lat bez kosztownej konserwacji i kosztów sprzętu. Robiąc to, będziesz mieć co najmniej bezpieczny i tani powrót do działania starego, działającego kodu.

Ponadto uważam, że niektóre stosy technologii są bardziej stabilne niż inne . Powiedziałbym, że .NET ma obecnie najlepszą możliwą historię kompatybilności wstecznej. Microsoft jest poważny. Java i C / C ++ są również naprawdę stabilne. Python udowodnił, że jest bardzo niestabilny przy przełamywaniu zmian w Pythonie 3. JavaScript wydaje mi się dość stabilny, ponieważ zerwanie z Internetem nie jest opcją dla żadnego dostawcy przeglądarki. Prawdopodobnie nie powinieneś polegać na niczym eksperymentalnym lub funky. („Funky” definiuje się jako „Wiem, kiedy to widzę”).

Inne odpowiedzi mają sens. Uważam jednak, że komentarze na temat technologii klienta są skomplikowane. Pracuję jako programista przez ostatnie 16 lat. Z mojego doświadczenia wynika, że ​​dopóki kod klienta jest intuicyjny, wszystko powinno być w porządku. Więc nie ma „hacków” z ramkami / ramkami iframe itp. Używaj tylko dobrze zdefiniowanych funkcji w przeglądarkach.

Zawsze możesz używać trybów zgodności w przeglądarkach, aby działały.

Aby to udowodnić, zaledwie kilka miesięcy temu naprawiłem tysiącletni błąd w kodzie javascript dla klienta, który od 17 lat prowadzi swoją aplikację internetową. Nadal działa na najnowszych komputerach, najnowszej bazie danych, najnowszym systemie operacyjnym.

Wniosek: zachowaj prostotę i czystość, a wszystko powinno być w porządku.

Kilka aksjomatów:

• Prawda przetrwa. W tym kontekście byłyby to algorytmy i modele danych - takie, które zgodnie z prawdą reprezentują „co” i „jak” obszaru problemu. Chociaż zawsze istnieje możliwość udoskonalenia i ulepszenia lub ewolucji samego problemu.
• Języki ewoluują. Dotyczy to zarówno języków komputerowych, jak i języków naturalnych.
• Wszystkie technologie są podatne na starzenie się. Niektóre technologie mogą potrwać dłużej niż inne

Najbardziej stabilne technologie i standardy (najmniej narażone na utratę przydatności) są zwykle niezastrzeżone i zostały powszechnie przyjęte. Im szersze przyjęcie, tym większa bezwładność wobec prawie każdej formy zmiany. Zastrzeżone „standardy” są zawsze podatne na fortuny i kaprysy ich właściciela i sił konkurencyjnych.

Dwadzieścia lat to bardzo długi czas w branży komputerowej. Pięć lat to bardziej realistyczny cel. Za pięć lat cały problem, który twoja aplikacja ma rozwiązać, może zostać całkowicie przedefiniowany.

Kilka przykładów do zilustrowania:

C i C ++ istnieją już od dłuższego czasu. Mają implementacje na niemal każdej platformie. C ++ wciąż ewoluuje, ale „uniwersalne” funkcje (dostępne na wszystkich platformach) są prawie całkowicie gwarantowane, że nigdy nie będą przestarzałe.

Flash prawie stał się uniwersalnym standardem, ale jest zastrzeżony. Korporacyjne decyzje o nieobsługiwaniu go na popularnych platformach mobilnych w gruncie rzeczy skazały go wszędzie - jeśli tworzysz strony internetowe, chcesz, aby Twoje treści były dostępne na wszystkich platformach; nie chcesz przegapić dużego rynku, jakim stała się sieć komórkowa.

WinTel (Windows / x86), mimo że jest własnością Microsoft i Intela, zaczął na mniej niż optymalnej platformie (16-bitowy wewnętrzny / 8-bitowy zewnętrzny 8088 vs. współczesny Apple Macintosh 32-bitowy wewnętrzny / 16-bitowy zewnętrzny 68000) i erozja Apple na rynku konsumenckim pozostaje de facto wyborem dla platform biznesowych. Przez cały ten czas (25 lat) zaangażowanie w kompatybilność wsteczną zahamowało przyszły rozwój i wzbudziło spore przekonanie, że to, co działało na starym urządzeniu, będzie nadal działać na nowym.

Końcowe przemyślenia

JavaScript może nie być najlepszym wyborem do implementacji logiki biznesowej. Ze względu na integralność i bezpieczeństwo danych logika biznesowa powinna być wykonywana na serwerze, więc JavaScript po stronie klienta powinien być ograniczony do zachowania interfejsu użytkownika. Nawet na serwerze JavaScript może nie być najlepszym wyborem. Chociaż jest łatwiejszy w obsłudze niż inne stosy (Java lub C #) w przypadku małych projektów, brakuje formalności, która może pomóc w pisaniu lepszych, lepiej zorganizowanych rozwiązań, gdy sprawy stają się bardziej złożone.