Memfaktorkan Ulang CSS: Pendahuluan (Bagian 1)

CSS adalah bahasa stylesheet sederhana untuk mendefinisikan presentasi situs web atau dokumen. Namun, kesederhanaan ini membuat pintu terbuka untuk banyak masalah potensial dan hutang teknis — kode yang membengkak, neraka spesifisitas, blok kode yang digandakan dengan sangat sedikit atau tidak ada perbedaan, sisa pemilih yang tidak digunakan, peretasan yang tidak perlu, dan solusi, untuk beberapa nama.

Utang teknis semacam itu, jika tidak dibayar tepat waktu, dapat menumpuk dan menyebabkan masalah parah di kemudian hari. Paling umum, ini dapat menyebabkan efek samping yang tidak terduga saat menambahkan komponen UI baru dan membuat basis kode sulit untuk dipelihara. Anda mungkin pernah mengerjakan proyek dengan basis kode CSS yang buruk sebelumnya dan berpikir bagaimana Anda menulis kode secara berbeda, diberi kesempatan untuk memperbaiki atau menulis ulang semuanya dari awal.

Memfaktorkan ulang sebagian besar kode CSS bukanlah tugas yang mudah dengan ukuran apa pun. Kadang-kadang, tampaknya itu hanya kasus "menghapus kode berkualitas buruk, menulis CSS yang lebih baik, dan menerapkan kode yang ditingkatkan mengkilap". Namun, ada banyak faktor lain yang perlu dipertimbangkan, seperti kesulitan refactoring basis kode langsung, durasi yang diharapkan dan pemanfaatan tim, menetapkan tujuan refactoring, melacak efektivitas dan kemajuan refactor, dll. Ada juga masalah meyakinkan manajemen atau pemangku kepentingan proyek untuk menginvestasikan waktu dan sumber daya ke dalam proses refactoring.

Dalam seri tiga bagian ini , kita akan melalui proses refactor CSS dari awal hingga akhir, dimulai dengan pengetahuan tentang cara mendekatinya dan beberapa pro dan kontra umum dari refactoring, kemudian beralih ke strategi refactoring itu sendiri dan berakhir dengan beberapa praktik terbaik umum tentang ukuran dan kinerja file CSS.

Efek Samping CSS Berkualitas Buruk

Untuk semua fleksibilitas dan kesederhanaannya, CSS sendiri memiliki beberapa masalah mendasar yang memungkinkan pengembang untuk menulis kode berkualitas buruk di tempat pertama. Masalah ini berasal dari spesifisitas dan mekanisme pewarisannya, beroperasi dalam lingkup global, ketergantungan urutan sumber, dll.

Pada tingkat tim, sebagian besar masalah basis kode CSS biasanya berasal dari berbagai tingkat keterampilan dan pengetahuan CSS, preferensi dan gaya kode yang berbeda, kurangnya pemahaman tentang struktur proyek dan kode serta komponen yang ada, tidak adanya tingkat proyek atau tim -standar dan pedoman tingkat, dan seterusnya.

Akibatnya, CSS berkualitas buruk dapat menyebabkan masalah yang melampaui bug visual sederhana dan dapat menghasilkan berbagai efek samping parah yang dapat memengaruhi proyek secara keseluruhan. Beberapa contoh tersebut meliputi:

• Penurunan kualitas kode karena lebih banyak fitur ditambahkan karena tingkat keterampilan CSS yang bervariasi dalam tim pengembangan dan kurangnya aturan internal, konvensi, dan praktik terbaik.
• Menambahkan fitur baru atau memperluas pemilih yang ada menyebabkan bug dan efek samping yang tidak terduga di bagian lain kode (juga dikenal sebagai regresi ).
• Beberapa pemilih CSS yang berbeda dengan blok kode duplikat atau potongan kode CSS dapat dipisahkan menjadi pemilih baru dan diperluas dengan variasi.
• Sisa, potongan kode yang tidak digunakan dari fitur yang dihapus . Tim pengembangan telah kehilangan jejak kode CSS mana yang digunakan dan mana yang dapat dihapus dengan aman.
• Inkonsistensi dalam struktur file, penamaan kelas CSS, kualitas keseluruhan CSS, dll.
• "Kekhususan neraka" di mana fitur baru ditambahkan dengan mengganti alih-alih yang ada basis kode CSS.
• Membatalkan CSS di mana pemilih dengan spesifisitas yang lebih tinggi "mengatur ulang" gaya pemilih dengan spesifisitas yang lebih rendah. Pengembang menulis lebih banyak kode untuk mengurangi gaya. Ini menghasilkan redundansi dan banyak pemborosan dalam kode.

