Cara Refactor CSS - Panduan

CSS refactoring perlu menjadi sebahagian penting dari alur kerja pembangunan front-end, jika kita mahu mempunyai asas kod yang boleh diurus dan dioptimumkan. Apabila kita refactor CSS, kita membersihkan dan menyusun semula kod kami yang sedia ada tanpa menambah sebarang ciri baru atau membetulkan pepijat.

Membantu refactoring mengelakkan letupan CSS, meningkatkan pembacaan kod dan kebolehbasaian semula, dan menjadikan CSS sleeker dan lebih cepat untuk dilaksanakan.

Refactoring biasanya diperlukan selepas beberapa ketika, kerana walaupun projek-projek yang bermula dengan asas kod ringkas dan teratur cepat atau lambat mula kehilangan kejelasan mereka; konsisten, peraturan usang dan bahagian kod duplikat muncul; dan kami juga mula menimpa gaya dan menggunakan lebih banyak lagi hacks dan penyelesaian.

Cara terbaik untuk mengekalkan asas kod CSS kami boleh dipelihara adalah berpegang kepada “refaktor awal, refactor sering” peraturan ibu jari. Dalam catatan ini, kami akan melihat beberapa petua tentang bagaimana kami boleh menjalankan proses refactoring CSS yang berkesan.

1. Melaksanakan Audit Awal

Untuk mempunyai gambaran yang lebih baik tentang apa yang kita perlukan untuk refactor, itu adalah yang terbaik untuk mulakan dengan audit menyeluruh untuk melihat apa yang kita ada sekarang.

Terdapat banyak alat dalam talian yang boleh membantu kami dalam usaha ini. CSSDig adalah pelanjutan Chrome berkuasa yang menganalisis CSS laman web, dan meneroka kelemahannya, seperti pemilih yang terlalu spesifik atau sifat berulang-ulang.

CSS yang tidak digunakan menyiasat peraturan CSS yang tidak digunakan, sementara alat linting, seperti CSS Lint, menjadikannya mudah untuk mencari kerumitan, kelayakan dan masalah lain dengan cepat..

Ia juga penting untuk meneliti kod secara manual semasa audit awal, kerana banyak masalah pada tahap seni bina hanya boleh ditangkap dengan cara ini.

2. Sediakan Rancangan Boleh Diurus

Kod kerja refactoring sentiasa menjadi tugas yang menakutkan, tetapi kita dapat meringankan rasa sakit jika kita membuat rancangan tentang apa yang perlu kita lakukan, memotong proses refactoring kepada bahagian-bahagian yang boleh diurus, dan membuat jadual yang sesuai.

Dalam refactoring CSS ada perkara penting yang selalu kita pertimbangkan: beberapa perkara yang kita refactor, mis. menukar nama pemilih, akan menjadikannya perlu menyesuaikan kod HTML dan fail JavaScript yang berkaitan juga.

Oleh itu, ia adalah idea yang baik surih ke hadapan pengubahsuaian tambahan ini yang perlu kita lakukan, dan membina mereka ke dalam jadual refactoring kami bersama-sama dengan tugas-tugas yang berkaitan dengan CSS.

3. Track Kemajuan

Sebelum memulakan refactoring, ini merupakan langkah penting untuk sandarkan fail awal kami. Memperkenalkan sistem kawalan versi, seperti Git atau Subversion, ke dalam alur kerja kami juga boleh meningkatkan proses refactoring dengan ketara, kerana kami akan mempunyai pendaftaran mengenai langkah-langkah berikutan yang kami ambil, dan kami akan dapat kembali ke peringkat terdahulu jika kita ingin mengubah sesuatu.

4. Terus ke Panduan Gaya Coding

Panduan gaya pengkodan yang komprehensif boleh meningkatkan kebolehbacaan dan kebolehmodalan kod, oleh itu sebelum kita mula refactor itu penting untuk sediakan panduan gaya pengkod CSS.

Perkara-perkara penting untuk diputuskan adalah:

