Frontend Fundamentals

Toss Frontend Chapter telah menerbitkan sebuah situs yang memperkenalkan standar mereka tentang seperti apa kode frontend yang baik.

• Dijelaskan berdasarkan TypeScript, yang paling sering digunakan oleh para pengembang frontend
• Menyajikan best practice dari empat sudut pandang: keterbacaan, prediktabilitas, kohesi, dan kopling
• Menyediakan contoh yang memanfaatkan library yang sering digunakan di frontend nyata

4 kriteria

1. Keterbacaan
   Keterbacaan (Readability) adalah sejauh mana kode mudah dibaca. Agar kode mudah diubah, pertama-tama kita harus bisa memahami perilaku apa yang dilakukan oleh kode tersebut.

2. Prediktabilitas
   Prediktabilitas (Predictability) adalah seberapa jauh rekan kerja yang berkolaborasi bersama dapat memprediksi perilaku fungsi atau komponen. Kode dengan prediktabilitas tinggi mengikuti aturan yang konsisten, dan hanya dengan melihat nama fungsi atau komponen, parameter, serta nilai kembalian, kita bisa mengetahui perilaku apa yang dijalankannya.

3. Kohesi
   Kohesi (Cohesion) adalah apakah kode yang perlu diubah selalu diubah bersama. Kode dengan kohesi tinggi tidak akan menimbulkan error secara tidak sengaja di bagian lain hanya karena satu bagian kode diubah. Itu karena strukturnya mendukung agar bagian-bagian yang memang harus diubah bersama benar-benar diubah bersama.

4. Kopling
   Kopling (Coupling) adalah cakupan dampak ketika kode diubah. Kode yang mudah diubah adalah kode yang memiliki dampak perubahan kecil, sehingga cakupan perubahan yang terjadi dapat diprediksi.

[savvykang]

Saya penasaran mengapa file digunakan sebagai unit pengelolaan minimum untuk komponen dan hook. Saya bisa menebak mungkin karena dukungan IDE atau tree shaking yang kurang memadai, tetapi saya tidak yakin, jadi saya ingin bertanya.

Saat membaca kode, ketika melihat file yang hanya berisi satu fungsi atau file index.ts yang hanya berisi pernyataan import/export, jumlah hal yang harus diingat jadi bertambah. Dibandingkan dengan pendekatan mencampur hook dan komponen dalam satu file, menurut saya penataan seperti itu meningkatkan beban kognitif lebih dari yang diperlukan. Meski begitu, adakah kelebihan atau alasan menggunakan penataan seperti itu?

[firea32]

Biasanya, premis besar dari “pengembangan yang baik” yang dibicarakan di tempat seperti ini adalah bahwa ada banyak developer yang sedang mengerjakannya.
Seperti yang Anda katakan, bertambahnya hal yang harus diingat = berarti Anda sendiri memikul tanggung jawab atas keseluruhan proyek, tetapi
Di lingkungan dengan banyak developer, orang biasanya hanya mengembangkan bagian yang menjadi tanggung jawabnya.
Kalau muncul masalah, cukup melihat bagian itu saja; tidak perlu menelusuri semua bagian yang terkait.
Kalau dilihat dari satu sisi, ini bisa dianggap sebagai memilih produktivitas alih-alih optimisasi yang ekstrem.

[savvykang]

Seperti yang Anda sampaikan, dalam lingkungan yang memungkinkan pembagian tugas kerja dipecah lebih rinci, isi tulisan ini merupakan pilihan yang tepat. Saya rasa tulisan ini akan menjadi lebih utuh jika juga menjelaskan trade-off saat memisahkan kode serta kriteria untuk menentukannya.

[beenzinozino]

Dalam kasus saya, alasan menggunakan file sebagai unit pengelolaan minimum untuk komponen atau hook saat mengembangkan frontend adalah sebagai berikut.

1. Kemudahan pengujian.

Artinya, lebih mudah mencocokkan satu unit test dengan satu modul.

Saya pikir pengembangan frontend didominasi oleh paradigma yang menggunakan pure function, tetapi jika ada beberapa fungsi dalam satu file, akan sulit membuat pencocokan 1 banding 1 saat menulis unit test.

Jika ada beberapa fungsi utilitas dalam satu file bernama remark-plugin.js, bagaimana sebaiknya kita menulis test-nya? Apakah membuat hanya satu file remark-plugin.test.js lalu menulis test untuk beberapa fungsi utilitas sekaligus merupakan pilihan yang baik?

Dalam situasi seperti ini, jika kita membuat direktori bernama remark-plugins, lalu memecah dan memisahkan fungsi-fungsi utilitas di dalamnya satu per satu untuk ditest, saya rasa ada keuntungan seperti peran tiap fungsi menjadi lebih jelas di kemudian hari, dan pelacakan commit di GitHub juga menjadi jauh lebih rapi.

2. Penataan struktur direktori

Modul bundler seperti commonjs di pengembangan server atau webpack di sisi klien sering menetapkan file index.js sebagai file entry untuk direktori tertentu. Ini juga merupakan kebiasaan yang sudah lama sering digunakan, jadi sebagian alasannya memang karena kita menerimanya sebagai konvensi.

Namun menurut saya, alasan yang paling penting adalah bahwa dalam paradigma pure function pada pemrograman fungsional, kita tidak boleh bergantung pada state eksternal, sehingga jika banyak fungsi berkumpul dalam satu file, kemungkinan terjadinya kesalahan dengan mereferensikan state eksternal akan lebih tinggi. (Mungkin ada baiknya memikirkan alasan mengapa module scope muncul di ES6.)

3. Kemudahan melacak commit.

Secara pribadi, dibanding beberapa fungsi utilitas bercampur dalam satu file, jika fungsi-fungsi itu dipecah ke file masing-masing, pelacakan riwayat commit terasa jauh lebih sederhana.

Ketika ada fitur yang ditambahkan atau bug yang diperbaiki pada suatu modul, kita bisa fokus hanya pada satu modul tanpa perlu merujuk ke modul lain.

---

Ternyata tulisan ini jadi panjang dan agak tidak terlalu terstruktur saat ditulis. (Saya juga masih belum terlalu paham soal tree shaking, jadi saya akan berhati-hati untuk tidak banyak berkomentar tentang itu...) Tentu saja, apa yang saya katakan belum tentu merupakan jawaban yang benar, jadi semoga bisa dilihat sebagai bahan referensi saja!

[thkimdev]

Ini bagus ya

[illiil1lii]

Tulisannya ternyata disusun dengan sangat baik dan enak dibaca. Saya merekomendasikannya.

[tsboard]

Terima kasih sudah membagikannya! Saya juga harus membacanya dengan saksama.

[bbulbum]

Meskipun ini ditulis terbatas untuk FE, rasanya ini adalah hal-hal yang bagus untuk diterapkan pada perangkat lunak secara umum. Terima kasih telah membagikan insight yang sangat bagus.