Dalam skenario terburuk, semua masalah yang disebutkan di atas dapat menghasilkan ukuran file CSS yang besar , bahkan dengan minifikasi CSS yang diterapkan. CSS ini biasanya memblokir perenderan, sehingga browser bahkan tidak akan merender konten situs web hingga selesai mengunduh dan menguraikan file CSS, sehingga menghasilkan UX dan kinerja yang buruk pada jaringan yang lebih lambat atau tidak dapat diandalkan.

Isu-isu ini tidak hanya mempengaruhi pengguna akhir tetapi juga tim pengembangan dan pemangku kepentingan proyek dengan membuat pemeliharaan dan pengembangan fitur menjadi sulit, memakan waktu dan mahal. Ini adalah salah satu argumen yang lebih berguna untuk dikemukakan ketika berdebat untuk refactor atau penulisan ulang CSS.

Tim di Netlify mencatat bahwa alasan di balik proyek refactoring CSS skala besar mereka adalah penurunan kualitas kode dan pemeliharaan karena proyek tumbuh dalam kompleksitas dengan semakin banyak komponen UI yang ditambahkan. Mereka juga memperhatikan bahwa kurangnya standar dan dokumentasi CSS internal menyebabkan penurunan kualitas kode karena semakin banyak orang yang mengerjakan basis kode CSS.

“(…) apa yang dimulai dengan PostCSS terorganisir secara bertahap tumbuh menjadi arsitektur CSS global yang kompleks dan terjerat dengan banyak kekhususan dan penggantian. Seperti yang Anda duga, ada titik di mana utang teknologi tambahan yang ditimbulkannya menyulitkan pengiriman cepat tanpa menambahkan regresi apa pun. Selain itu, karena jumlah pengembang frontend yang berkontribusi pada basis kode juga bertambah, arsitektur CSS semacam ini menjadi semakin sulit untuk dikerjakan.”

Refactor Atau Tulis Ulang?

Refactoring memungkinkan pengembang untuk secara bertahap dan strategis meningkatkan basis kode yang ada, tanpa mengubah presentasi atau fungsionalitas intinya. Peningkatan ini biasanya dalam lingkup kecil dan terbatas, dan tidak memperkenalkan kerusakan, perubahan arsitektur yang luas atau menambahkan perilaku, fitur, atau fungsionalitas baru ke basis kode yang ada.

Misalnya, basis kode saat ini menampilkan dua variasi komponen kartu — yang pertama diterapkan di awal pengembangan proyek oleh pengembang berpengalaman dan yang kedua ditambahkan beberapa saat setelah proyek diluncurkan oleh pengembang yang kurang berpengalaman dalam tenggat waktu yang singkat, jadi ini menampilkan kode duplikat dan pemilih luas dengan spesifisitas tinggi.

Variasi kartu ketiga perlu ditambahkan, yang berbagi beberapa gaya dari dua variasi kartu lainnya. Jadi untuk menghindari bug, kode duplikat dan kelas CSS yang kompleks, dan markup HTML, tim memutuskan untuk memfaktorkan ulang CSS komponen kartu sebelum menerapkan variasi baru.

Penulisan ulang memungkinkan pengembang untuk membuat perubahan substansial pada basis kode dan mengasumsikan bahwa sebagian besar jika tidak semua kode dari basis kode saat ini akan diubah atau diganti. Penulisan ulang memungkinkan pengembang untuk membangun basis kode baru dari awal, mengatasi masalah inti dari basis kode saat ini yang tidak mungkin atau mahal untuk diperbaiki, meningkatkan tumpukan teknologi dan arsitektur, serta menetapkan aturan internal baru dan praktik terbaik untuk basis kode baru.

Misalnya, klien sedang dalam proses rebranding dan situs web perlu diperbarui dengan desain baru dan konten yang diperbarui. Karena ini adalah perubahan di seluruh situs di luar kotak, pengembang memutuskan untuk memulai dari awal, menulis ulang proyek, dan mengambil kesempatan ini untuk mengatasi masalah inti yang dimiliki basis kode CSS saat ini tetapi tidak dapat diselesaikan dengan refactor kode, perbarui tumpukan teknologi CSS , gunakan alat dan fitur terbaru, buat aturan internal baru dan praktik terbaik untuk penataan gaya, dll.

Mari kita rangkum pro dan kontra dari setiap pendekatan.

Kapan Memfaktorkan Ulang CSS?

