Alat, perpustakaan, dan kerangka kerja yang kami gunakan untuk membina aplikasi web kami hari ini sangat berbeza dengan yang kami gunakan beberapa tahun yang lalu.
Dalam beberapa tahun yang singkat dari sekarang, kebanyakan teknologi ini akan berubah secara mendadak lagi. Namun, ramai di antara kita menjadikan ini sebagai bahagian terpenting dari aplikasi kita.
Kami mengimport, menggunakan, dan mewarisi kerangka rasa bulan seolah-olah semuanya akan ada dan tidak berubah selamanya. Baiklah ... mereka tidak. Dan itu masalah.
Setelah 20+ tahun mengembangkan, merancang, dan membuat arkitek aplikasi web, saya menghargai dua kebenaran penting:
- Pergantungan luaran menimbulkan ancaman besar terhadap kestabilan dan daya maju jangka panjang mana-mana aplikasi.
- Semakin sukar - jika tidak mustahil - untuk membina jenis aplikasi tidak remeh tanpa memanfaatkan pergantungan luaran.
Artikel ini adalah mengenai mendamaikan kedua kebenaran ini agar aplikasi kita mempunyai peluang terbesar untuk bertahan lama.
Lubang arnab memang sangat dalam.
Sekiranya kita mula memikirkan semua perkara yang bergantung pada aplikasi web kita, mudah difikirkan selusin atau lebih sebelum kita sampai ke kodnya:
- Kuasa
- Kesalinghubungan
- Firewall
- DNS
- Perkakasan Pelayan (CPU, Disk, Ram,…)
- Menyejukkan
- Platform Virtualisasi
- Platform Kontena
- Sistem operasi
- Platform Pelayan Web
- Platform Pelayan Aplikasi
- Pelayar web
Sebagai pembangun, ada baiknya kita mengetahui perkara ini, tetapi selalunya tidak banyak yang dapat kita lakukan mengenainya. Oleh itu, mari kita abaikan mereka buat masa ini dan hanya membincangkan kodnya.
Dalam kod, terdapat tiga jenis kebergantungan:
1. Ketergantungan yang kita kendalikan
Ini adalah kod yang ditulis dan dimiliki oleh kami atau organisasi kami.
2. Ketergantungan yang tidak kita kendalikan
Ini adalah kod yang ditulis oleh vendor pihak ketiga atau komuniti perisian sumber terbuka.
3. Tanggungan setelah dikeluarkan
Ini adalah kebergantungan kod yang bergantung pada kod pihak ketiga kami. (Katakan tiga kali cepat!)
Kita akan bercakap terutamanya mengenai pergantungan yang tidak kita kendalikan .
Ketergantungan yang kita kendalikan dan kebergantungan setelah dihapus masih boleh menyebabkan sakit kepala, tetapi dalam hal ketergantungan yang kita kendalikan, kita harus dapat campur tangan secara langsung dan mengurangkan masalah.
Sekiranya tanggungan dilepaskan, kita biasanya boleh bergantung pada pihak ketiga untuk menjaganya, kerana mereka juga bergantung pada ini.
Mengapa pergantungan kod pihak ketiga bagus
Sebilangan besar aplikasi web anda ada untuk menyelesaikan masalah umum: pengesahan, pengesahan, akses data, pengendalian ralat, navigasi, pembalakan, penyulitan, memaparkan senarai item, mengesahkan input borang, dan sebagainya ...
Terlepas dari tumpukan teknologi mana yang anda gunakan, ada kemungkinan besar penyelesaian umum untuk masalah ini ada, dan tersedia sebagai perpustakaan yang dapat anda peroleh dan pasangkan ke pangkalan data dengan mudah. Menulis barang-barang ini sepenuhnya dari awal biasanya membuang masa.
Anda ingin menumpukan perhatian pada kod yang dapat menyelesaikan masalah yang tidak biasa atau menyelesaikan masalah yang biasa dengan cara yang tidak biasa. Itulah yang menjadikan aplikasi anda berharga: kod yang menerapkan peraturan perniagaan yang unik untuk aplikasi anda sahaja - "sos rahsia".
Algoritma carian dan kedudukan halaman Google, penapisan garis masa Facebook, bahagian Netflix "disyorkan untuk anda" dan algoritma pemampatan data - kod di sebalik semua ciri ini adalah "rahsia."
Kod pihak ketiga - dalam bentuk perpustakaan - membolehkan anda dengan cepat melaksanakan ciri komoditi aplikasi anda, sehingga anda dapat terus fokus pada "sos rahsia" anda.
Mengapa pergantungan kod pihak ketiga buruk
Lihatlah aplikasi web yang tidak sepele yang dibina dalam beberapa tahun kebelakangan ini dan anda pasti akan terkejut dengan jumlah kod yang sebenarnya berasal dari perpustakaan pihak ketiga. Bagaimana jika satu atau lebih perpustakaan pihak ketiga tersebut berubah secara drastik, atau hilang, atau rosak?
Sekiranya sumber terbuka, mungkin anda boleh memperbaikinya sendiri. Tetapi sejauh mana anda memahami semua kod di perpustakaan yang tidak anda miliki? Sebab utama mengapa anda menggunakan perpustakaan adalah untuk mendapatkan kelebihan kod tersebut tanpa perlu risau tentang semua butirannya. Tetapi sekarang anda buntu. Anda benar-benar mengikat kekayaan anda dengan kebergantungan ini yang tidak anda miliki dan tidak anda kendalikan.
Mungkin anda fikir saya berlebihan, atau bercakap dari sudut akademik semata-mata. Izinkan saya memberi jaminan kepada anda - Saya mempunyai puluhan contoh pelanggan yang benar-benar mengejek mereka dengan memasukkan kod pihak ketiga terlalu ketat ke dalam aplikasinya. Inilah satu contoh baru-baru ini ...
Seorang bekas pelanggan saya membina aplikasi mereka menggunakan penyedia Backend-as-a-Service yang dimiliki oleh Facebook, yang dipanggil Parse. Mereka menggunakan perpustakaan klien JavaScript yang disediakan oleh Parse untuk menggunakan perkhidmatan Parse. Dalam proses itu, mereka menggabungkan semua kod mereka - termasuk kod "sos rahsia" dengan erat ke perpustakaan ini.
Tiga bulan selepas pelancaran produk awal pelanggan saya - sama seperti mereka mula mendapat daya tarikan yang baik dengan pelanggan yang sebenar dan berbayar - Parse mengumumkan bahawa ia akan ditutup.
Sekarang, bukannya menumpukan pada iterasi pada produk mereka dan mengembangkan basis pelanggan mereka, pelanggan saya harus memikirkan cara untuk berhijrah ke versi Parse yang di-host sendiri, atau sumber Parse sepenuhnya.
Gangguan ini disebabkan oleh aplikasi muda yang masih muda begitu besar sehingga pelanggan saya akhirnya membatalkan aplikasi tersebut.
Mengimbangkan yang baik dan yang buruk
Beberapa tahun yang lalu, jalan keluar saya untuk mengatasi risiko sambil mengekalkan faedah perpustakaan pihak ketiga adalah membungkusnya menggunakan Adapter Pattern.
Pada dasarnya, anda membungkus kod pihak ketiga dalam kelas atau modul penyesuai yang telah anda tulis. Ini kemudian berfungsi untuk mendedahkan fungsi perpustakaan pihak ketiga dengan cara yang anda kendalikan.
Dengan menggunakan corak ini, jika perpustakaan atau kerangka kerja pihak ketiga berubah, atau hilang, anda hanya perlu memperbaiki sedikit kod penyesuai. Selebihnya aplikasi anda tetap utuh.
Ini kedengaran baik di atas kertas. Apabila anda mempunyai pergantungan mandiri yang hanya menyediakan beberapa fungsi, ini akan berjaya. Tetapi perkara boleh menjadi buruk dengan cepat.
Bolehkah anda bayangkan perlu membungkus keseluruhan pustaka React (termasuk JSX) sebelum menggunakannya? Bagaimana dengan membungkus jQuery, atau Angular, atau rangka Spring di Java? Ini dengan cepat menjadi mimpi ngeri.
Hari-hari ini saya mencadangkan pendekatan yang lebih bernuansa…
Untuk setiap kebergantungan yang ingin anda tambahkan ke pangkalan data anda, nilaikan tahap risiko yang akan ditimbulkannya dengan mengalikan dua faktor:
- Kemungkinan kebergantungan akan berubah secara material.
- Jumlah kerosakan yang akan diubah oleh dependensi terhadap aplikasi anda.
Perpustakaan atau kerangka kerja pihak ketiga cenderung tidak berubah apabila beberapa atau semua perkara berikut benar:
- Sudah ada selama beberapa tahun dan mempunyai beberapa rilis utama.
- Ia digunakan secara meluas oleh banyak aplikasi komersial.
- Ia mempunyai sokongan aktif dari organisasi besar - sebaiknya syarikat atau institusi nama rumah tangga.
Perpustakaan atau kerangka kerja pihak ketiga akan mengurangkan kerosakan pada aplikasi anda apabila beberapa atau semua perkara berikut benar:
- Ini hanya digunakan oleh sebahagian kecil aplikasi anda, dan bukan digunakan di seluruh.
- Kod yang bergantung padanya bukan sebahagian daripada "sos rahsia" yang saya bicarakan sebelumnya.
- Mengeluarkannya memerlukan sedikit perubahan pada pangkalan data anda.
- Keseluruhan aplikasi anda sangat kecil dan dapat ditulis semula dengan cepat. (Hati-hati dengan yang ini - jarang berlaku lama sekali.)
Sesuatu yang lebih berisiko, semakin besar kemungkinan anda membungkusnya atau menghindarinya sama sekali.
Mengenai kod yang sangat penting bagi cadangan nilai aplikasi anda - "sos rahsia" anda - anda harus sangat melindungi terhadapnya. Jadikan kod itu sebebas mungkin. Sekiranya anda benar-benar perlu menggunakan ketergantungan, pertimbangkan untuk menyuntikkannya daripada terus merujuknya. Walaupun begitu, berhati-hatilah.
Kadang-kadang ini bermaksud mengatakan "tidak" ke perpustakaan pihak ketiga yang anda fikir sangat keren, atau yang anda benar-benar mahu gunakan untuk satu sebab atau yang lain. Kuatkan diri. Percayalah, ia akan membuahkan hasil. Tanya sahaja kepada semua orang yang membuat pelaburan besar pada keluaran pertama Angular, atau bekas pelanggan saya yang menggunakan Parse di mana sahaja. Ia tidak menyeronokkan. Percayakan saya.
Bercakap tentang keseronokan, lihatlah ini ...
Gambar di atas adalah grafik ketergantungan untuk aplikasi yang dipanggil TinyTag Explorer.
Menghasilkan grafik ketergantungan untuk aplikasi yang ada adalah cara terbaik untuk memahami tahap risiko yang diperkenalkan oleh pergantungan anda. Saya telah mengumpulkan senarai alat percuma untuk menghasilkan grafik yang serupa dengan yang di atas dalam pelbagai bahasa termasuk JavaScript, C #, Java, PHP, dan Python. Anda boleh mendapatkannya di sini.
Tolonglah saya menolong orang lain
Saya ingin membantu seberapa banyak pembangun yang saya dapat dengan berkongsi pengetahuan dan pengalaman saya dengan mereka. Tolong bantu saya dengan mengklik butang ❤ cadangan (hati hijau) di bawah.
Akhirnya, jangan lupa untuk mengambil senarai penjana grafik pergantungan percuma anda di sini.