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

160

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ść?

Dan
źródło
94
Zacząłem programować w Fortranie pod koniec 1966 roku, więc miałem dużo czasu, aby przemyśleć dokładnie ten problem. Jeśli kiedykolwiek spotkasz się z odpowiedzią wiarygodną nawet w 50%, daj mi znać. Tymczasem pomyśl o prawie pewnej nieuchronnej nieuchronności jako o „bezpieczeństwie pracy” :)
John Forkosh,
11
Nic nie trwa wiecznie w inżynierii oprogramowania. Tylko HOST w bankach i ponieważ nikt nie odważy się zaktualizować tak krytycznych systemów. Cóż, myślę, że program działający w Voyagerze również się liczy.
Laiv
9
@Laiv Jakiś czas temu pracowałem nad aplikacjami do przelewów dla Bankers Trust przy użyciu wiadomości błyskawicznych działających na Vax / VMS. Kilka lat później Swift eol'ed (wycofany z eksploatacji) całe wsparcie VMS. Chłopcze, czy to spowodowało pewne problemy ... i zapewniło mi kolejny kontrakt w BTCo. Jak powiedziałem wyżej, „bezpieczeństwo pracy” :). W każdym razie mam na myśli to, że nawet krytyczne zastosowania na rynkach finansowych nie są odporne na starzenie się.
John Forkosh
102
Co powiesz na „Napisz kod, który zrozumie następny programista”? Jeśli i kiedy kod stanie się przestarzały do ​​tego stopnia, że ​​będzie musiał znaleźć programistę, aby go zaktualizować, najlepszym scenariuszem będzie zrozumienie tego, co robi Twój kod (i być może, dlaczego podjęto pewne decyzje).
David Starkey,
38
Wystarczy użyć zwykłego starego HTML, bez JS, bez wtyczek, nic fantazyjnego. Jeśli działa w Lynx, jest dobry na zawsze.
Gajusz

Odpowiedzi:

132

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.

amon
źródło
4
Aplikacje na dużą skalę są obecnie nie do utrzymania w waniliowej wersji js. ES6 już w jakiś sposób rozwiązuje problem, ale istnieje powód, dla którego popularność flow lub TypeScript zyskuje na popularności.
Andy,
34
@DavidPacker Oczywiście, TypeScript itp. Są świetne i ułatwiają programowanie. Ale jak tylko przedstawię proces kompilacji, wszystkie narzędzia wymagane do procesu kompilacji stają się zależne: NodeJS, Gulp, NPM - kto mówi, że NPM będzie nadal dostępny za 20 lat? Będę musiał uruchomić własny rejestr, aby się upewnić. To nie jest niemożliwe. Ale w pewnym momencie lepiej puścić rzeczy, które ułatwiają rozwój tylko natychmiast, ale nie na dłuższą metę.
amon
30
@DavidPacker Istnieje wiele dynamicznych języków i, co zaskakujące, wiele udanych systemów zostało zbudowanych za pomocą Smalltalk, Ruby, Perl, Python, nawet z PHP i JS. Podczas gdy języki typowane statycznie są łatwiejsze w utrzymaniu, podczas gdy języki dynamiczne są lepsze do szybkiego prototypowania, nie jest niemożliwe napisanie konserwowalnego JS. W przypadku braku kompilatora, wysoka mediana umiejętności w zespole, kunszt i dodatkowy nacisk na przejrzystą organizację kodu stają się jeszcze bardziej istotne. Osobiście uważam, że typy ułatwiają wszystko, ale nie są srebrną kulą.
amon
4
Czy właśnie przeczytałem „weź usb i przetestuj na innym komputerze”? Dlaczego nie po prostu rozkręcić virtualbox lub po prostu użyć trybu incognito (z wyłączonym ethX).
Kyslik,
5
Nie jestem pewien, czy waniliowy JS będzie pewny za 20 lat. Jego historia była kamienista i eksperymentalna, a po drodze zebrała sporo cruft, nawet jeśli okazała się zachwycającym i skutecznym językiem (ja osobiście wolę JavaScript lub TypeScript). Nietrudno wyobrazić sobie, że dostawcy mogą chcieć porzucić część lub całość tego cruftu, niezależnie od tego, czy oznacza to rozpoczęcie oferowania nowego alternatywnego języka - jak Google zdawał się proponować z Dartem, jednak nie wydaje się, aby to wszystko poszło nigdzie —Lub poprzez wycofanie, a następnie wyeliminowanie części JS.
KRyan
178

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.