Refactoring adalah pendekatan yang disarankan untuk meningkatkan basis kode CSS secara bertahap sambil mempertahankan tampilan dan nuansa (desain) saat ini. Anggota tim dapat bekerja untuk mengatasi masalah basis kode ini ketika tidak ada tugas dengan prioritas lebih tinggi. Dengan secara bertahap meningkatkan pengalaman pengguna basis kode saat ini tidak akan terpengaruh secara langsung dalam banyak kasus, namun basis kode yang lebih bersih dan lebih dapat dipelihara akan menghasilkan implementasi fitur yang lebih mudah dan lebih sedikit bug dan efek samping yang tidak terduga.

Pemangku kepentingan proyek mungkin akan setuju untuk menginvestasikan waktu dan sumber daya yang terbatas ke dalam refactoring, tetapi mereka akan mengharapkan tugas-tugas ini dilakukan dengan cepat dan akan mengharapkan tim tersedia untuk tugas-tugas utama.

Refactoring CSS harus dilakukan secara berkala ketika tidak ada desain yang luas atau perubahan konten yang tidak direncanakan dalam waktu dekat. Tim harus secara proaktif mencari titik lemah yang disebutkan sebelumnya dalam basis kode CSS saat ini dan berupaya mengatasinya setiap kali tidak ada tugas dengan prioritas lebih tinggi yang tersedia.

Pengembang frontend pemimpin atau pengembang yang paling berpengalaman dengan CSS harus mengangkat masalah dan membuat tugas pemfaktoran ulang untuk menegakkan standar kualitas kode CSS di basis kode.

Kapan Menulis Ulang CSS?

Menulis ulang basis kode CSS lengkap harus dilakukan ketika basis kode CSS memiliki masalah inti yang tidak dapat diatasi dengan refactoring atau ketika refactoring adalah opsi yang lebih mahal. Berbicara dari pengalaman pribadi, ketika saya sudah mulai bekerja untuk klien yang pindah dari perusahaan lain dan masalah CSS yang disebutkan di atas dan jelas bahwa itu akan menjadi pekerjaan yang sulit untuk refactor, saya akan mulai dengan merekomendasikan penulisan ulang penuh dan lihat apa klien berpikir. Dalam kebanyakan kasus, klien tersebut tidak puas dengan keadaan basis kode dan dengan senang hati melanjutkan penulisan ulang.

Alasan lain untuk penulisan ulang CSS penuh adalah ketika perubahan substansial direncanakan untuk situs web — rebranding, desain ulang, atau perubahan signifikan lainnya yang memengaruhi sebagian besar situs web. Aman untuk mengasumsikan bahwa pemangku kepentingan proyek menyadari bahwa ini adalah investasi yang signifikan dan akan memakan waktu untuk menyelesaikan penulisan ulang.

Mengaudit Kesehatan Basis Kode CSS

Ketika tim pengembangan telah menyetujui fakta bahwa kode CSS perlu difaktorkan ulang untuk merampingkan alur kerja pengembangan fitur atau menghilangkan efek samping dan bug CSS yang tidak terduga, tim perlu menyampaikan saran ini kepada pemangku kepentingan proyek atau manajer proyek.

Merupakan ide bagus untuk memberikan beberapa data keras di samping pemikiran subjektif tentang basis kode dan tinjauan kode umum. Ini juga akan memberi tim tujuan terukur yang dapat mereka sadari saat mengerjakan refactor — ukuran file target, kekhususan pemilih, kompleksitas kode CSS, jumlah kueri media…

Saat melakukan audit CSS atau mempersiapkan refactor CSS, saya mengandalkan beberapa dari banyak alat yang berguna untuk mendapatkan gambaran umum dan statistik yang berguna tentang basis kode CSS.

Alat masuk pribadi saya adalah Statistik CSS, alat gratis yang memberikan gambaran umum yang berguna tentang kualitas basis kode CSS dengan banyak metrik berguna yang dapat membantu pengembang menangkap beberapa masalah yang sulit dikenali.

Kembali pada tahun 2016, trivago telah melakukan refactor skala besar untuk basis kode CSS mereka dan menggunakan metrik dari CSS Stats untuk menetapkan beberapa tujuan konkret dan terukur seperti mengurangi spesifisitas dan mengurangi jumlah variasi warna. Hanya dalam tiga minggu, mereka telah berhasil meningkatkan kesehatan keseluruhan basis kode CSS, mengurangi ukuran file CSS, meningkatkan kinerja render di seluler, dll.

“Alat seperti CSS Stats dapat dengan mudah membantu Anda mengetahui masalah konsistensi dalam basis kode Anda. Menunjukkan apa yang bisa terjadi ketika setiap orang memiliki pendapat berbeda tentang bagaimana seharusnya warna abu-abu terlihat, Anda akan mendapatkan 50 warna abu-abu. Selain itu, Grafik Kekhususan memberi Anda indikasi keseluruhan yang baik tentang kesehatan basis CSS Anda.”

