Bagaimana cara Refactor CSS - A Guide
Refactoring CSS perlu menjadi bagian penting dari alur kerja pengembangan front-end, jika kita ingin memiliki basis kode yang dikelola dan dioptimalkan. Ketika kami mereformasi CSS, kami bersihkan dan atur ulang kode yang ada tanpa menambahkan fitur baru atau memperbaiki bug.
Refactoring membantu mencegah ledakan CSS, meningkatkan keterbacaan kode dan penggunaan kembali, dan membuat CSS lebih ramping dan lebih cepat untuk dieksekusi.
Refactoring biasanya diperlukan setelah beberapa saat, karena bahkan proyek yang dimulai dengan basis kode yang ringkas dan terorganisir cepat atau lambat mulai kehilangan kejelasan mereka; konsistensi, aturan usang dan duplikat bagian kode muncul; dan kami juga mulai mengesampingkan gaya dan menggunakan lebih banyak peretasan dan penyelesaian masalah.
Cara terbaik untuk menjaga basis kode CSS kami tetap terpelihara adalah dengan tetap menggunakan “refactor awal, sering refactor” aturan praktis. Dalam posting ini kita akan melihat beberapa tips tentang bagaimana kita dapat melakukan proses refactoring CSS yang efektif.
1. Melakukan Audit Awal
Untuk memiliki gambaran yang lebih baik tentang apa yang perlu kita refactor, itu yang terbaik untuk mulai dengan audit komprehensif untuk melihat apa yang kita miliki saat ini.
Ada banyak alat online hebat yang dapat membantu kami dalam upaya ini. CSSDig adalah ekstensi Chrome yang kuat yang menganalisis CSS suatu situs web, dan mengeksplorasi kelemahannya, seperti penyeleksi yang terlalu spesifik atau properti berulang.
CSS yang tidak digunakan menyelidiki aturan CSS yang tidak digunakan, sementara alat linting, seperti CSS Lint, memungkinkan untuk dengan cepat menemukan kompabilitas, rawatan dan masalah lainnya.
Penting juga untuk memeriksa kode secara manual selama audit awal, karena banyak masalah di tingkat arsitektur hanya dapat ditangkap dengan cara ini.
2. Mengatur Rencana yang Dapat Dielola
Kode kerja refactoring selalu merupakan tugas yang menakutkan, tetapi kita dapat meringankan rasa sakit jika kita membuat rencana tentang apa yang perlu kita lakukan, mengiris proses refactoring menjadi potongan yang dapat dikelola, dan membuat jadwal yang layak.
Di CSS refactoring ada hal penting yang selalu perlu Anda pertimbangkan: beberapa hal yang kami refactor, mis. mengubah nama pemilih, akan membuatnya diperlukan untuk menyesuaikan kode file HTML dan JavaScript yang relevan demikian juga.
Karena itu ide yang bagus untuk itu lacak maju modifikasi tambahan ini yang perlu kami lakukan, dan masukkan mereka ke dalam jadwal refactoring kami bersama dengan tugas-tugas utama yang berhubungan dengan CSS.
3. Lacak Kemajuan
Sebelum memulai refactoring, ini merupakan langkah penting buat cadangan file awal kami. Memperkenalkan sistem kontrol versi, seperti Git atau Subversion, ke dalam alur kerja kami juga dapat secara signifikan meningkatkan proses refactoring, karena kami akan memiliki registri tentang langkah-langkah berurutan yang telah kami ambil, dan kami akan dapat kembali ke tahap sebelumnya jika kita ingin mengulang hal-hal.
4. Tetap berpegang pada Panduan Gaya Pengkodean
Panduan gaya pengkodean yang koheren dapat sangat meningkatkan keterbacaan dan pemeliharaan kode, jadi sebelum kita mulai memperbaiki itu penting untuk mengatur panduan gaya pengkodean CSS.
Hal-hal penting untuk diputuskan adalah:
- konvensi penamaan
- aturan pemformatan
- perintah deklarasi
- unit dan nilai yang ingin kita gunakan
- aturan berkomentar
Jika kami tidak ingin membuat panduan gaya pengkodean kami sendiri, kami juga dapat menggunakan panduan orang lain, seperti ThinkUp yang dapat ditemukan di Github.
Meskipun tidak cukup hanya dengan memperkenalkan panduan gaya pengkodean, kita juga perlu melakukannya berpegang teguh pada itu ketika kita menulis ulang kode selama refactoring, dan mengharapkan hal yang sama dari orang lain yang bekerja di proyek kami.
5. Mengatur Struktur File yang Koheren
Setelah kita siap dengan persiapan, hal pertama yang perlu kita lakukan adalah mengatur struktur file CSS yang tepat yang memperhatikan sifat cascading dari CSS.
Ini terutama tergantung pada proyek bagaimana cara terbaik mengatur file kita, tetapi ada beberapa aturan universal, seperti menggunakan yang terpisah normalize.css file untuk gaya reset CSS, terpisah global.css untuk gaya global yang digunakan di seluruh proyek, dan untuk menyimpan perpustakaan pihak ke-3 dalam folder terpisah.
Jika kita ingin bermain aman dengan struktur file CSS kita, ada juga arsitektur yang sudah jadi, seperti SMACSS atau ITCSS, yang menawarkan teknik efektif tentang cara mengatur file CSS dengan cara yang dapat diskalakan.
6. Singkirkan Aturan yang Tidak Digunakan dan Duplikat
Setelah beberapa saat, file CSS biasanya mulai berlimpah dalam aturan yang tidak terpakai yang perlu kita identifikasi dan bersihkan selama refactoring. Ada banyak alat online yang memungkinkan kita selidiki aturan-aturan usang ini, dan kadang-kadang juga memungkinkan kita untuk membuang mereka dengan cepat.
Alat yang paling terkenal untuk tujuan ini mungkin adalah UnCSS, modul Node.js yang memungkinkan untuk menyingkirkan aturan CSS yang tidak digunakan dengan cepat, dan juga memberi kita opsi konfigurasi canggih yang membuatnya mudah untuk menyempurnakan proses pembersihan.
Sangat penting untuk memperhitungkan bahwa kita tidak perlu ingin menghapus aturan yang tidak digunakan semua file CSS yang kita miliki, misalnya dari global, reset, atau stylesheet pihak ke-3, jadi kita perlu kecualikan mereka saat melakukan pembersihan.
Seiring dengan aturan yang usang, aturan duplikat juga menyebabkan kembung kode berlebihan dan kehilangan kinerja. Kami dapat menghapusnya dengan menggunakan modul CSS Purge Node.js, tetapi kami juga dapat bekerja dengannya CSS linters untuk mencari aturan duplikat dalam file CSS kami.
7. Kurangi Kekhususan
Kekhususan pemilih CSS dihitung dari jumlah dan jenis selektor dalam yang dikandungnya. Kekhususan CSS dinyatakan sebagai angka 4 digit yang paling mudah dipahami jika kita melihat kalkulator spesifisitas CSS visual ini:
Spesifisitas terendah (0001) milik penyeleksi yang hanya menargetkan satu elemen HTML umum, seperti atau . Semakin banyak pemilih selektor bagian dalam, semakin tinggi spesifisitasnya.
Selektor tertentu, seperti id atau penyeleksi yang berasal dari gaya inline, memiliki prioritas lebih tinggi karena mereka menimpa gaya milik penyeleksi yang lebih umum. Misalnya kekhususan # id1 pemilih adalah 0100.
Dalam refactoring, tujuannya adalah untuk mengurangi kekhususan penyeleksi (tetap singkat) sebanyak mungkin, seperti penyeleksi dengan spesifisitas lebih tinggi secara signifikan mengurangi usabilitas pemilih, dan menyebabkan basis kode kembung.
3 jenis utama penyeleksi dengan spesifisitas tinggi adalah:
- Selektor berkualitas, seperti
p.class1(mendefinisikanhaltag tidak perlu di sini, karena itu membuat tidak mungkin untuk menggunakan kelas yang sama dengan elemen HTML lainnya) - Selektor sangat bersarang, seperti
.class1 .class2 .class3 .class4… - ID, seperti
# id1
Alat daring, seperti CSSDig yang disebutkan pada Langkah 1, dapat digunakan untuk dengan cepat menemukan penyeleksi dengan spesifisitas tinggi ini. Ini juga dapat berguna untuk membuat aturan dalam panduan gaya pengkodean tentang hal-hal seperti tingkat bersarang maksimum, atau batasan dalam menggunakan id penyeleksi.
8. Weed Out !penting Aturan
Aturan CSS diikuti oleh !penting pernyataan menimpa aturan gaya biasa. Menggunakan !penting aturan cepat atau lambat mengarah ke kode yang tidak koheren. Bukan kebetulan sebagian besar alat linting menandainya sebagai kesalahan.
Ketika kita perlu menulis CSS dengan cepat, kita mungkin mulai mengandalkan mereka karena kesederhanaannya.
Masalah utama dengan !penting deklarasi adalah bahwa jika kita ingin menimpanya di masa depan, kita perlu menempatkan lebih banyak lagi !penting deklarasi sedang digunakan, jadi yang terbaik adalah membuangnya di tempat yang memungkinkan selama proses refactoring.
9. Bersihkan Angka Ajaib dan Nilai Kode Keras
Selama alur kerja CSS kita sehari-hari, kadang-kadang kita bertemu dengan masalah yang tidak bisa kita selesaikan, dan kita mulai menggunakan apa yang disebut angka ajaib, nilai yang bekerja karena beberapa alasan tetapi kami tidak mengerti mengapa. Sebagai contoh, ambil contoh berikut:
.class1 position: absolute; atas: 28px; kiri: 15,5%;
Masalah utama dengan angka ajaib adalah angka itu tidak langsung, dan mereka mewujudkan “pemrograman dengan permutasi” antipattern. Selama proses refactoring, kita perlu menghapus aturan sewenang-wenang ini dari kode kita, dan menggantinya dengan solusi yang lebih masuk akal sedapat mungkin.
Aturan praktis yang sama berlaku untuk nilai-nilai kode keras demikian juga. Mungkin kemunculan nilai-nilai hard-code yang paling sering dapat ditemukan dalam aturan line-height:
/ * buruk, kita harus menambahkan aturan tinggi-garis tetap tambahan ke elemen turunan dari .class1 * / .class1 font-size: 20px; garis-tinggi: 24px; / * bagus, aturan ketinggian-garis yang fleksibel dapat dengan aman digunakan oleh elemen anak juga * / .class1 font-size: 20px; tinggi garis: 1.2;
Nilai-nilai hard-coded membuat kode kita lebih sedikit bukti masa depan dan lebih kaku, sehingga sebagai bagian dari refactoring kita perlu menggali mereka, dan gantikan dengan nilai yang fleksibel.
10. Unit dan Nilai Refactor
Untuk membuat pemeliharaan dan debugging lebih mudah di masa depan, dan untuk menghindari kegagalan yang dapat berasal dari menggunakan unit yang berbeda, seperti em dan px, secara bersamaan, kita perlu berpegang teguh pada aturan yang koheren tentang bagaimana kita menggunakan nilai relatif dan absolut.
Jika kita menggunakannya secara tidak konsisten di masa lalu, kita perlu mengkonversinya sehingga mereka dapat membentuk sistem yang ringkas
Jika kita menggunakan terlalu banyak warna serupa di situs kita, itu juga bisa menjadi hal yang bijaksana merasionalisasi skema warna dengan mengurangi jumlah warna yang kami gunakan. (Berikut adalah posting tentang cara memilih skema warna situs web secara praktis.)
