Uzun ömür için web uygulamaları geliştirmek (20+ yıl)

Şu anda hükümet arazi planlaması için bir web uygulaması geliştiriyorum. Uygulama, veri yüklemek ve kaydetmek için ajax kullanarak çoğunlukla tarayıcıda çalışır.

İlk gelişmeyi yapacağım ve sonra mezun olacağım (bu bir öğrenci işi). Bundan sonra, ekibin geri kalanı arada sırada özelliği gerektiği gibi ekleyecektir. Kodlamayı biliyorlar, ama çoğunlukla arazi planlama uzmanı.

Javascript teknolojilerinin değişme hızını göz önüne alarak, 20 yıl sonra çalışmaya devam edecek kodu nasıl yazabilirim? Özellikle, kodumu ileride korumak için hangi kütüphaneleri, teknolojileri ve tasarım fikirlerini kullanmalıyım (veya kaçınmalıyım)?

Böyle bir kullanım ömrü için planlama yazılımı zordur, çünkü geleceğin neler taşıdığını bilmiyoruz. Bağlamın bir kısmı: Java 1995, 21 yıl önce yayınlandı. XmlHttpRequest, ilk olarak 1999, 17 yıl önce yayınlanan Internet Explorer 5 için tescilli bir eklenti olarak kullanıma sunuldu. Tüm büyük tarayıcılarda kullanıma sunulması yaklaşık 5 yıl aldı. Geleceğe bakmak istediğiniz 20 yıl, zengin web uygulamalarının var olduğu zamandan ibaret.

Bazı şeyler kesinlikle o zamandan beri aynı kaldı. Güçlü bir standardizasyon çabası olmuştur ve çoğu tarayıcı ilgili çeşitli standartlara uygundur. 15 yıl önce tarayıcılar arasında çalışan bir web sitesi, her tarayıcı için geçici çözümler kullandığı için değil, tüm tarayıcıların ortak alt kümesini hedef alması nedeniyle çalıştığı sürece, aynı şekilde çalışacaktır .

Diğer şeyler geldi ve gitti - en belirgin şekilde Flash. Flash'ın ölümüne yol açan çeşitli problemleri vardı. En önemlisi, tek bir şirket tarafından kontrol edildi. Flash platformundaki rekabet yerine, Flash ile HTML5 - ve HTML5 arasında rekabet vardı.

Bu tarihten itibaren birkaç ipucu toplayabiliriz:

• Basit tutun: Herhangi bir geçici çözüm kullanmak zorunda kalmadan, şu anda çalışanı yapın. Bu davranış, geriye dönük uyumluluk nedenleriyle gelecekte büyük olasılıkla uzun süre kalacaktır.

• Özel teknolojilere güvenmekten kaçının ve açık standartları tercih edin.

Günümüzde JavaScript dünyası, yüksek düzeyde kütüphaneler ve çerçeveler akışı ile nispeten değişkendir. Ancak, neredeyse hiçbiri 20 yıl içinde önemli olmayacak - o zamana kadar kullanılacağından emin olduğum tek “çerçeve” Vanilla JS .

Bir kütüphane veya araç kullanmak istiyorsanız, geliştirmeyi gerçekten çok kolaylaştırıyorsa, öncelikle bugünün iyi desteklediği standartlara dayandığından emin olun. Ardından kitaplığı veya aracı indirmeli ve kaynak kodunuza eklemelisiniz. Kod deponuz, sistemi çalıştırılabilir hale getirmek için gereken her şeyi içermelidir. Dışsal herhangi bir şey gelecekte kırılabilecek bir bağımlılıktır. Bunu test etmenin ilginç bir yolu, kodunuzu bir başparmak sürücüye kopyalamak, farklı bir işletim sistemine sahip yeni bir bilgisayara gitmek, internet bağlantısını kesmek ve ön planın çalışıp çalışmayacağını görmek. Projeniz düz HTML + CSS + JavaScript ve belki de bazı kütüphanelerden oluştuğu sürece, muhtemelen geçeceksiniz.

