Mengembangkan aplikasi web untuk umur panjang (20+ tahun)

160

Saat ini saya sedang mengembangkan aplikasi web untuk perencanaan pertanahan pemerintah. Aplikasi sebagian besar berjalan di browser, menggunakan ajax untuk memuat dan menyimpan data.

Saya akan melakukan pengembangan awal, dan kemudian lulus (ini adalah pekerjaan siswa). Setelah ini, anggota tim lainnya akan menambahkan fitur sesekali sesuai kebutuhan. Mereka tahu cara membuat kode, tetapi mereka kebanyakan ahli perencanaan lahan.

Mempertimbangkan kecepatan perubahan teknologi Javascript, bagaimana saya bisa menulis kode yang masih berfungsi 20 tahun dari sekarang? Secara khusus, perpustakaan, teknologi, dan ide-ide desain mana yang harus saya gunakan (atau hindari) untuk membuktikan kode saya di masa mendatang?

javascript web-development future-proof Dan
sumber
94
Saya mulai pemrograman di Fortran pada akhir 1966, jadi saya punya banyak waktu untuk memikirkan masalah seperti itu. Jika Anda pernah menemukan jawaban yang tepercaya bahkan 50%, beri tahu saya. Sementara itu, anggap saja keusangan yang hampir tak terelakkan sebagai "keamanan pekerjaan" :)
John Forkosh
11
Tidak ada yang bertahan selamanya di Rekayasa Perangkat Lunak. Hanya HOST di bank dan karena tidak ada yang berani memperbarui sistem kritis tersebut. Ya, saya kira program yang berjalan di Voyager juga diperhitungkan.
Laiv
9
@ Longv Beberapa waktu lalu, saya bekerja pada aplikasi pengiriman uang untuk Bankir Trust menggunakan pesan cepat yang berjalan di Vax / VMS. Beberapa tahun kemudian, Swift eol'ed (end-of-life'ed) semua dukungan VMS. Boy, apakah itu menyebabkan beberapa masalah ... dan memberi saya kontrak lain di BTCo. Seperti yang saya katakan di atas, "keamanan pekerjaan" :). Pokoknya, maksud saya adalah bahwa bahkan aplikasi pasar keuangan yang kritis tidak kebal terhadap usang.
John Forkosh
102
Bagaimana dengan "Tulis kode yang bisa dipahami pengembang selanjutnya"? Jika dan ketika kode menjadi usang sampai-sampai mereka perlu menemukan seorang programmer untuk memperbaruinya, skenario terbaik adalah mereka akan mengerti apa yang dilakukan kode Anda (dan mungkin mengapa keputusan tertentu dibuat).
David Starkey
38
Cukup gunakan HTML lama, tanpa JS, tanpa plugin, tidak ada yang mewah. Jika berfungsi di Lynx, itu bagus untuk selamanya.
Gayus

Jawaban:

132

Merencanakan perangkat lunak untuk masa hidup seperti itu sulit, karena kita tidak tahu apa yang akan terjadi di masa depan. Sedikit konteks: Jawa diterbitkan tahun 1995, 21 tahun yang lalu. XmlHttpRequest pertama kali tersedia sebagai ekstensi berpemilik untuk Internet Explorer 5, diterbitkan 1999, 17 tahun yang lalu. Butuh waktu sekitar 5 tahun hingga tersedia di semua browser utama. 20 tahun yang Anda coba lihat ke depan sudah saatnya aplikasi web kaya telah ada.

Beberapa hal pasti tetap sama sejak itu. Telah ada upaya standardisasi yang kuat, dan sebagian besar browser sesuai dengan berbagai standar yang terlibat. Situs web yang bekerja lintas browser 15 tahun yang lalu masih akan berfungsi sama, asalkan berfungsi karena menargetkan subset umum dari semua browser, bukan karena menggunakan solusi untuk setiap browser.

Hal-hal lain datang dan pergi - yang paling mencolok adalah Flash. Flash memiliki berbagai masalah yang menyebabkan kematiannya. Yang paling penting, itu dikendalikan oleh satu perusahaan. Alih-alih persaingan di dalam platform Flash, ada persaingan antara Flash dan HTML5 - dan HTML5 menang.

Dari sejarah ini, kita dapat mengumpulkan beberapa petunjuk:

  • Tetap sederhana: Lakukan apa yang berfungsi sekarang, tanpa harus menggunakan solusi apa pun. Perilaku ini kemungkinan akan tetap tersedia lama di masa depan karena alasan kompatibilitas ke belakang.

  • Hindari mengandalkan teknologi eksklusif, dan lebih suka standar terbuka.