Avner Shahar-Kashtan
źródło
141
Przepraszam, ale muszę to powiedzieć. Jeśli korzystasz z Oracle, zastrzelisz wszystkich w stopie w odniesieniu do „łatwości w obsłudze”. Oracle nie jest wcale łatwe do pracy. Ogromna funkcjonalność, którą SQL Server, PostgreSQL i prawdopodobnie nawet MySQL upraszczają, Oracle albo całkowicie nie ma, albo zbytnio utrudnia. Nigdy nie mam tylu głupich problemów z innymi bazami danych, jak z Oracle; nawet samo założenie klienta to ogromny ból w tyłku. Nawet Googlowanie jest trudne. Jeśli chcesz „łatwo pracować”, trzymaj się z dala od Oracle.
jpmc26,
4
+1 za utrzymanie danych tak prosto, jak to możliwe. Użyj do tego standardowego SQL, np. Użyj ZŁĄCZA ZEWNĘTRZNEGO zamiast operatora + dla Oracle . Używaj prostych układów tabel. Nie normalizuj swoich tabel do absolutnego maksymalnego poziomu. Zdecyduj, czy niektóre tabele mogą zawierać nadmiarowe dane, czy naprawdę musisz utworzyć nową tabelę, aby każda wartość istniała tylko raz. Czy procedury składowane są specyficzne dla dostawcy ? Jeśli tak, nie używaj ich. Nie używaj najgorętszej funkcji w Twoim obecnym języku: widziałem więcej programów COBOL bez funkcji OOP niż z nimi. I to jest całkowicie w porządku.
some_coder
3
@ jpmc26 Zgadzam się z twoimi opiniami na temat Oracle, ale jak powiedziałem, „łatwa w obsłudze” niekoniecznie jest tutaj głównym wymogiem. Wolę solidnie obsługiwaną platformę, nawet jeśli praca z nią jest uciążliwa. Bo kiedy amortyzowane przez 20 lat, nie jest tak źle.
Avner Shahar-Kashtan
8
Rzeczywiście unikaj Oracle. Jedynym obecnie istniejącym DB, który prawdopodobnie nie będzie złym wyborem za 20 lat, jest Postgresql.
Joshua
3
Chciałbym dodać, że świetny system DBMS typu open source jest lepszy, ponieważ istnieje spora szansa, że ​​nie umrą. Jeśli Oracle przestanie zarabiać za 10 lat, to za 11 lat zniknie. PostreSQL wydaje się najlepszym koniem do postawienia zakładu.
Shautieh
36

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!

Arseni Mourzenko
źródło
4
Adaptacja do różnych rozmiarów ekranu to ogólny problem. Mobilność jest w tej chwili przesadzona, ale jeśli patrzysz na tę stronę w oknie przeglądarki na pełnym ekranie na ekranie o wystarczającej rozdzielczości, jest dużo pustej (zmarnowanej) przestrzeni. Zmiana układu i sposób prezentacji informacji w celu najlepszego wykorzystania dostępnych pikseli nigdy tak naprawdę nie nastąpił w inteligentny sposób. Mobile dało to do zrozumienia. Ale myślenie w innym kierunku może być ważniejsze dla omawianego pytania.
null
9
@ null: chociaż zgadzam się z twoim komentarzem, strony StackExchange mogą nie być najlepszą ilustracją twojego punktu widzenia. Biorąc pod uwagę dane do wyświetlenia, uważam, że projektanci / programiści StackExchange wykonali świetną robotę, wyświetlając je tak, jak muszą być wyświetlane, w tym na dużych monitorach. Nie możesz poszerzyć głównej kolumny, ponieważ tekst stałby się znacznie trudniejszy do odczytania, i nie możesz użyć wielu kolumn, ponieważ nie będzie ładnie wyglądać w przypadku krótkich pytań i odpowiedzi.
Arseni Mourzenko
Innym dobrym przykładem jest zdarzenie „najechania”, które często było używane w systemach menu. Wiele z tych menu kończy się niepowodzeniem w przypadku urządzeń dotykowych.
Justas
Masz 110% (lub więcej) racji co do urządzeń i mogę ci podać przykłady sprzed kilkudziesięciu lat. Pod koniec lat 80. pracowałem nad aplikacjami CICS działającymi na komputerach mainframe IBM i synchronicznych terminalach 3270. Region CICS jest w pewnym sensie analogiczny do aplikacji po stronie serwera, wysyłając jednocześnie pełne ekrany danych do terminali synchronicznych, które są zatem analogiczne do przeglądarek dedykowanych urządzeń. A programowanie w CICS było może 80% Cobol, 20% PL / 1. Oba te języki są obecnie w większości przestarzałe, a pojawienie się uniksowych stacji roboczych (Sun i Apollo) na początku lat 90. prawie całkowicie zabiło CICS
John Forkosh
31

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.