20 yıl boyunca hayatta kalan kodunuzdan daha da önemli olan, verilerinizin 20 yıl boyunca hayatta kalmasıdır. Muhtemelen, korunmaya değer bir şey bu. Verilerinizle çalışmak kolaysa, üzerine yeni teknolojiyle alternatif bir sistem oluşturmak kolay olacaktır.

• Öyleyse açık ve iyi belgelenmiş bir veri modeliyle başlayın.
• Oracle ^[1] veya SQL Server gibi kurulmuş, iyi desteklenen bir veritabanı sistemi kullanın .
• Temel özellikleri kullanın, gösterişli yenilerini sıkmaya çalışmayın.
• Tercih basit üzerinde zeki .
• Gelecekteki sürdürülebilirliğin performans gibi unsurların pahasına gelebileceğini kabul edin. Örneğin, saklı yordamları kullanmaya istekli olabilirsiniz, ancak bunlar sistemi birisinin daha basit bir depolama çözümüne geçirmesini engellediklerinde gelecekteki bakımı sınırlayabilir.

Buna sahip olduktan sonra, uygulamanın kendisini provaya dönüştürmek daha kolaydır, çünkü veri modeli etrafındaki bir sarmalayıcıdır ve örneğin 10 yıl içinde artık hiç kimse Javascript kullanmıyorsa ve uygulamayı bu uygulamaya geçirmeniz gerekirse WASM ya da bir şey. Modüler, daha az birbirine bağımlı olarak tutmak, gelecekteki bakımı kolaylaştırır.

^[1] Bu cevaba yapılan yorumların çoğu, bir DB için Oracle kullanmaya karşı güçlü bir duruş sergilemekte, Oracle'ın çalışmak için acı vermesinin neden çok meşru bir nedeni olduğunu, ek bir öğrenme eğrisi ve montaj yükü olduğunu vurgulamaktadır. Bunlar DB'yi Oracle olarak seçerken tamamen geçerli kaygılardır, ancak bizim durumumuzda, genel amaçlı bir DB aramıyoruz, ancak birincil kaygının sürdürülebilir olduğu yerlerden biriyiz . Oracle, 70'li yılların sonlarından bu yana etrafında olmuştur ve uzun yıllar boyunca desteklenmesi muhtemeldir ve çalışmaya devam etmenize yardımcı olacak devasa bir danışman ekosistemi ve destek seçenekleri vardır. Bu, birçok şirket için overpriced bir karmaşa mı? Elbette. Fakat veri tabanınızın 20 yıl boyunca çalışmasını sağlayacak mı? Büyük olasılıkla.

Amon tarafından verilen önceki cevap harika, ancak belirtilmeyen iki ek nokta daha var:

• Bu sadece tarayıcılarla ilgili değil; cihazlar da önemli.

  Amon, “15 yıl önce tarayıcılarda çalışan bir web sitesinin aynı şekilde çalışacağını” belirtiyor , bu doğru. Bununla birlikte, onbeş değil, on yıl önce oluşturulan web sitelerine bakın; Bugün, kullanıcıların büyük bir kısmı, tarayıcılar değiştiği için değil, cihazlar kullandığı için bu web sitelerini hiç kullanamayacak. Bu web siteleri mobil cihazların küçük ekranlarında berbat görünecek ve geliştiriciler clicko tapetkinliğin de önemli olduğunu bilmeden JavaScript etkinliğine güvenmeye karar verdiğinde sonuçta hiç işe yaramayacaktı .