Dunia JavaScript saat ini relatif tidak stabil dengan fluktuasi perpustakaan dan kerangka kerja yang tinggi. Namun, hampir tidak satu pun dari mereka akan berarti dalam 20 tahun - satu-satunya "kerangka kerja" saya yakin yang masih akan digunakan saat itu adalah Vanilla JS .

Jika Anda ingin menggunakan perpustakaan atau alat karena itu benar-benar membuat pengembangan jauh lebih mudah, pertama pastikan bahwa itu dibangun di atas standar yang didukung dengan baik saat ini. Anda kemudian harus mengunduh perpustakaan atau alat dan memasukkannya dengan kode sumber Anda. Repositori kode Anda harus menyertakan semua yang diperlukan untuk menjalankan sistem. Apa pun eksternal adalah ketergantungan yang bisa pecah di masa depan. Cara yang menarik untuk menguji ini adalah menyalin kode Anda ke thumb drive, pergi ke komputer baru dengan sistem operasi yang berbeda, lepaskan dari internet, dan lihat apakah Anda dapat membuat frontend Anda berfungsi. Selama proyek Anda terdiri dari HTML + CSS + JavaScript polos plus mungkin beberapa perpustakaan, Anda mungkin akan lulus.

amon
sumber
4
Aplikasi skala besar tidak terpelihara dalam vanilla js, seperti yang sekarang. ES6 sudah entah bagaimana memperbaiki masalah ini, tetapi ada alasan mengapa flow atau TypeScript mendapatkan popularitas.
Andy
34
@ Davidvider Benar-benar, TypeScript dll. Hebat dan membuat pengembangan lebih mudah. Tetapi begitu saya memperkenalkan proses pembuatan, semua alat yang diperlukan untuk proses pembuatan menjadi dependensi: NodeJS, Gulp, NPM - siapa bilang NPM masih akan online dalam 20 tahun? Saya harus menjalankan registry sendiri untuk memastikan. Ini bukan tidak mungkin. Tetapi beberapa hal, lebih baik melepaskan hal-hal yang membuat pengembangan lebih mudah hanya dengan segera, tetapi tidak dalam jangka panjang.
amon
30
@ Davidvider Ada banyak bahasa dinamis, dan yang mengejutkan, banyak sistem yang berhasil telah dibangun dengan Smalltalk, Ruby, Perl, Python, bahkan dengan PHP dan JS. Sementara bahasa yang diketik secara statis cenderung lebih mudah dikelola sedangkan bahasa yang dinamis cenderung lebih baik untuk pembuatan prototipe cepat, bukan tidak mungkin untuk menulis JS yang bisa dikelola. Dengan tidak adanya kompiler, keterampilan median yang tinggi dalam tim, pengerjaan, dan penekanan ekstra pada organisasi kode yang jelas menjadi lebih penting. Saya pribadi berpikir tipe membuat segalanya lebih mudah, tetapi mereka bukan peluru perak.
amon
4
Apakah saya baru saja membaca "ambil usb dan uji pada mesin yang berbeda"? Mengapa tidak hanya memutar virtualbox atau hanya menggunakan mode penyamaran (dengan ethX dinonaktifkan).
Kyslik
5
Saya tidak yakin vanilla JS akan menjadi hal yang pasti 20 tahun dari sekarang. Sejarahnya berbatu-batu dan eksperimental, dan mengambil cukup banyak cruft di sepanjang jalan, bahkan ketika itu telah muncul sebagai bahasa yang menyenangkan dan efektif (saya pribadi lebih suka JavaScript atau TypeScript sendiri). Tidak sulit untuk membayangkan bahwa vendor mungkin ingin membuang sebagian atau semua cacat itu, apakah itu berarti mulai menawarkan bahasa alternatif baru — seperti yang tampaknya diusulkan Google dengan Dart, betapapun banyak hal yang tampaknya tidak terjadi di mana pun. —Atau dengan mencela dan kemudian menghilangkan bagian-bagian JS.
KRyan
178