Coteyr
źródło
2
„Gdybyś musiał teraz zmienić bazy danych, czy mógłbyś” Nie jest to prawie niemożliwe, jeśli zrobisz coś więcej niż CRUD w jednym wierszu na raz.
jpmc26,
1
Wiele ORM jest agnostycznych dla bazy danych. Mógłbym podać jeden z projektów, nad którymi pracuję nad gaurentee, i bez problemu mogłem przejść z SQLLite na MySql i Postgre.
coteyr
5
I ORM przestają być bardzo dobrymi narzędziami do pracy, gdy wykonujesz więcej niż zwykłą CRUD na jednym rekordzie naraz. Dlatego to zakwalifikowałem. Próbowałem. Wraz ze wzrostem złożoności zapytań nawet najlepsze ORM stają się bardziej kłopotliwe niż zwykłe pisanie zapytania, a nawet jeśli wprowadzisz je w życie, dość szybko znajdziesz się przy użyciu funkcji lub optymalizacji specyficznych dla bazy danych.
jpmc26
1
Zdefiniuj „kompleks”. Czy to była operacja masowa? Czy zawierał zapytania dotyczące okien? Podzapytania? CTE? Związki? Złożone warunki grupowania? Skomplikowana matematyka w każdym rzędzie i agregatach? Ile łączy w jednym zapytaniu? Jakie rodzaje złączeń? Ile wierszy przetworzono jednocześnie? Trzeba przyznać, że mówienie czegokolwiek ponad CRUD w jednym wierszu (uwaga, oznacza to jeden wiersz na zapytanie, a nie na żądanie internetowe itp.) Jest trochę hiperbolą, ale droga do tego, kiedy ORM staje się większym problemem niż jest warta, jest znacznie krótsza niż myślisz. Kroki niezbędne do poprawnego działania zapytania są bardzo często specyficzne dla bazy danych.
jpmc26
4
„Czy baza danych aplikacji jest agnostyczna? Gdybyś musiał teraz przełączyć bazy danych, prawda? Czy Twój język logiczny jest agnostyczny. Jeśli musiałbyś teraz przepisać aplikację w zupełnie nowym języku, prawda?” - To jest absolutnie straszna rada! Nie ograniczaj się sztucznie do tego, co uważasz za największy wspólny mianownik języków programowania lub baz danych - zmusi cię to do ciągłego odkrywania koła. Zamiast tego spróbuj znaleźć NATURALNY sposób wyrażenia pożądanego zachowania w wybranym języku programowania i wybranej bazie danych.
fgp
12

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ć.