penamaan konvensyen
peraturan pemformatan
perintah pengisytiharan
unit dan nilai yang ingin kita gunakan
mengomentari peraturan

Jika kita tidak mahu mencipta panduan gaya pengekodan kita sendiri, kita juga boleh menggunakan orang lain, seperti ThinkUp yang boleh didapati di Github.

Ia tidak mencukupi walaupun hanya memperkenalkan panduan gaya pengekodan, kita juga perlu melekatinya apabila kita menulis semula kod itu semasa refactoring, dan mengharapkan yang sama dari orang lain yang bekerja pada projek kami.

5. Menetapkan Struktur Fail Koheren

Setelah kami siap dengan persiapan, perkara pertama yang perlu kita lakukan adalah untuk membuat struktur fail CSS yang tepat yang memberi perhatian kepada sifat CSS yang bersifat cascading.

Ia bergantung kepada projek bagaimana cara terbaik mengatur fail kita, tetapi terdapat beberapa peraturan sejagat, seperti menggunakan yang berasingan normalize.css fail untuk gaya semula CSS, berasingan global.css untuk gaya global yang digunakan di seluruh projek, dan menyimpan perpustakaan pihak ketiga ke dalam folder yang berasingan.

Jika kita mahu bermain selamat dengan struktur fail CSS kita, terdapat juga seni bina siap, seperti SMACSS atau ITCSS, yang menawarkan teknik yang berkesan tentang bagaimana untuk menyusun fail CSS dengan cara yang berskala.

6. Menghapus Peraturan Tidak Digunakan dan Duplikat

Selepas beberapa ketika, fail CSS biasanya mula berlimpah dalam peraturan yang tidak digunakan yang kita perlu mengenalpasti dan membersihkan semasa refactoring. Terdapat banyak alat dalam talian yang membolehkan kami menyiasat peraturan usang ini, dan kadang-kadang juga membolehkan kita untuk cepat merendam mereka.

Alat yang paling terkenal untuk tujuan ini mungkin UnCSS, modul Node.js yang memungkinkan untuk menyingkirkan peraturan CSS yang tidak digunakan dengan cepat, dan ia juga menyediakan kami dengan pilihan konfigurasi yang canggih yang menjadikannya mudah untuk menyempurnakan proses pembersihan.

Adalah penting untuk mengambil kira bahawa kita tidak semestinya mahu mengeluarkan peraturan yang tidak digunakan dari semua fail CSS yang kami ada, contohnya dari gaya global, set semula, atau stylesheets pihak ke-3, jadi kami perlu tidak termasuk mereka semasa melakukan pembersihan.

Bersama dengan peraturan usang, peraturan pendua juga menyebabkan kembung kod berlebihan dan kehilangan prestasi. Kita boleh membuangnya dengan menggunakan modul CSS Purge Node.js, tetapi kita juga boleh bekerjasama Pelapik CSS untuk mencari peraturan duplikat dalam fail CSS kami.

7. Mengurangkan Spesifik

Kekhususan pemilih CSS dikira dari bilangan dan jenis pemilih dalaman yang terkandung di dalamnya. Kekhususan CSS diungkapkan sebagai nombor 4 angka yang paling mudah difahami jika kita periksa kalkulator specifity CSS visual ini:

Kekhususan terendah (0001) adalah pemilih yang hanya mensasarkan satu elemen HTML umum, seperti

atau

. Pemilih dalaman lebih banyak pemilih gabungan mengandungi, semakin tinggi kekhususannya.

Pemilih tertentu, seperti ID atau pemilih yang datang dari gaya inline, mempunyai keutamaan yang lebih tinggi kerana mereka mengatasi gaya kepunyaan pemilih yang lebih generik. Contohnya kekhususan # id1 pemilih adalah 0100.

Dalam refactoring, matlamatnya adalah untuk mengurangkan kekhususan pemilih (menjaga mereka pendek) seberapa banyak yang mungkin, sebagai pemilih dengan kekhususan yang lebih tinggi dapat mengurangkan kebolehterilan pemilih, dan membawa kepada asas kod padu.