Apa yang lebih penting daripada kode Anda bertahan selama 20 tahun adalah bahwa data Anda bertahan selama 20 tahun. Kemungkinannya, itulah hal yang patut dipertahankan. Jika data Anda mudah dikerjakan, membangun sistem alternatif di atasnya dengan teknologi yang lebih baru akan mudah.

  • Jadi mulailah dengan model data yang jelas dan terdokumentasi dengan baik.
  • Gunakan sistem database yang mapan dan didukung dengan baik, seperti Oracle [1] atau SQL Server.
  • Gunakan fitur dasar, jangan coba-coba memeras fitur baru yang mencolok.
  • Lebih suka sederhana daripada pintar .
  • Terimalah bahwa pemeliharaan di masa depan dapat mengorbankan aspek-aspek seperti kinerja. Misalnya, Anda mungkin tergoda untuk menggunakan prosedur yang tersimpan, tetapi ini mungkin membatasi pemeliharaan di masa depan jika mereka mencegah seseorang dari migrasi sistem ke solusi penyimpanan yang lebih sederhana.

Setelah Anda memilikinya, pemeriksaan di masa depan aplikasi itu sendiri lebih sederhana, karena itu adalah pembungkus model data, dan dapat diganti jika, dalam 10 tahun, tidak ada yang menggunakan Javascript lagi, misalnya, dan Anda perlu melakukan migrasi aplikasi ke WASM atau apalah. Menjaga hal-hal menjadi modular, tidak saling tergantung, memungkinkan pemeliharaan yang lebih mudah di masa depan.

[1] Sebagian besar komentar untuk jawaban ini sangat menentang penggunaan Oracle untuk DB, dengan mengutip banyak alasan sah mengapa Oracle sulit digunakan, memiliki kurva pembelajaran yang curam dan overhead pemasangan. Ini adalah kekhawatiran yang sepenuhnya sahih ketika memilih Oracle sebagai DB, tetapi dalam kasus kami, kami tidak mencari DB untuk tujuan umum, tetapi yang menjadi perhatian utama adalah pemeliharaan . Oracle telah ada sejak akhir 70-an dan kemungkinan akan didukung selama bertahun-tahun yang akan datang, dan ada ekosistem besar konsultan dan opsi dukungan yang dapat membantu Anda tetap berjalan. Apakah ini kekacauan yang terlalu mahal bagi banyak perusahaan? Tentu. Tapi apakah itu akan membuat database Anda berjalan selama 20 tahun ? Sepertinya.

Avner Shahar-Kashtan
sumber
141
Maaf, tapi saya harus mengatakan ini. Jika Anda menggunakan Oracle, Anda menembak semua orang dengan mudah untuk "bekerja dengan mudah." Oracle tidak mudah diajak bekerja sama sekali. Banyak fungsi yang SQL Server, PostgreSQL, dan mungkin bahkan MySQL membuat sederhana, Oracle baik tidak punya atau membuat terlalu sulit. Saya tidak pernah memiliki banyak masalah bodoh dengan DB lain seperti yang saya miliki dengan Oracle; bahkan hanya menyiapkan klien adalah rasa sakit yang hebat di pantat. Bahkan hal-hal yang sulit di Google. Jika Anda ingin "mudah dikerjakan," menjauhlah dari Oracle.
jpmc26
4
+1 untuk menjaga data sesederhana mungkin. Gunakan SQL standar untuk ini, mis. Gunakan OUTER JOIN dan bukannya operator + oracle tertentu . Gunakan tata letak tabel sederhana. Jangan menormalkan tabel Anda ke tingkat maksimum absolut. Putuskan apakah beberapa tabel dapat memiliki data yang berlebihan atau jika Anda benar-benar harus membuat tabel baru sehingga setiap nilai hanya ada satu kali. Apakah prosedur tersimpan vendor khusus ? Jika ya maka jangan menggunakannya. Jangan gunakan fitur terhebat dari bahasa pilihan Anda saat ini: Saya telah melihat lebih banyak program COBOL tanpa OOP-Features kemudian bersama mereka. Dan itu sangat baik.
some_coder
3
@ jpmc26 Saya setuju dengan sentimen Anda tentang Oracle, tetapi seperti yang saya katakan, "mudah digunakan" tidak selalu merupakan persyaratan utama di sini. Saya lebih suka platform yang didukung kuat di sini, bahkan jika itu sulit untuk diajak bekerja sama. Karena ketika diamortisasi selama 20 tahun, itu tidak terlalu buruk.
Avner Shahar-Kashtan
8
Memang menghindari Oracle. Satu-satunya DB yang ada saat ini yang sepertinya tidak terlihat sebagai pilihan yang buruk dalam 20 tahun adalah Postgresql.
Joshua
3
Saya ingin menambahkan bahwa DBMS open source yang hebat lebih disukai karena ada kemungkinan mereka tidak akan mati. Jika Oracle berhenti menghasilkan uang dalam 10 tahun, maka dalam 11 akan hilang. PostreSQL sepertinya kuda terbaik untuk bertaruh.
Shautieh
36