• Yanlış bir konuya odaklanıyorsun.

  Teknoloji değişiklikleri bir şeydir, ama daha önemli olan gereksinimlerin değişimleridir . Ürünün ölçeklendirilmesi gerekebilir veya ek özelliklere sahip olması gerekebilir veya mevcut özelliklerinin değiştirilmesi gerekebilir.

  Tarayıcılara, cihazlara veya W3C'ye veya ne olursa olsun ne olacağı önemli değil.

  Eğer varsa o refactored edilebilir bir şekilde kod yazmak , ürün teknolojisi ile gelişecektir.

  Kodunuzu hiç kimsenin anlayamayacağı ve koruyamayacağı bir şekilde yazarsanız, teknolojinin önemi yoktur: herhangi bir çevresel değişiklik, uygulamanızı farklı bir işletim sistemine geçiş gibi, hatta doğal veri büyümesi gibi basit bir şey gibi aşağı indirecektir. .

  Örnek olarak, on yıl boyunca yazılım geliştirme alanında çalışıyorum. Düzinelerce ve düzinelerce proje arasında, teknoloji nedeniyle değiştirmeye karar verdiğim sadece iki tane vardı , daha doğrusu PHP son on yılda çok gelişti. Müşterinin kararı bile değildi: site PHP'nin ad alanlarını veya kapaklarını kullanırsa daha az umrunda olmazdı. Ancak, yeni gereksinimler ve ölçeklenebilirlik ile ilgili değişiklikler var, bolca vardı!

20 yıl sürmeyi planlamıyorsun. Sade ve basit. Bunun yerine hedeflerinizi bölümlendirmeye kaydırıyorsunuz.

Uygulama veritabanınız agnostik mi? Şu anda veri tabanlarını değiştirmek zorunda olsaydın, yapabilir miydin? Mantık diliniz agnostik mi. Uygulamayı şimdi tamamen yeni bir dilde yeniden yazmak zorunda kalsaydınız, olur mu? SRP ve DRY gibi iyi tasarım kurallarına uyuyor musunuz?

Projelerim 20 yıldan daha uzun bir süredir yaşıyor ve size işlerin değiştiğini söyleyebilirim. Pop-up'lar gibi. 20 yıl önce bir pop-up'a güvenebilirdiniz, bugün yapamazsınız. XSS 20 yıl önce bir şey değildi, şimdi CORS’u açıklamalısınız.

Yani yaptığınız şey, mantığınızın hoş bir şekilde ayrıldığından ve sizi belirli bir satıcıya kilitleyen HERHANGİ bir teknolojiyi kullanmaktan kaçındığınızdan emin olmaktır.

Bu bazen çok zor olabilir. Örneğin, .NET, diğer bağdaştırıcılarda eşdeğerleri olmayan MSSQL veritabanı bağdaştırıcısının mantığını ve yöntemini göstermekte harikadır. MSSQL bugün iyi bir plan gibi görünebilir, ancak 20 yıl boyunca devam edecek mi? Kim bilir. Uygulamanın diğer bölümlerinden tamamen ayrı bir veri katmanına sahip olmak için bunun nasıl çözüleceğine bir örnek. O zaman, en kötü durumda, tüm veri katmanını sadece yeniden yazmak zorundasınız, uygulamanızın geri kalan kısmı etkilenmeden kalıyor.

Başka bir deyişle, bir araba gibi düşünün. Arabanız 20 yıl sürmeyecek. Ancak, yeni lastikler, yeni motor, yeni şanzıman, yeni pencereler, yeni elektronik, vb. Aynı araba çok uzun bir süre boyunca yolda olabilir.

@ Amon ve diğerlerinin cevapları harika, ama buna başka bir açıdan bakmanı önermek istedim.

20 yılı aşkın bir süredir kullanılmış olan programlara veya kod tabanlarına dayanan Büyük Üreticiler ve Devlet Daireleri ile çalıştım ve hepsinin ortak bir özelliği vardı - şirket donanımı kontrol etti. 20 + yıl boyunca çalışan ve genişletilebilir bir şeyin olması, üzerinde çalıştığını kontrol ettiğinizde zor değildir. Bu gruplardaki çalışanlar, dağıtım makinelerinden yüzlerce kez daha hızlı olan modern makineler üzerinde kod geliştirdiler ... ancak dağıtım makineleri zaman içinde dondu.

Durumunuz karmaşık, çünkü bir web sitesi iki ortam için plan yapmanız gerektiği anlamına geliyor - sunucu ve tarayıcı.

Sunucuya gelince, iki genel seçeneğiniz var:

• Çok daha hızlı olabilen çeşitli destek fonksiyonları için işletim sistemine güvenin, ancak işletim sisteminin "zaman içinde donması" gerekebileceği anlamına gelir. Bu durumda, sunucu için işletim sistemi kurulumunun bazı yedeklerini hazırlamak isteyeceksiniz. 10 yıl içinde bir şey bozulursa, birinin işletim sistemini yeniden yüklemeye çalışırken çıldırmasını sağlamak veya farklı bir ortamda çalışmak için kodu yeniden yazmak istemezsiniz.

• Belirli bir dilde / çerçevede, daha yavaş, ancak sanal bir ortamda paketlenebilen ve muhtemelen farklı işletim sistemleri veya mimarilerde çalıştırılan sürümlü kitaplıkları kullanın.

Tarayıcıya gelince, sunucudaki her şeyi barındırmanız gerekir (yani dosyaları barındırmak için global bir CDN kullanamazsınız). Gelecekteki tarayıcıların HTML ve Javascript'i (en azından uyumluluk için) çalıştırmaya devam edeceğini varsayıyoruz, ancak bu gerçekten bir tahmin / varsayımdır ve kontrol edemezsiniz.

Çoğu uygulamanın özü veridir. Veri sonsuza kadar. Kod daha harcanabilir , değişken, dövülebilir. Yine de veriler korunmalıdır. Bu yüzden gerçekten sağlam bir veri modeli oluşturmaya odaklanın. Şema ve verileri temiz tutun. Aynı veritabanının üzerine yeni bir uygulama yapılabileceğini tahmin edin.

Bütünlük kısıtlamaları uygulayabilen bir veritabanı seçin. Güçsüz kısıtlamalar zaman geçtikçe ihlal edilme eğilimindedir. Kimse farketmez. Yabancı anahtarlar, benzersiz kısıtlamalar, kısıtlamaları kontrol edin ve muhtemelen doğrulama için tetikleyiciler gibi olanaklardan en iyi şekilde yararlanın. Tablolar arası benzersiz kısıtlamaları uygulamak için dizine alınmış görünümleri kötüye kullanmanın bazı püf noktaları vardır.

Bu nedenle, başvurunun bir süre sonra yeniden yazılacağını kabul etmeniz gerekebilir. Veritabanı temizse, az miktarda göç çalışması olacaktır. Göçler işgücü ve sebep olduğu kusurlar açısından oldukça pahalıdır.

Teknoloji açısından bakıldığında, uygulamanın çoğunu sunucuya koymak iyi bir fikir olabilir, istemcideki JavaScript biçiminde değil. Sanallaştırma sayesinde muhtemelen aynı uygulamayı aynı işletim sistemi örneğinde çok uzun süre çalıştırabilirsiniz . Bu gerçekten hoş değil ama uygulamanın pahalı bakım ve donanım masrafları olmadan bundan 20 yıl sonra çalışacağının garantisi. Bunu yaparak, en azından eski, çalışma kodunu çalıştırmaya devam etmenin güvenli ve ucuz bir geri dönüşüne sahip olursunuz.

Ayrıca, bazı teknoloji yığınlarının diğerlerinden daha istikrarlı olduğunu buldum . .NET'in şu anda mümkün olan en iyi geriye dönük uyumluluk hikayesine sahip olduğunu söyleyebilirim. Microsoft bu konuda ciddi. Java ve C / C ++ da gerçekten kararlıdır. Python, Python 3 kırılma değişiklikleriyle çok dengesiz olduğunu kanıtladı. JavaScript aslında benim için oldukça kararlı görünüyor çünkü web'i kırmak herhangi bir tarayıcı satıcısı için bir seçenek değildir. Muhtemelen, deneysel veya korkak bir şeye güvenmemelisin. ("Funky", "gördüğümde biliyorum" olarak tanımlanıyor).

Diğer cevaplar anlamlıdır. Bununla birlikte, müşteri teknolojisindeki yorumların işleri karmaşık hale getirdiğini düşünüyorum. Son 16 yıldır geliştirici olarak çalışıyorum. Tecrübelerime göre, müşteri kodunuzu sezgisel tuttuğunuz sürece, iyi olmalısınız. Öyleyse, çerçeveler / iframe'lerle "kesmek" yok. Tarayıcılarda yalnızca iyi tanımlanmış işlevleri kullanın.

