Kesesuaian dalam ekosistem framework JavaScript
Dalam postingan blog pengantar, kami membahas banyak hal yang telah kami pelajari selama membangun serta menggunakan framework dan alat untuk mengembangkan dan memelihara aplikasi web berskala besar seperti Google Penelusuran, Maps, Foto, dan sebagainya. Dengan melindungi developer dari penulisan kode yang dapat memengaruhi pengalaman pengguna secara negatif, kami membuktikan bahwa framework dapat berperan penting dalam mengubah hasil performa dan kualitas aplikasi.
Di Google, secara internal kami menggunakan istilah "Kesesuaian" untuk menjelaskan metodologi ini, dan artikel ini membahas bagaimana kami berencana untuk menjadikan konsep ini open source ke ekosistem framework JavaScript.
Apa itu Kesesuaian?
Di Google, Kesesuaian adalah sebuah evolusi. Tim mengandalkan sekelompok kecil pengelola yang sangat berpengalaman yang melakukan peninjauan kode secara ekstensif, melaporkan hal-hal yang memengaruhi kualitas dan pengelolaan aplikasi, yang jauh di luar masalah ketepatan. Untuk meningkatkan skalanya ke tim developer aplikasi yang sedang berkembang, sistem Kesesuaian dikembangkan untuk mengodifikasi praktik terbaik secara otomatis dan dapat diterapkan. Hal ini memastikan standar yang tinggi secara konsisten untuk kualitas aplikasi dan pemeliharaan codebase terlepas dari jumlah kontributor kode.
Kesesuaian adalah sistem yang memastikan developer tetap berada di jalur yang jelas; sistem ini membangun kepercayaan diri dan memastikan hasil yang dapat diprediksi. Hal ini membuat tim produktif dan menjadi penting untuk skala -- seiring pertumbuhan tim dan lebih banyak fitur yang dikembangkan secara bersamaan. Dengan demikian, developer dapat fokus untuk membangun fitur produk, sehingga terbebas dari hal-hal kecil dan lanskap yang berubah di berbagai area seperti performa, aksesibilitas, keamanan, dll. Siapa saja dapat memilih untuk tidak mengikuti Kesesuaian kapan saja, dan fitur ini harus dapat disesuaikan sejauh tim akan memiliki opsi untuk menerapkan apa pun yang mereka putuskan untuk dijalankan.
Kesesuaian didasarkan pada default yang kuat dan memberikan aturan yang dapat ditindaklanjuti yang dapat diberlakukan pada waktu pembuatan. Hal ini diuraikan menjadi 3 prinsip berikut.
1. Default yang kuat
Aspek dasar kesesuaian adalah memastikan bahwa alat yang digunakan developer memiliki setelan default yang kuat. Ini berarti solusi tidak hanya dimasukkan ke dalam framework, tetapi juga pola desain framework memudahkan Anda melakukan hal yang benar dan sulit untuk mengikuti anti-pola. Framework ini mendukung developer dengan desain aplikasi dan struktur kode.
Untuk performa pemuatan, setiap resource (font, CSS, JavaScript, gambar, dll.) harus dioptimalkan. Ini adalah tantangan kompleks yang melibatkan pemangkasan byte, mengurangi perjalanan bolak-balik, dan memisahkan hal-hal yang diperlukan untuk render pertama, kesiapan visual, dan interaksi pengguna. Misalnya, mengekstrak CSS penting, dan menetapkan prioritas pada gambar penting.
2. Aturan yang dapat ditindaklanjuti
Bahkan dengan pengoptimalan dasar, developer masih harus membuat pilihan. Ada berbagai kemungkinan untuk pengoptimalan terkait jumlah input developer yang diperlukan:
- Setelan default yang tidak memerlukan input developer seperti menyisipkan CSS penting.
- Wajibkan persetujuan developer. Misalnya, menggunakan komponen gambar yang disediakan framework untuk mengukur dan menskalakan gambar.
- Memerlukan persetujuan dan penyesuaian developer. Misalnya, memberi tag pada gambar penting untuk dimuat lebih awal.
- Bukan fitur spesifik, tetapi beberapa hal yang masih memerlukan keputusan developer. Misalnya, hindari font atau skrip sinkron yang menunda rendering awal.
Pengoptimalan yang memerlukan keputusan apa pun dari developer dapat menimbulkan risiko bagi performa aplikasi. Seiring penambahan fitur dan tim Anda berkembang, developer yang paling berpengalaman pun tidak dapat mengikuti praktik terbaik yang terus berubah. Ini juga bukan penggunaan waktu terbaik mereka. Untuk Kesesuaian, aturan yang tepat dan dapat ditindaklanjuti sama pentingnya dengan default yang kuat untuk memastikan aplikasi terus memenuhi standar tertentu bahkan saat developer terus melakukan perubahan.
3. Waktu pembuatan
Penting untuk mengetahui dan mencegah masalah performa di awal siklus proses pengembangan. Waktu pembuatan, sebelum kode di-commit, idealnya cocok untuk menangkap dan mengatasi masalah. Semakin lama masalah terjebak dalam siklus proses pengembangan, semakin sulit dan mahal untuk mengatasinya. Meskipun hal ini berlaku untuk masalah ketepatan, hal ini juga berlaku untuk masalah performa, karena banyak dari masalah ini tidak akan ditangani secara surut setelah diterapkan ke codebase.
Saat ini, sebagian besar masukan performa bersifat out-of-band melalui dokumentasi, audit satu kali, atau masukan tersebut terlalu terlambat ditampilkan melalui regresi metrik setelah deployment ke produksi. Kami ingin menghadirkan hal ini pada waktu penulisan.
Kesesuaian dalam Framework
Untuk mempertahankan standar pengalaman pengguna yang tinggi untuk performa pemuatan, pertanyaan-pertanyaan berikut perlu dijawab:
- Apa yang dimaksud dengan pemuatan optimal, dan apa masalah umum yang dapat berdampak buruk pada pemuatan tersebut?
- Solusi mana yang dapat diimplementasikan yang tidak memerlukan input developer?
- Bagaimana cara memastikan bahwa developer menggunakan solusi ini dan memanfaatkannya secara optimal?
- Apa pilihan lain yang dapat dibuat oleh developer sehingga memengaruhi performa pemuatan?
- Apa saja pola kode yang dapat memberi tahu kita tentang pilihan ini (#3 dan #4 di atas) lebih awal pada waktu pembuatan?
- Aturan apa yang dapat kita rumuskan untuk menilai pola kode ini? Bagaimana desainer dapat ditampilkan kepada developer pada waktu pembuatan sambil diintegrasikan dengan lancar ke dalam alur kerja?
Untuk menghadirkan model Kesesuaian yang kami miliki secara internal di Google ke framework open source, tim kami telah banyak bereksperimen di Next.js dan kami sangat senang dapat membagikan visi dan rencana kami yang telah disempurnakan. Kami menyadari bahwa rangkaian aturan terbaik yang dapat menilai pola kode perlu berupa kombinasi analisis kode statis dan pemeriksaan dinamis. Aturan ini dapat mencakup beberapa platform, termasuk:
- ESLint
- TypeScript
- Pemeriksaan dinamis di server pengembangan pengguna (setelah pembuatan DOM)
- Pemaket modul (webpack)
- Alat CSS (masih bersifat eksplorasi)
Dengan memanfaatkan penyediaan aturan melalui berbagai alat, kita dapat memastikan aturan tersebut kohesif, tetapi juga mencakup masalah pengalaman pengguna yang langsung memengaruhi performa pemuatan. Selain itu, aturan ini juga dapat ditampilkan kepada developer pada waktu yang berbeda:
- Selama pengembangan lokal di server pengembangan, browser dan IDE pengguna akan menampilkan peringatan, yang meminta developer untuk membuat perubahan kecil pada kode.
- Pada waktu build, masalah yang belum terselesaikan akan ditampilkan kembali di terminal pengguna
Singkatnya, tim akan memilih hasil yang penting bagi mereka, seperti Data Web Inti atau performa pemuatan, dan mengizinkan kumpulan aturan yang relevan untuk diikuti oleh semua kontributor kode.
Meskipun cara ini sangat cocok untuk project baru, tidak mudah untuk mengupgrade codebase besar agar mematuhi kumpulan aturan lengkap. Di Google, kami memiliki sistem yang luas untuk memilih tidak ikut di berbagai tingkat, seperti baris kode sumber individual, seluruh direktori, codebase lama, atau bagian aplikasi yang tidak dalam pengembangan aktif. Kami secara aktif mengeksplorasi strategi yang efektif untuk menghadirkan hal ini kepada tim dengan menggunakan framework open source.
Kesesuaian di Next.js
ESLint banyak digunakan di kalangan developer JavaScript, dan lebih dari 50% aplikasi Next.js menggunakan ESLint di beberapa bagian alur kerja build mereka. Next.js v11 memperkenalkan dukungan ESLint siap pakai yang menyertakan plugin kustom dan konfigurasi yang dapat dibagikan untuk memudahkan penangkapan masalah umum khusus framework selama pengembangan dan waktu build. Hal ini dapat membantu developer memperbaiki masalah yang signifikan pada waktu pembuatan. Contohnya termasuk saat komponen tertentu digunakan, atau tidak digunakan, dengan cara yang dapat menurunkan performa seperti pada Tidak ada link HTML untuk halaman). Atau, jika font, stylesheet, atau skrip tertentu dapat berpengaruh negatif terhadap pemuatan resource di halaman. Misalnya, Tidak ada skrip sinkron.
Selain ESLint, pemeriksaan jenis terintegrasi dalam pengembangan dan produksi telah didukung di Next.js sejak v9 dengan dukungan TypeScript. Beberapa
komponen yang disediakan oleh framework (Gambar, Skrip, Link) telah dibuat sebagai ekstensi elemen
HTML (<img>, <script>, <a>) untuk memberikan pendekatan berperforma tinggi kepada developer dalam menambahkan
konten ke halaman web. Pemeriksaan jenis mendukung penggunaan fitur yang tepat dengan memastikan bahwa properti dan opsi yang ditetapkan berada dalam cakupan nilai dan jenis yang didukung yang dapat diterima. Lihat
lebar dan tinggi gambar wajib untuk
contoh.
Menampilkan Error dengan Toast dan Overlay
Seperti yang disebutkan sebelumnya, Aturan kesesuaian dapat dimunculkan di beberapa area. Toast dan overlay saat ini sedang dieksplorasi sebagai cara untuk menampilkan error secara langsung di browser dalam lingkungan pengembangan lokal pengguna.
Banyak alat pemeriksaan error dan pengauditan yang diandalkan developer (tab Lighthouse, Chrome DevTools Issues) bersifat pasif dan memerlukan beberapa bentuk interaksi pengguna untuk mengambil informasi. Developer cenderung bertindak saat error muncul langsung dalam alat yang ada, dan saat memberikan tindakan konkret serta spesifik yang harus diambil untuk memperbaiki masalah tersebut.
Kesesuaian dalam Framework Lain
Kesesuaian dieksplorasi di Next.js terlebih dahulu dengan tujuan memperluas ke framework lain (Nuxt, Angular, dll.). ESLint dan TypeScript sudah digunakan di banyak framework dengan berbagai cara, tetapi konsep sistem runtime tingkat browser yang kohesif sedang dieksplorasi secara aktif.
Kesimpulan
Kesesuaian mengodifikasi praktik terbaik ke dalam kumpulan aturan yang dapat ditindaklanjuti oleh developer sebagai pola kode sederhana. Tim Aurora telah berfokus pada performa pemuatan, tetapi praktik terbaik lainnya, seperti aksesibilitas dan keamanan, juga tetap berlaku.
Mengikuti aturan Kesesuaian akan memberikan hasil yang dapat diprediksi, dan mencapai standar tinggi untuk pengalaman pengguna dapat menjadi efek samping dari pengembangan tech stack Anda. Kesesuaian membuat tim produktif, dan memastikan standar berkualitas tinggi untuk aplikasi, meskipun tim dan codebase terus berkembang dari waktu ke waktu.