3 jenis utama pemilihan khusus adalah:

Pemilih berkelayakan, seperti p.class1 (mentakrifkan p tag tidak perlu di sini, kerana ia menjadikannya mustahil untuk menggunakan kelas yang sama dengan elemen HTML lain)
Pemilih yang sangat bersarang, seperti .class1 .class2 .class3 .class4 ...
ID, seperti # id1

Alat dalam talian, seperti CSSDig yang disebutkan dalam Langkah 1, boleh digunakan untuk mencari pencetus spesifik yang tinggi ini dengan cepat. Ia juga berguna untuk membuat peraturan dalam panduan gaya pengekodan tentang perkara-perkara seperti tahap maksimum bersarang, atau had penggunaan ID pemilih.

8. Rumpai Keluar `!penting` Peraturan

Peraturan CSS diikuti oleh !penting pernyataan mengatasi peraturan gaya biasa. Menggunakan !penting peraturan yang lambat laun membawa kepada kod tidak sepadan. Ia bukan satu kebetulan alat yang paling linting menandakan mereka sebagai kesilapan.

Apabila kita perlu menulis CSS dengan cepat, kita boleh mula bergantung kepada mereka walaupun kerana kesederhanaan mereka.

Masalah utama dengan !penting pengisytiharan ialah jika kita mahu mengatasi mereka pada masa akan datang, kita perlu meletakkan lebih banyak lagi !penting pengisytiharan yang digunakan, jadi lebih baik untuk menghilangkannya di mana sahaja mungkin semasa proses refactoring.

9. Bersihkan Nombor Magic dan Nilai Berkod keras

Semasa alur kerja CSS setiap hari, kadang-kadang kita bertemu dengan isu-isu yang tidak dapat kita selesaikan, dan kita mula menggunakan apa yang dipanggil nombor sihir, nilai-nilai yang bekerja untuk beberapa sebab tetapi kita tidak faham mengapa. Misalnya mengambil contoh berikut:

 .class1 position: absolute; atas: 28px; kiri: 15.5%;

Masalah utama dengan nombor sihir ialah mereka keadaannya, dan mereka merangkumi “pengaturcaraan dengan permutasi” antipattern. Semasa proses refactoring, kita perlu mengeluarkan peraturan sewenang-wenang dari kod kami, dan menggantikannya dengan penyelesaian yang lebih munasabah di mana sahaja ia mungkin.

Peraturan praktikal yang sama berlaku untuk nilai berkod keras juga. Mungkin terjadinya nilai-nilai berkod keras yang paling kerap dapat dijumpai dalam peraturan ketinggian garis:

 / * buruk, kita perlu menambah peraturan baris ketinggian tetap kepada elemen kanak-kanak. class1 * / .class1 font-size: 20px; garis ketinggian: 24px;  / * baik, peraturan ketinggian garis fleksibel boleh digunakan dengan selamat oleh elemen kanak-kanak juga * / .class1 font-size: 20px; ketinggian talian: 1.2;

Nilai-nilai yang berkod keras menjadikan kod kami kurang masa depan dan lebih tegar, jadi sebagai sebahagian daripada refactoring kita perlu menggali mereka, dan menggantikannya dengan nilai fleksibel.

10. Unit dan Nilai Pemfaktoran

Untuk membuat penyelenggaraan dan debugging lebih mudah pada masa akan datang, dan untuk mengelakkan kegagalan yang boleh timbul daripada menggunakan unit yang berbeza, seperti em dan px, serentak, kita perlu melekat pada peraturan yang koheren mengenai bagaimana kita menggunakan nilai relatif dan mutlak.

Sekiranya kita menggunakannya secara tidak konsisten pada masa lalu, kita perlu menukarnya supaya ia dapat membentuk sistem ringkas

Jika kami menggunakan terlalu banyak warna yang sama di laman web kami, ia juga boleh menjadi perkara yang bijak merasionalkan skema warna dengan mengurangkan bilangan warna yang kami gunakan. (Ini ialah siaran mengenai cara memilih skema warna laman web secara praktikal.)