Adapun alat CLI, Wallace adalah alat praktis yang menyediakan statistik dan ikhtisar CSS yang agak mendasar, tetapi berguna yang dapat digunakan untuk mengidentifikasi masalah yang terkait dengan ukuran file, jumlah aturan dan pemilih, jenis dan kompleksitas pemilih, dll.

Wallace juga menawarkan alat penganalisis gratis di Situs Web Project Wallace yang menggunakan versi Wallace yang tampaknya lebih canggih di bagian belakang untuk memberikan beberapa visualisasi data yang berguna dan beberapa metrik lagi yang tidak tersedia di CLI Wallace.

Project Wallace juga menawarkan solusi berbayar lengkap untuk analisis basis kode CSS . Ini menampilkan fitur dan metrik yang lebih berguna yang dapat membantu pengembang menangkap beberapa masalah yang sulit dikenali dan melacak perubahan statistik CSS berdasarkan komitmen. Meskipun paket berbayar mencakup lebih banyak fitur, paket gratis, dan alat penganalisa CSS dasar lebih dari cukup untuk mengaudit kualitas basis kode CSS dan mendapatkan gambaran umum untuk membuat rencana refactoring.

Menulis CSS Berkualitas Tinggi

Kami telah melihat bagaimana kesederhanaan dan fleksibilitas basis kode CSS dapat menyebabkan banyak masalah dengan kualitas kode, kinerja, dan bug visual. Tidak ada alat otomatis peluru perak yang akan memastikan bahwa kita menulis CSS dengan cara terbaik dan menghindari semua kemungkinan jebakan arsitektur di sepanjang jalan.

Alat terbaik yang akan memastikan bahwa kita menulis kode CSS berkualitas tinggi adalah disiplin, perhatian terhadap detail, serta pengetahuan dan keterampilan umum CSS . Pengembang harus terus-menerus menyadari gambaran yang lebih besar dan memahami peran apa yang dimainkan CSS mereka dalam gambaran yang lebih besar itu.

Misalnya, dengan menentukan pemilih secara berlebihan, satu pengembang dapat sangat membatasi kegunaan, yang menyebabkan pengembang lain harus menduplikasi kode untuk menggunakannya untuk komponen lain yang serupa dengan markup yang berbeda. Masalah ini sering terjadi ketika pengembang kurang memahami dan tidak memanfaatkan mekanisme yang mendasari di balik CSS (kaskade, pewarisan, kinerja browser, dan kekhususan pemilih). Keputusan awal ini dapat menyebabkan dampak besar di masa depan , sehingga kesehatan dan kemampuan pemeliharaan basis kode CSS bergantung pada pengetahuan, keterampilan, dan pemahaman pengembang tentang dasar-dasar CSS.

Alat otomatis tidak mengetahui gambaran yang lebih besar atau bagaimana pemilih digunakan, sehingga mereka tidak dapat membuat keputusan arsitektur penting ini, selain menerapkan beberapa aturan dasar, dapat diprediksi, dan kaku.

Berbicara dari pengalaman pribadi, saya telah menemukan yang berikut ini membantu saya untuk secara signifikan meningkatkan cara saya bekerja dengan CSS:

• Mempelajari pola arsitektur.
  Pedoman CSS memberikan basis pengetahuan yang hebat dan praktik terbaik untuk menulis CSS berkualitas tinggi berdasarkan pola pemrograman umum dan prinsip arsitektur.
• Berlatih dan tingkatkan.
  Kerjakan proyek pribadi atau atasi tantangan dari Frontend Mentor untuk meningkatkan keterampilan Anda. Mulailah dengan proyek sederhana (satu komponen atau satu bagian) dan fokuslah pada penulisan CSS terbaik yang Anda bisa, coba berbagai pendekatan, terapkan berbagai pola arsitektur, tingkatkan kode secara bertahap, dan pelajari cara menulis CSS berkualitas tinggi secara efisien.
• Belajar dari kesalahan.
  Percayalah, Anda akan menulis beberapa CSS berkualitas buruk saat memulai. Ini akan membawa Anda beberapa mencoba untuk melakukannya dengan benar. Luangkan waktu sejenak dan pikirkan apa yang salah, analisis titik-titik lemah, pikirkan apa yang bisa Anda lakukan secara berbeda dan bagaimana caranya, dan cobalah untuk menghindari kesalahan yang sama di masa depan.