Uyumluluk modlarını, tarayıcıların çalışmalarını sürdürmek için her zaman kullanabilirsiniz.

Amacımı kanıtlamak için, sadece birkaç ay önce, web uygulamasını 17 yıldır işleten bir müşterinin javascript kodunda bin yıl süren bir hatayı düzelttim. Halen yeni makineler, son veritabanı, son işletim sistemi üzerinde çalışmaktadır.

Sonuç: basit ve temiz tutun ve iyi olmanız gerekir.

Birkaç aksiyom:

• Gerçek hayatta kalır. Bu bağlamda, algoritmalar ve veri modelleri olacaktır - ki bu problem alanınızın "neyi" ve "nasıl" nı gerçekten temsil eder. Bununla birlikte, her zaman iyileştirme ve iyileştirme potansiyeli veya sorunun kendisinde bir evrim vardır.
• Diller gelişiyor. Bu, bilgisayar dilleri için olduğu gibi doğal diller için de geçerlidir.
• Tüm teknoloji eskimeye karşı hassastır. Bazı teknolojiler için diğerlerinden daha uzun sürebilir

En istikrarlı teknolojiler ve standartlar (eskimeye en az hassas olanlar) tescilli olmayan ve en yaygın şekilde kabul edilenler olma eğilimindedir. Evlat edinme ne kadar genişse, hemen hemen her türlü değişime karşı atalet o kadar büyük olur. Özel "standartlar" her zaman sahiplerinin ve rekabet güçlerinin servet ve kaprislerine karşı savunmasızdır.

Yirmi yıl bilgisayar endüstrisinde çok uzun bir zamandır. Beş yıl daha gerçekçi bir hedef. Beş yıl içinde, başvurunuzun çözmesi gereken bütün sorun tamamen yeniden tanımlanabilir.

Göstermek için birkaç örnek:

C ve C ++ uzun süredir var. Hemen hemen her platformda uygulamaları var. C ++ gelişmeye devam ediyor, ancak "evrensel" özelliklerin (tüm platformlarda bulunanların) hiçbir zaman kullanımdan kaldırılmayacağı garanti ediliyor.

Flash neredeyse evrensel bir standart oldu, ancak tescilli. Popüler mobil platformlarda desteklememeye yönelik kurumsal kararlar temelde her yere mahkum etti - web için yazıyorsanız, içeriğinizin tüm platformlarda kullanılabilir olmasını istersiniz; Mobil pazarın haline geldiği büyük pazarları kaçırmak istemezsiniz.

WinTel (Windows / x86) Microsoft'a ve Intel'e tescilli olmasına rağmen, optimal olmayan bir platformda (16 bit dahili / 8 bit harici 8088 vs çağdaş Apple Macintosh 32 bit dahili / 16 bit harici 68000) ve erozyona başladı Tüketici pazarında Apple'a iş platformları için fiili bir seçenek olmaya devam etmektedir. Tüm bu süre zarfında (25 yıl) geriye dönük uyumluluğa olan bağlılık, gelecekteki gelişimin artmasına neden oldu ve eski kutuda çalışılanın hala yenisi üzerinde çalışacağına dair büyük bir güven verdi.

Son düşünceler

İş mantığını uygulamak için JavaScript en iyi seçenek olmayabilir. Veri bütünlüğü ve güvenliği nedeniyle, sunucuda iş mantığı uygulanmalı, böylece istemci tarafı JavaScript kullanıcı arayüzü davranışıyla sınırlandırılmalıdır. Sunucuda bile, JavaScript en iyi seçenek olmayabilir. Küçük projeler için diğer yığınlardan (Java veya C #) çalışmak daha kolay olsa da, işler daha karmaşık hale geldiğinde daha iyi, daha organize çözümler yazmanıza yardımcı olabilecek bir formaliteden yoksundur.