Jawaban sebelumnya oleh Amon bagus, tetapi ada dua poin tambahan yang tidak disebutkan:

  • Ini bukan hanya tentang browser; perangkat juga penting.

    amon menyebutkan fakta bahwa "situs web yang bekerja di browser 15 tahun yang lalu masih akan berfungsi sama" , yang benar. Namun, lihat situs web yang dibuat bukan lima belas, tetapi sepuluh tahun lalu, yang, ketika dibuat, berfungsi di sebagian besar browser untuk sebagian besar pengguna. Saat ini, sebagian besar pengguna tidak akan dapat menggunakan situs web itu sama sekali, bukan karena browser berubah, tetapi karena perangkat melakukannya. Situs web itu akan terlihat mengerikan di layar kecil perangkat seluler , dan akhirnya tidak berfungsi sama sekali jika pengembang memutuskan untuk mengandalkan clickacara JavaScript , tanpa mengetahui bahwa tapacara itu juga penting.

  • Anda fokus pada subjek yang salah.

    Perubahan teknologi adalah satu hal, tetapi yang lebih penting adalah perubahan persyaratan . Produk mungkin perlu diskalakan, atau mungkin perlu memiliki fitur tambahan, atau mungkin perlu fitur saat ini diubah.

    Tidak masalah apa yang akan terjadi pada browser, atau perangkat, atau W3C, atau ... apa pun.

    Jika Anda menulis kode Anda sedemikian rupa sehingga dapat di refactored , produk akan berkembang dengan teknologi.

    Jika Anda menulis kode dengan cara yang tidak dapat dipahami dan dipelihara oleh siapa pun, teknologi tidak masalah: perubahan lingkungan apa pun akan menurunkan aplikasi Anda, seperti migrasi ke sistem operasi yang berbeda, atau bahkan hal sederhana seperti pertumbuhan data alami .

    Sebagai contoh, saya bekerja dalam pengembangan perangkat lunak selama sepuluh tahun. Di antara lusinan proyek, hanya ada dua yang saya putuskan untuk berubah karena teknologi , lebih tepatnya karena PHP banyak berkembang selama sepuluh tahun terakhir. Itu bahkan bukan keputusan pelanggan: dia tidak akan peduli jika situs menggunakan ruang nama PHP atau penutupan. Namun, perubahan terkait dengan persyaratan dan skalabilitas baru, ada banyak!

Arseni Mourzenko
sumber
4
Adopsi untuk berbagai ukuran layar adalah masalah umum. Seluler adalah hal yang paling populer saat ini, tetapi jika Anda melihat situs web ini dalam jendela browser layar penuh pada layar dengan resolusi yang cukup, ada banyak ruang kosong (terbuang). Mengubah tata letak dan bagaimana informasi disajikan untuk penggunaan terbaik piksel yang tersedia tidak pernah benar-benar terjadi dengan cara yang cerdas. Ponsel membuat ini jelas. Tetapi berpikir ke arah lain mungkin lebih penting untuk pertanyaan yang ada.
null
9
@null: sementara saya setuju dengan komentar Anda, situs web StackExchange mungkin bukan ilustrasi terbaik dari poin Anda. Mengingat data yang akan ditampilkan, saya percaya desainer / pengembang StackExchange melakukan pekerjaan yang baik untuk menampilkannya karena perlu ditampilkan, termasuk pada monitor besar. Anda tidak dapat membuat kolom utama lebih luas, karena teks akan menjadi lebih sulit untuk dibaca, dan Anda tidak dapat menggunakan banyak kolom karena itu tidak akan terlihat bagus untuk pertanyaan dan jawaban singkat.
Arseni Mourzenko
Contoh bagus lainnya adalah acara 'hover' yang sering digunakan dalam sistem menu. Banyak dari menu itu gagal total dengan perangkat sentuh.
Justas
Anda 110% (atau lebih) benar tentang perangkat, dan saya dapat memberi Anda contoh yang lebih tua. Kembali pada akhir 1980-an saya bekerja pada aplikasi CICS yang berjalan pada mainframe IBM dan terminal 3270 yang sinkron. Wilayah CICS adalah jenis analog dengan aplikasi sisi server, mengirimkan layar penuh data sekaligus ke terminal sinkron, yang dengan demikian analog dengan browser perangkat khusus. Dan pemrograman CICS mungkin 80% Cobol, 20% PL / 1. Kedua bahasa tersebut sebagian besar sudah ketinggalan zaman saat ini, dan penampilan workstation Unix (Sun dan Apollo) pada awal 1990-an cukup banyak membunuh CICS sepenuhnya
John Forkosh
31