Penting juga untuk menetapkan aturan dan standar CSS internal dalam tim atau bahkan untuk seluruh perusahaan. Standar perusahaan, gaya kode, dan prinsip yang didefinisikan dengan jelas dapat menghasilkan banyak manfaat seperti:

• Gaya dan kualitas kode yang terpadu dan konsisten
• Lebih mudah dipahami, basis kode yang kuat
• Orientasi proyek yang disederhanakan
• Tinjauan kode standar yang dapat dilakukan oleh anggota tim mana pun, bukan hanya pengembang frontend utama atau pengembang yang lebih berpengalaman

Kirby Yardley telah mengerjakan refactoring sistem desain dan CSS Sundance Institute dan telah menunjukkan pentingnya menetapkan aturan internal dan praktik terbaik.

“Tanpa aturan dan strategi yang tepat, CSS adalah bahasa yang bisa disalahgunakan. Seringkali pengembang akan menulis gaya khusus untuk satu komponen tanpa berpikir kritis tentang bagaimana kode itu dapat digunakan kembali di elemen lain (...) Setelah banyak penelitian dan pertimbangan tentang bagaimana kami ingin mendekati arsitektur CSS kami, kami memutuskan untuk menggunakan metodologi yang disebut ITCSS. “

Kembali ke contoh sebelumnya dari tim di trivago, menetapkan aturan dan pedoman internal terbukti menjadi langkah penting untuk proses refactoring mereka.

“Kami memperkenalkan pustaka pola, mulai menggunakan desain atom dalam alur kerja kami, membuat pedoman pengkodean baru, dan mengadaptasi beberapa metodologi seperti BEM dan ITCSS untuk mendukung kami dalam memelihara dan mengembangkan CSS/UI kami dalam skala besar.”

Tidak semua aturan dan standar perlu diperiksa dan ditegakkan secara manual. Alat linting CSS seperti Stylelint menyediakan beberapa aturan berguna yang akan membantu Anda memeriksa kesalahan dan menegakkan standar internal dan praktik terbaik CSS umum seperti melarang blok kode CSS kosong dan komentar, melarang pemilih duplikat, membatasi unit, menyetel spesifisitas maksimum pemilih dan kedalaman bersarang, menetapkan pola nama pemilih, dll.

Kesimpulan

Sebelum memutuskan untuk mengusulkan refactor basis kode granular atau penulisan ulang CSS lengkap, kita perlu memahami masalah dengan basis kode saat ini sehingga kita dapat menghindarinya di masa mendatang dan memiliki data terukur untuk proses tersebut. Basis kode CSS mungkin berisi banyak pemilih spesifisitas tinggi yang kompleks yang menyebabkan efek samping dan bug yang tidak terduga saat menambahkan fitur baru, mungkin basis kode mengalami banyak potongan kode berulang yang dapat dipindahkan ke kelas utilitas terpisah, atau mungkin campuran dari berbagai pertanyaan media menyebabkan beberapa konflik tak terduga.

Alat yang berguna seperti CSS Stats dan Wallace dapat memberikan gambaran umum tingkat tinggi tentang basis kode CSS dan memberikan wawasan mendetail tentang status dan kesehatan basis kode. Alat-alat ini juga menyediakan statistik terukur yang dapat digunakan untuk menetapkan tujuan untuk proses refactoring dan melacak kemajuan refactoring.

Setelah menentukan tujuan dan cakupan refactoring, penting untuk menetapkan pedoman internal dan praktik terbaik untuk basis kode CSS — konvensi penamaan, prinsip arsitektur, struktur file, dan folder, dll. Ini memastikan konsistensi kode, menetapkan fondasi inti dalam proyek yang dapat didokumentasikan dan yang dapat digunakan untuk orientasi dan tinjauan kode CSS. Menggunakan alat linting seperti Stylelint dapat membantu menerapkan beberapa praktik terbaik CSS umum untuk mengotomatiskan sebagian proses peninjauan kode.

Dalam artikel berikutnya dari seri tiga bagian ini, kita akan menyelami strategi pemfaktoran ulang CSS antipeluru yang memastikan transisi mulus antara basis kode saat ini dan basis kode refactored.

Referensi

• “Mengelola Proyek CSS Dengan ITCSS,” Harry Roberts
• “Pemfaktoran Ulang CSS Skala Besar Di Trivago,” Christoph Reinartz
• “Sistem Desain Sundance.org Dan Refactor CSS,” Kirby Yardley
• “Dari CSS Semantik ke Tailwind: Memfaktorkan Ulang Basis Kode UI Netlify,” Charlie Gerard & Leslie Cohn-Wein
• “Alat Audit CSS,” Iris Lješjanin