Jonathan Vanasco
źródło
11
Trzeba też wziąć pod uwagę bezpieczeństwo. 20-letni nieobsługiwany system operacyjny będzie prawdopodobnie pełen luk bezpieczeństwa. Pracowałem dla firmy i odziedziczyłem ten problem. Agencja rządowa, starożytne systemy operacyjne (wszystkie na długo zwirtualizowane, na szczęście), ale był to ogromny problem, a aktualizacja była prawie niemożliwa ze względu na konieczność całkowitego przepisania oprogramowania (setki pojedynczych skryptów PHP z kodem spaghetti, z których każdy miał wywołania bazy danych zakodowane na stałe, używając przestarzałych funkcji, których nowy sterownik nie obsługiwał / wzdrygnął się).
Jeśli pójdziesz drogą systemu operacyjnego, możesz mieć co najwyżej nadzieję, że łatki bezpieczeństwa zostały zastosowane i że przyszli opiekunowie będą mogli chronić rzeczy w warstwie sieciowej. Aby zaplanować, że rzeczy będą działać w ten sposób w dłuższej perspektywie (zwłaszcza przy braku dużego budżetu, ponieważ OP jest studentem), zasadniczo musisz zaakceptować, że twoja aplikacja i serwer w końcu staną się niepewne. Na przykład za 20 lat będą ostatecznie znane znane exploity dla wersji SSL na serwerze ... ale ten system operacyjny może nie być kompatybilny z wersjami openssl za 10 lat. Chodzi o zminimalizowanie kompromisów.
Jonathan Vanasco
@FighterJet, zawsze możesz uruchomić zaporę ogniową na obsługiwanym systemie operacyjnym, wtedy masz niewiele ryzyka oprócz zastrzyków SQL itp., Które i tak powinieneś był zakodować.
Ian
@Ian: Chciałbym. Była zapora ogniowa. Ale nie napisałem kodu, odziedziczyłem go. I tak, były tysiące luk w zabezpieczeniach SQL, które chciałbym naprawić, ale prawdziwy problem polegał na tym, że kod był zależny od konkretnej wersji PHP4 (która była przestarzała na zawsze i jest pełna luk bezpieczeństwa) oraz konkretna wersja sterownika bazy danych (która nie działała na nowszych systemach operacyjnych), która uniemożliwiła nam aktualizację do nowszej wersji bazy danych ... chodzi o to, że poleganie na czymś takim samym nie zawsze działa. Powiedzmy, że cieszę się, że już tam nie pracuję.
1
@FighterJet To naprawdę dobry przykład tego, o czym chciałem rozmawiać. W rezultacie odziedziczyłeś kod, który działa tylko na określonej wersji PHP4 i sterownik, który działa tylko na określonym systemie operacyjnym ... więc nie możesz zaktualizować serwera. Nie zalecałbym, aby ktokolwiek to robił, ale tak się dzieje. -- dużo. FWIW, zgadzam się z tobą, ale chciałem, aby moja odpowiedź sprzyjała myśleniu wokół tego rodzaju scenariuszy, a nie zalecaniu.
Jonathan Vanasco
6

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ę”).

usr
źródło
o historii kompatybilności wstecznej .net - nie sądzę, że widziałem aplikację Java, która prosiłaby o starszą wersję Java, w przeciwieństwie do tego. To może się zmienić w Javie 9 lub nowszej, ale jeszcze tego nie widziałem.
eis
Jest niesamowicie kompatybilny w praktyce, a instalacja starszej wersji obok siebie nie stanowi problemu. Zauważ też, że .NET BCL jest moim zdaniem 10-100x większy niż wbudowane klasy Java.
usr
kompatybilność wsteczna oznacza, że ​​nie powinno być potrzeby instalowania również starszej wersji. Ale odbiegamy od pierwotnego pytania, nie jest to tak naprawdę istotne dla OP.
eis
0

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.

Jonathan van de Veen
źródło
1
Ramki i ramki iframe są bardzo dobrze zdefiniowane w specyfikacji HTML. Co czyni je nieodpowiednimi?
curiousdannii
3
@curiousdannii: Nie chodzi tylko o użycie ramek iframe (ramki nie są już obsługiwane w HTML5), ale o użycie ramek i ramek iframe do asynchronicznego ładowania treści za pomocą skryptów itp. Może teraz działać świetnie, ale zawsze będzie działać podlegać zmianom bezpieczeństwa.
Jonathan van de Veen
-2

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.

Zenilogix
źródło