Anda tidak berencana untuk bertahan 20 tahun. Polos dan sederhana. Alih-alih, Anda menggeser sasaran ke kompartementalisasi.

Apakah basis data aplikasi Anda agnostik? Jika Anda harus beralih basis data sekarang, bisakah Anda. Apakah bahasa logika Anda agnostik. Jika Anda harus menulis ulang aplikasi dalam bahasa yang sama sekali baru sekarang, bisakah Anda? Apakah Anda mengikuti pedoman desain yang baik seperti SRP dan KERING?

Saya telah memiliki proyek yang hidup lebih dari 20 tahun, dan saya dapat memberitahu Anda bahwa semuanya berubah. Seperti pop-up. 20 Tahun yang lalu Anda bisa mengandalkan pop-up, hari ini Anda tidak bisa. XSS bukan hal 20 tahun yang lalu, sekarang Anda harus memperhitungkan CORS.

Jadi yang Anda lakukan adalah memastikan logika Anda terpisah dengan baik, dan Anda menghindari penggunaan teknologi APA SAJA yang mengunci Anda ke vendor tertentu.

Ini terkadang sangat sulit. .NET misalnya sangat bagus dalam mengungkap logika dan metode untuk adaptor basis data MSSQL yang tidak memiliki padanan dalam adaptor lain. MSSQL mungkin tampak seperti rencana yang bagus hari ini tetapi apakah akan tetap demikian selama 20 tahun? Siapa tahu. Contoh cara menyiasatinya agar memiliki lapisan data yang benar-benar terpisah dari bagian lain aplikasi. Kemudian, kasus terburuk, Anda hanya perlu menulis ulang seluruh lapisan data, sisa aplikasi Anda tetap tidak terpengaruh.

Dengan kata lain pikirkan itu seperti mobil. Mobil Anda tidak akan membuatnya 20 tahun. Tapi, dengan ban baru, mesin baru, transmisi baru, jendela baru, elektronik baru, dll. Mobil yang sama itu bisa berada di jalan untuk waktu yang sangat lama.

kapas
sumber
2
"Jika Anda harus beralih basis data sekarang, bisakah Anda" Ini hampir mustahil untuk dicapai jika Anda melakukan sesuatu yang lebih dari CRUD pada satu baris sekaligus.
jpmc26
1
Banyak ORM adalah agnostik basis data. Saya dapat memberikan salah satu proyek yang sedang saya kerjakan pada gaurentee yang dapat saya ubah dari SQLLite, ke MySql dan Postgre tanpa usaha.
coteyr
5
Dan ORM berhenti menjadi alat yang sangat baik untuk pekerjaan ketika Anda melakukan lebih dari CRUD sederhana pada satu catatan pada satu waktu. Itu sebabnya saya memenuhi syarat itu. Saya sudah mencoba. Seiring meningkatnya kompleksitas kueri, bahkan ORM terbaik pun menjadi lebih banyak masalah daripada sekadar menulis kueri, dan bahkan jika Anda memaksakan kueri Anda, Anda cukup cepat menemukan diri Anda menggunakan fitur atau optimisasi khusus basis data.
jpmc26
1
Tentukan "kompleks". Apakah ini operasi massal? Apakah itu termasuk permintaan jendela? Subquery? CTE? Serikat pekerja? Kondisi pengelompokan yang rumit? Matematika kompleks pada setiap baris dan agregat? Berapa banyak yang bergabung dalam satu permintaan? Gabungan macam apa? Berapa banyak baris yang diproses sekaligus? Diakui, mengatakan sesuatu melalui CRUD baris tunggal (Ingat, ini berarti satu baris per permintaan, bukan per permintaan web atau apa pun.) Adalah sedikit hiperbola, tetapi jalan menuju ketika ORM menjadi lebih banyak masalah daripada nilainya jauh lebih pendek daripada menurutmu. Dan langkah-langkah untuk membuat kueri berkinerja baik sangat sering spesifik database.
jpmc26
4
"Apakah database aplikasi Anda agnostik? Jika Anda harus beralih basis data sekarang, bukan? Apakah bahasa logika Anda agnostik. Jika Anda harus menulis ulang aplikasi dalam bahasa yang sama sekali baru sekarang, bukan?" - Ini benar-benar saran yang MENGERIKAN! Jangan membatasi diri Anda secara artifisial terhadap apa pun yang menurut Anda penyebut umum terbesar dari bahasa atau database pemrograman - ini akan memaksa Anda untuk menemukan kembali roda secara konstan. Sebagai gantinya, cobalah untuk menemukan cara ALAMI untuk mengekspresikan perilaku yang diinginkan dalam bahasa pemrograman dan basis data pilihan Anda.
fgp
12

Jawaban oleh @amon dan beberapa yang lain bagus, tapi saya ingin menyarankan Anda melihat ini dari sudut pandang lain.

Saya telah bekerja dengan Produsen Besar dan Instansi Pemerintah yang mengandalkan program atau basis kode yang telah digunakan selama lebih dari 20 tahun, dan mereka semua memiliki satu kesamaan - perusahaan mengendalikan perangkat keras. Memiliki sesuatu yang berjalan dan dapat diperpanjang selama 20+ tahun tidak sulit ketika Anda mengontrol apa yang berjalan. Karyawan di kelompok-kelompok ini mengembangkan kode pada mesin modern yang ratusan kali lebih cepat daripada mesin penempatan ... tetapi mesin penempatan dibekukan dalam waktu.

Situasi Anda rumit, karena situs web berarti Anda perlu merencanakan dua lingkungan - server dan browser.

Ketika datang ke server, Anda memiliki dua pilihan umum:

  • Mengandalkan sistem operasi untuk berbagai fungsi pendukung yang mungkin jauh lebih cepat, tetapi berarti OS mungkin perlu "dibekukan dalam waktu". Jika demikian, Anda harus menyiapkan beberapa cadangan instalasi OS untuk server. Jika terjadi crash dalam 10 tahun, Anda tidak ingin membuat orang menjadi gila mencoba menginstal ulang OS atau menulis ulang kode untuk bekerja di lingkungan yang berbeda.

  • Gunakan pustaka berversi dalam bahasa / kerangka kerja tertentu, yang lebih lambat, tetapi dapat dikemas dalam lingkungan virtual dan kemungkinan dijalankan pada sistem operasi atau arsitektur yang berbeda.

Ketika datang ke browser, Anda harus meng-host semua yang ada di server (mis. Anda tidak dapat menggunakan CDN global untuk meng-host file). Kami dapat berasumsi bahwa browser masa depan masih akan menjalankan HTML dan Javascript (setidaknya untuk kompatibilitas), tetapi itu benar-benar dugaan / asumsi dan Anda tidak dapat mengendalikannya.

Jonathan Vanasco
sumber
11
Anda harus mempertimbangkan keamanan juga. OS 20 tahun yang tidak didukung mungkin akan penuh dengan lubang keamanan. Saya bekerja untuk sebuah perusahaan dan mewarisi masalah ini. Instansi pemerintah, OS kuno (semuanya telah tervirtualisasi, untungnya), tetapi ini adalah masalah besar, dan peningkatannya hampir tidak mungkin karena harus sepenuhnya menulis ulang perangkat lunak (ratusan skrip PHP kode spaghetti individu, yang masing-masing memiliki panggilan basis data hardcoded, menggunakan fungsi-fungsi yang sudah usang yang tidak didukung oleh driver baru / bergidik).
Jika Anda memilih rute OS, paling baik Anda bisa berharap bahwa patch keamanan diterapkan, dan bahwa pengelola masa depan akan dapat melindungi hal-hal di lapisan jaringan. Untuk merencanakan hal-hal yang berfungsi seperti ini dalam jangka panjang (khususnya jika tidak ada anggaran yang besar, karena OP adalah pelajar), Anda pada dasarnya harus menerima bahwa aplikasi dan server Anda pada akhirnya akan menjadi tidak aman. Misalnya, dalam 20 tahun pada akhirnya akan ada eksploitasi yang diketahui untuk versi SSL di server ... tetapi OS itu mungkin tidak kompatibel dengan versi openssl dalam 10 tahun. Ini semua tentang meminimalkan pengorbanan.
Jonathan Vanasco
@FighterJet, Anda selalu dapat menjalankan firewall pada OS yang didukung, maka Anda memiliki beberapa risiko terpisah dari SQL injects dll yang seharusnya Anda kodekan.
Ian
@Ian: Saya berharap. Ada firewall. Tapi saya tidak menulis kode, saya mewarisinya. Dan ya, ada ribuan kerentanan SQL yang saya harap bisa saya perbaiki, tetapi masalah sebenarnya adalah bahwa kode tersebut bergantung pada versi PHP4 tertentu (yang telah ditinggalkan untuk selamanya dan penuh dengan celah keamanan) dan versi tertentu dari driver basis data (yang tidak berfungsi pada OS yang lebih baru), yang mencegah kami meningkatkan ke versi yang lebih baru dari basis data ... intinya adalah, mengandalkan sesuatu yang tetap sama tidak selalu bekerja. Katakan saja saya senang saya tidak bekerja di sana lagi.
1
@FighterJet Itu sebenarnya contoh yang sangat bagus dari apa yang saya maksud untuk dibicarakan. Anda akhirnya mewarisi kode yang hanya berfungsi pada versi PHP4 tertentu dan driver yang hanya berjalan pada OS tertentu ... sehingga Anda tidak dapat memutakhirkan server. Saya tidak akan menganjurkan orang melakukan itu, tetapi itu terjadi. -- banyak. FWIW, saya setuju dengan Anda, tetapi saya ingin jawaban saya untuk menumbuhkan pemikiran di sekitar jenis skenario itu, bukan membuat rekomendasi.
Jonathan Vanasco
6

Inti dari sebagian besar aplikasi adalah data. Data selamanya. Kode lebih dapat dibuang , diubah, dapat ditempa. Namun, data harus disimpan. Jadi fokuslah untuk membuat model data yang benar-benar solid. Jaga skema dan data tetap bersih. Mengantisipasi, bahwa aplikasi baru dapat dibangun di atas database yang sama.

Pilih database yang mampu menegakkan batasan integritas. Kendala yang tidak dipaksakan cenderung dilanggar seiring berjalannya waktu. Tidak ada yang tahu. Manfaatkan fasilitas secara maksimal seperti kunci asing, kendala unik, periksa kendala, dan mungkin pemicu untuk validasi. Ada beberapa trik untuk menyalahgunakan pandangan yang diindeks untuk menegakkan batasan keunikan lintas-tabel.

Jadi mungkin Anda perlu menerima bahwa aplikasi akan ditulis ulang pada suatu waktu. Jika database bersih, akan ada sedikit pekerjaan migrasi. Migrasi sangat mahal dalam hal tenaga kerja dan cacat yang disebabkan.

Dari perspektif teknologi mungkin ide yang baik untuk menempatkan sebagian besar aplikasi di server dan bukan dalam bentuk JavaScript pada klien. Anda mungkin dapat menjalankan aplikasi yang sama dalam instance OS yang sama untuk waktu yang sangat lama berkat virtualisasi . Itu tidak terlalu bagus tapi itu jaminan aplikasi akan bekerja 20 tahun dari sekarang tanpa biaya pemeliharaan dan perangkat keras yang mahal. Dengan melakukan ini, Anda setidaknya memiliki fallback aman dan murah untuk terus menjalankan kode lama yang berfungsi.

Juga, saya menemukan bahwa beberapa tumpukan teknologi lebih stabil daripada yang lain . Saya akan mengatakan bahwa .NET memiliki kisah kompatibilitas mundur terbaik saat ini. Microsoft sangat serius tentang hal itu. Java dan C / C ++ juga sangat stabil. Python telah membuktikan bahwa itu sangat tidak stabil dengan Python 3 melanggar perubahan. Sebenarnya JavaScript tampaknya cukup stabil bagi saya karena memecah web bukanlah opsi untuk vendor browser mana pun. Anda mungkin sebaiknya tidak mengandalkan apa pun yang eksperimental atau funky. ("Funky" didefinisikan sebagai "Saya tahu ketika saya melihatnya").

usr
sumber
tentang .net kompatibilitas mundur cerita - Saya tidak berpikir saya telah melihat aplikasi java yang akan meminta versi java yang lebih lama, sebagai kontras. Itu mungkin berubah dengan Java 9 atau lebih, tetapi belum melihatnya terjadi.
eis
Ini luar biasa kompatibel dalam praktiknya, dan menginstal versi yang lebih lama secara berdampingan bukanlah suatu masalah. Juga perhatikan, bahwa .NET BCL dalam perkiraan saya 10-100x lebih besar dari kelas bawaan Java.
usr
kompatibilitas ke belakang berarti bahwa seharusnya tidak perlu menginstal juga versi yang lebih lama. Tapi kami ngelantur dari pertanyaan awal, ini tidak benar-benar relevan dengan OP.
eis
0

Jawaban lain masuk akal. Namun, saya merasa komentar pada teknologi klien lebih rumit. Saya telah bekerja sebagai pengembang selama 16 tahun terakhir. Dalam pengalaman saya, selama Anda menjaga kode klien Anda intuitif, Anda harus baik-baik saja. Jadi tidak ada "retasan" dengan bingkai / iframe, dll. Hanya gunakan fungsi yang didefinisikan dengan baik di browser.

Anda selalu dapat menggunakan mode kompatibilitas di browser agar tetap berfungsi.

Untuk membuktikan maksud saya, hanya beberapa bulan yang lalu saya memperbaiki bug milenium dalam kode javascript untuk pelanggan, yang telah menjalankan aplikasi web mereka selama 17 tahun. Masih berfungsi pada mesin terbaru, basis data terkini, sistem operasi terbaru.

Kesimpulan: tetap sederhana dan bersih dan Anda harus baik-baik saja.

Jonathan van de Veen
sumber
1
Frame dan iframe didefinisikan dengan sangat baik dalam spesifikasi HTML. Apa yang membuat mereka tidak cocok?
curiousdannii
3
@curiousdannii: Tidak terlalu banyak menggunakan iframe (bingkai tidak lagi didukung dalam HTML5), seperti penggunaan bingkai dan iframe untuk memuat konten secara tidak sinkron melalui skrip, dll. Ini dapat bekerja dengan baik sekarang, tetapi akan selalu bekerja dengan baik saat ini, tetapi dikenakan perubahan keamanan.
Jonathan van de Veen
-2

Beberapa aksioma:

  • Kebenaran bertahan. Dalam konteks ini, itu akan menjadi algoritma dan model data - apa yang sebenarnya mewakili "apa" dan "bagaimana" dari ruang masalah Anda. Meskipun, selalu ada potensi untuk perbaikan dan perbaikan, atau evolusi dari masalah itu sendiri.
  • Bahasa berkembang. Ini berlaku untuk bahasa komputer seperti halnya untuk bahasa alami.
  • Semua teknologi rentan terhadap usang. Mungkin butuh waktu lebih lama untuk beberapa teknologi daripada yang lain

Teknologi dan standar paling stabil (yang paling tidak rentan terhadap keusangan) cenderung adalah yang tidak berpemilik dan telah diadopsi secara luas. Semakin luas adopsi, semakin besar inersia terhadap hampir semua bentuk perubahan. "Standar" hak milik selalu rentan terhadap nasib dan keinginan pemiliknya dan kekuatan kompetitifnya.

Dua puluh tahun adalah waktu yang sangat lama di industri komputer. Lima tahun adalah target yang lebih realistis. Dalam waktu lima tahun, seluruh masalah yang ingin diselesaikan oleh aplikasi Anda dapat sepenuhnya didefinisikan ulang.

Beberapa contoh untuk menggambarkan:

C dan C ++ sudah ada sejak lama. Mereka memiliki implementasi di hampir semua platform. C ++ terus berkembang, tetapi fitur "universal" (yang tersedia di semua platform) dijamin tidak akan pernah ditinggalkan.

Flash hampir menjadi standar universal, tetapi ini adalah hak milik. Keputusan perusahaan untuk tidak mendukungnya di platform seluler populer pada dasarnya telah membinasakannya di mana saja - jika Anda membuat situs web, Anda ingin konten Anda tersedia di semua platform; Anda tidak ingin ketinggalan pasar seluler utama.

WinTel (Windows / x86) meskipun milik Microsoft dan Intel, setelah dimulai pada platform yang kurang optimal (internal 16 bit / 8 bit eksternal 8088 vs Apple Macintosh kontemporer 32 bit internal / 16 bit eksternal 68000), dan erosi untuk Apple di pasar konsumen tetap menjadi pilihan de facto untuk platform bisnis. Dalam semua waktu (25 tahun), komitmen terhadap kompatibilitas ke belakang telah menghambat pembangunan di masa depan dan menginspirasi keyakinan yang cukup besar bahwa apa yang bekerja pada kotak lama akan tetap bekerja pada yang baru.

Pikiran terakhir

JavaScript mungkin bukan pilihan terbaik untuk menerapkan logika bisnis. Untuk alasan integritas dan keamanan data, logika bisnis harus dilakukan di server, sehingga JavaScript sisi klien harus dibatasi untuk perilaku UI. Bahkan di server, JavaScript mungkin bukan pilihan terbaik. Meskipun lebih mudah untuk dikerjakan daripada tumpukan lain (Java atau C #) untuk proyek-proyek kecil, itu tidak memiliki formalitas yang dapat membantu Anda menulis solusi yang lebih baik, lebih terorganisir ketika semuanya menjadi lebih kompleks.

Zenilogix
sumber