CSS'yi Yeniden Düzenleme: Giriş (Bölüm 1)

CSS, bir web sitesi veya belgenin sunumunu tanımlamak için basit bir stil sayfası dilidir. Bununla birlikte, bu basitlik, birçok potansiyel sorun ve teknik borç için kapıyı açık bırakır - şişirilmiş kod, özgüllük cehennemi, çok az veya hiç fark olmayan çoğaltılmış kod blokları, arta kalan kullanılmayan seçiciler, gereksiz saldırılar ve geçici çözümler, bunlardan birkaçı.

Bu tür teknik borçlar, zamanında ödenmezse birikebilir ve ileride ciddi sorunlara yol açabilir. En yaygın olarak, yeni UI bileşenleri eklerken ve kod tabanının bakımını zorlaştırırken beklenmeyen yan etkilere yol açabilir. Muhtemelen daha önce zayıf bir CSS kod tabanına sahip bir proje üzerinde çalıştınız ve her şeyi sıfırdan yeniden düzenleme veya yeniden yazma fırsatı verildiğinde kodu nasıl farklı yazdığınızı düşündünüz.

CSS kodunun büyük kısımlarını yeniden düzenlemek, hiçbir şekilde kolay bir iş değildir. Bazen, bunun yalnızca “düşük kaliteli kodu silmek, daha iyi CSS yazmak ve parlak, geliştirilmiş kodu dağıtmak” durumu olduğu görünebilir. Ancak, canlı bir kod tabanını yeniden düzenlemenin zorluğu, beklenen süre ve ekip kullanımı, yeniden düzenleme hedefleri oluşturma, yeniden düzenleme etkinliğinin ve ilerlemenin izlenmesi vb. gibi dikkate alınması gereken başka birçok faktör vardır. Ayrıca yönetimi veya proje paydaşlarını buna ikna etme meselesi de vardır. zaman ve kaynakları yeniden düzenleme sürecine yatırın.

Bu üç bölümlük dizide , CSS yeniden düzenleme sürecini baştan sona inceleyeceğiz, ona nasıl yaklaşılacağı ve yeniden düzenlemenin bazı genel artıları ve eksileri hakkında bilgiyle başlayıp, ardından yeniden düzenleme stratejilerine geçerek ve sona ereceğiz. CSS dosya boyutu ve performansıyla ilgili bazı genel en iyi uygulamalarla.

Düşük Kaliteli CSS'nin Yan Etkileri

Tüm esnekliği ve basitliğine rağmen, CSS'nin kendisinin, geliştiricilerin ilk etapta düşük kaliteli kod yazmasına izin veren bazı temel sorunları vardır. Bu sorunlar, küresel kapsamda faaliyet gösteren özgünlük ve kalıtım mekanizmalarından, kaynak sırasına bağımlılıktan vb. kaynaklanmaktadır.

Ekip düzeyinde, CSS kod tabanı sorunlarının çoğu genellikle değişen beceri düzeylerinden ve CSS bilgisinden, farklı tercihlerden ve kod stillerinden, proje yapısının ve mevcut kod ve bileşenlerin anlaşılmamasından, proje düzeyinin veya ekibin olmamasından kaynaklanır. -seviye standartlar ve yönergeler, vb.

Sonuç olarak, düşük kaliteli CSS, basit görsel hataların ötesine geçen sorunlara neden olabilir ve projeyi bir bütün olarak etkileyebilecek çeşitli ciddi yan etkiler üretebilir. Bu tür bazı örnekler şunları içerir:

• Geliştirme ekibindeki değişen CSS beceri düzeyleri ve dahili kurallar, sözleşmeler ve en iyi uygulamalardan yoksun olması nedeniyle daha fazla özellik eklendikçe kod kalitesi düşüyor .
• Yeni özellikler eklemek veya mevcut seçicileri genişletmek, kodun diğer bölümlerinde hatalara ve beklenmeyen yan etkilere neden olur ( gerileme olarak da bilinir).
• Çoğaltılan kod blokları veya CSS kodu parçalarına sahip birden çok farklı CSS seçicisi, yeni bir seçiciye ayrılabilir ve varyasyonla genişletilebilir.
• Silinen özelliklerden arta kalan, kullanılmayan kod parçaları . Geliştirme ekibi, hangi CSS kodunun kullanıldığını ve hangilerinin güvenli bir şekilde kaldırılabileceğini kaybetti.
• Dosya yapısındaki tutarsızlık , CSS sınıfı adlandırma, genel CSS kalitesi vb.
• Mevcut CSS kod tabanı yerine geçersiz kılarak yeni özelliklerin eklendiği “özgüllük cehennemi”.
• Yüksek özgüllük seçicilerin düşük özgüllük seçici stilini "sıfırladığı" CSS'yi geri alma. Geliştiriciler daha az stile sahip olmak için daha fazla kod yazıyor. Bu, fazlalık ve kodda çok fazla atık ile sonuçlanır.

En kötü senaryolarda, yukarıda bahsedilen tüm sorunlar bir araya geldiğinde, CSS küçültme uygulanmış olsa bile büyük bir CSS dosya boyutuna neden olabilir. Bu CSS genellikle oluşturmayı engeller, bu nedenle tarayıcı, CSS dosyasını indirmeyi ve ayrıştırmayı bitirene kadar web sitesi içeriğini oluşturmaz, bu da zayıf bir UX ve daha yavaş veya güvenilmez ağlarda performans ile sonuçlanır.

Bu sorunlar, bakım ve özellik geliştirmeyi zor, zaman alıcı ve maliyetli hale getirerek yalnızca son kullanıcıyı değil aynı zamanda geliştirme ekibini ve proje paydaşlarını da etkiler. Bu, CSS yeniden düzenleme veya yeniden yazma için tartışırken ortaya çıkacak en faydalı argümanlardan biridir.

Netlify ekibi, büyük ölçekli CSS yeniden düzenleme projelerinin ardındaki nedenin, proje giderek daha fazla UI bileşeni eklenmesiyle karmaşıklaştıkça azalan kod kalitesi ve sürdürülebilirlik olduğunu belirtti. Ayrıca, gitgide daha fazla insan CSS kod tabanı üzerinde çalışırken, dahili CSS standartlarının ve belgelerinin eksikliğinin kod kalitesinin düşmesine yol açtığını da fark ettiler.

“(…) Organize PostCSS ile başlayan şey, yavaş yavaş büyüyerek pek çok özgünlük ve geçersiz kılma ile karmaşık ve karmaşık bir küresel CSS mimarisi haline geldi. Tahmin edebileceğiniz gibi, getirdiği ek teknoloji borcunun, herhangi bir gerileme eklemeden nakliyeyi hızlı tutmayı zorlaştırdığı bir nokta var. Ayrıca, kod tabanına katkıda bulunan ön uç geliştiricilerin sayısı da arttıkça, bu tür CSS mimarisiyle çalışmak daha da zorlaşıyor.”

Yeniden Düzenleme mi Yeniden Yazma mı?

Yeniden düzenleme, geliştiricilerin sunumunu veya temel işlevselliğini değiştirmeden mevcut kod tabanını kademeli ve stratejik olarak iyileştirmelerine olanak tanır. Bu iyileştirmeler genellikle kapsam olarak küçük ve sınırlıdır ve yeni, geniş kapsamlı mimari değişiklikler getirmez veya mevcut kod tabanına yeni davranış, özellikler veya işlevler eklemez.

Örneğin, mevcut kod tabanı, bir kart bileşeninin iki varyasyonunu içerir - ilki, deneyimli bir geliştirici tarafından proje geliştirmenin başlarında uygulandı ve ikincisi, proje daha az deneyimli bir geliştirici tarafından kısa bir süre içinde başlatıldıktan bir süre sonra eklendi, bu nedenle yinelenen koda ve yüksek özgüllüğe sahip geniş kapsamlı seçicilere sahiptir.

Diğer iki kart varyasyonundan bazı stilleri paylaşan üçüncü bir kart varyasyonunun eklenmesi gerekiyor. Bu nedenle, hatalardan, yinelenen kodlardan ve karmaşık CSS sınıflarından ve hatta HTML işaretlemesinden kaçınmak için ekip, yeni bir varyasyon uygulamadan önce kart bileşeni CSS'yi yeniden düzenlemeye karar verir.

Yeniden yazma , geliştiricilerin kod tabanında önemli değişiklikler yapmasına izin verir ve mevcut kod tabanındaki tüm kodların olmasa da çoğunun değiştirileceğini veya değiştirileceğini varsayar. Yeniden Yazma, geliştiricilerin sıfırdan yeni kod tabanı oluşturmasına, mevcut kod tabanından düzeltilmesi imkansız veya pahalı olan temel sorunları çözmesine, teknoloji yığınını ve mimarisini geliştirmesine ve yeni kod tabanı için yeni dahili kurallar ve en iyi uygulamalar oluşturmasına olanak tanır.

Örneğin, müşteri yeniden markalaşma sürecindedir ve web sitesinin yeni bir tasarım ve yenilenmiş içerikle güncellenmesi gerekmektedir. Bu kutudan çıkar çıkmaz site çapında bir değişiklik olduğundan, geliştiriciler sıfırdan başlamaya, projeyi yeniden yazmaya ve bu fırsatı mevcut CSS kod tabanının sahip olduğu ancak kod refactor ile çözülemeyen temel sorunları ele almak için kullanmaya karar verir, CSS teknoloji yığınını güncelleyin , en yeni araçları ve özellikleri kullanın, stil için yeni dahili kurallar ve en iyi uygulamalar oluşturun, vb.

Her yaklaşımın artılarını ve eksilerini özetleyelim.

CSS'yi Ne Zaman Yeniden Düzenlemeli?

Yeniden düzenleme, mevcut görünümü ve hissi (tasarımı) korurken CSS kod tabanını aşamalı olarak geliştirmek için önerilen bir yaklaşımdır. Ekip üyeleri, daha yüksek öncelikli görevler olmadığında bu kod tabanı sorunlarını çözmek için çalışabilirler. Mevcut kod tabanı kullanıcı deneyiminin aşamalı olarak iyileştirilmesi çoğu durumda doğrudan etkilenmeyecektir, ancak daha temiz ve daha sürdürülebilir bir kod tabanı, daha kolay özellik uygulaması ve daha az beklenmeyen hata ve yan etki ile sonuçlanacaktır.

Proje paydaşları muhtemelen yeniden düzenlemeye sınırlı zaman ve kaynak ayırmayı kabul edecekler, ancak bu görevlerin hızlı bir şekilde yapılmasını ve ekibin birincil görevler için hazır olmasını bekleyecekler.

Yakın gelecekte geniş kapsamlı bir tasarım veya içerik değişikliği planlanmadığında, CSS'yi yeniden düzenleme, düzenli aralıklarla yapılmalıdır. Ekipler, mevcut CSS kod tabanında önceden bahsedilen zayıf noktaları proaktif olarak araştırmalı ve daha yüksek öncelikli görevler olmadığında bunları ele almaya çalışmalıdır.

Ön uç geliştirici veya CSS konusunda en fazla deneyime sahip geliştirici, kod tabanında CSS kod kalite standartlarını uygulamak için sorunları dile getirmeli ve yeniden düzenleme görevleri oluşturmalıdır.

CSS Ne Zaman Yeniden Yazılır?

Tüm CSS kod tabanının yeniden yazılması, CSS kod tabanının yeniden düzenleme ile çözülemeyen temel sorunları olduğunda veya yeniden düzenlemenin daha pahalı bir seçenek olduğu durumlarda yapılmalıdır. Kişisel deneyimimden bahsetmişken, başka bir şirketten taşınan müşteriler ve yukarıda bahsedilen CSS sorunları için çalışmaya başladığımda ve yeniden düzenlemenin zor bir iş olacağı açıktı, tam bir yeniden yazma önererek başlardım ve ne olduğunu görün. müşteri düşünür. Çoğu durumda, bu istemciler kod tabanının durumundan memnun değillerdi ve yeniden yazmaya devam etmekten mutlu oldular.

Tam CSS yeniden yazmanın bir başka nedeni, web sitesi için önemli bir değişikliğin planlanmasıdır - yeniden markalama, yeniden tasarım veya web sitesinin çoğunu etkileyen diğer önemli değişiklikler. Proje paydaşlarının bunun önemli bir yatırım olduğunun ve yeniden yazmanın tamamlanmasının biraz zaman alacağının farkında olduğunu varsaymak güvenlidir.

CSS Kod Tabanı Sağlığını Denetleme

Geliştirme ekibi, özellik geliştirme iş akışını kolaylaştırmak veya beklenmedik CSS yan etkilerini ve hatalarını ortadan kaldırmak için CSS kodunun yeniden düzenlenmesi gerektiği konusunda anlaştığında, ekibin bu öneriyi proje paydaşlarına veya bir proje yöneticisine iletmesi gerekir.

Kod tabanı ve genel kod incelemesi hakkındaki öznel düşüncelerin yanı sıra bazı somut veriler sağlamak iyi bir fikirdir. Bu aynı zamanda ekibe, yeniden düzenleme üzerinde çalışırken farkında olabilecekleri ölçülebilir bir hedef de verecektir – hedef dosya boyutu, seçici özgünlüğü, CSS kodunun karmaşıklığı, medya sorgularının sayısı…

Bir CSS denetimi yaparken veya bir CSS yeniden düzenleme işlemine hazırlanırken, CSS kod tabanı hakkında genel bir genel bakış ve faydalı istatistikler elde etmek için birçok faydalı araçtan yararlanırım.

Benim kişisel aracım CSS Stats, CSS kod tabanı kalitesine faydalı bir genel bakış sağlayan ve geliştiricilerin tespit edilmesi zor olan bazı sorunları yakalamasına yardımcı olabilecek birçok faydalı ölçüm sağlayan ücretsiz bir araçtır.

2016'da trivago, CSS kod tabanları için büyük ölçekli bir yeniden düzenleme yaptı ve belirliliği azaltmak ve renk varyasyonlarının sayısını azaltmak gibi bazı somut, ölçülebilir hedefler belirlemek için CSS İstatistiklerinden alınan metrikleri kullandı. Yalnızca üç hafta içinde, CSS kod tabanının genel sağlığını iyileştirmeyi, CSS dosya boyutunu küçültmeyi, mobilde oluşturma performansını iyileştirmeyi vb. başardılar.

“CSS İstatistikleri gibi bir araç, kod tabanınızdaki tutarlılık sorunlarını kolayca çözmenize yardımcı olabilir. Gri tonunun nasıl görünmesi gerektiği konusunda herkesin farklı fikirleri olduğunda neler olabileceğini göstererek, 50 ton gri elde edeceksiniz. Ayrıca, Özgüllük Grafiği size CSS tabanınızın sağlığına dair iyi bir genel gösterge sağlar.”

CLI araçlarına gelince, Wallace, dosya boyutu, kural ve seçici sayısı, seçici türleri ve karmaşıklığı vb. ile ilgili sorunları belirlemek için kullanılabilecek, biraz temel ancak kullanışlı CSS istatistikleri ve genel bakış sağlayan kullanışlı bir araçtır.

Wallace ayrıca, Wallace CLI'de mevcut olmayan bazı yararlı veri görselleştirmeleri ve birkaç ölçüm daha sağlamak için arka uçta Wallace'ın görünüşte daha gelişmiş bir sürümünü kullanan Project Wallace Web Sitesinde ücretsiz bir analiz aracı sunar.

Project Wallace ayrıca CSS kod tabanı analitiği için eksiksiz bir ücretli çözüm sunar. Geliştiricilerin fark edilmesi zor bazı sorunları yakalamasına ve CSS istatistik değişikliklerini taahhüt bazında takip etmesine yardımcı olabilecek daha da kullanışlı özellikler ve ölçümler içerir. Ücretli plan daha fazla özellik içerse de, ücretsiz plan ve temel CSS analiz aracı, CSS kod tabanı kalitesini denetlemek ve yeniden düzenleme planları yapmak için genel bir bakış elde etmek için fazlasıyla yeterlidir.

Yüksek Kaliteli CSS Yazma

CSS kod tabanının basitliği ve esnekliğinin kod kalitesi, performans ve görsel hatalarla ilgili birçok soruna nasıl neden olabileceğini gördük. CSS'yi mümkün olan en iyi şekilde yazmamızı ve yol boyunca olası tüm mimari tuzaklardan kaçınmamızı sağlayacak gümüş kurşun otomatik bir araç yoktur.

Yüksek kaliteli CSS kodu yazmamızı sağlayacak en iyi araçlar disiplin, detaylara dikkat ve genel CSS bilgi ve becerileridir . Geliştiricinin sürekli olarak büyük resmin farkında olması ve CSS'lerinin bu büyük resimde nasıl bir rol oynadığını anlaması gerekir.

Örneğin, seçicileri aşırı belirterek, tek bir geliştirici kullanılabilirliği ciddi şekilde sınırlayabilir, bu da diğer geliştiricilerin kodu farklı biçimlendirmeye sahip diğer benzer bileşenler için kullanmak üzere kopyalamak zorunda kalmasına neden olabilir. Bu sorunlar genellikle geliştiricilerin CSS'nin arkasındaki temel mekanizmaları (kademeli, devralma, tarayıcı performansı ve seçici özgüllüğü) anlamaması ve bunlardan yararlanmaması durumunda ortaya çıkar. Bu erken kararlar gelecekte büyük tepkilere yol açabilir , bu nedenle CSS kod tabanının sağlığı ve sürdürülebilirliği geliştiricinin bilgisine, becerilerine ve CSS temellerini anlamasına bağlıdır.

Otomatik araçlar, büyük resmin veya seçicinin nasıl kullanıldığının farkında değildir, bu nedenle bazı temel, öngörülebilir ve katı kuralları uygulamanın yanı sıra bu önemli mimari kararları alamazlar.

Kişisel deneyimimden bahsetmişken, aşağıdakilerin CSS ile çalışma şeklimi önemli ölçüde geliştirmeme yardımcı olduğunu gördüm:

• Mimari kalıpları öğrenmek.
  CSS Yönergeleri, genel programlama kalıplarına ve mimari ilkelere dayalı olarak yüksek kaliteli CSS yazmak için harika bir bilgi tabanı ve en iyi uygulamaları sağlar.
• Pratik yapın ve geliştirin.
  Becerilerinizi geliştirmek için kişisel projeler üzerinde çalışın veya Frontend Mentor'dan bir zorluğun üstesinden gelin. Basit projelerle (tek bir bileşen veya bölüm) başlayın ve yapabileceğiniz en iyi CSS'yi yazmaya odaklanın, çeşitli yaklaşımları deneyin, çeşitli mimari modeller uygulayın, yavaş yavaş kodu geliştirin ve yüksek kaliteli CSS'yi verimli bir şekilde yazmayı öğrenin.
• Hatalardan ders çıkarmak.
  İnanın bana, başlarken gerçekten kalitesiz CSS yazacaksınız. Doğru yapmak için birkaç denemeniz gerekecek. Bir dakikanızı ayırın ve neyin yanlış gittiğini düşünün, zayıf noktaları analiz edin, neyi farklı ve nasıl yapabileceğinizi düşünün ve gelecekte aynı hatalardan kaçınmaya çalışın.

Bir ekip içinde ve hatta tüm şirket için kurallar ve dahili CSS standartları oluşturmak da önemlidir. Açıkça tanımlanmış şirket çapında standartlar, kod stili ve ilkeler, aşağıdakiler gibi birçok fayda sağlayabilir:

• Birleşik ve tutarlı kod stili ve kalitesi
• Anlaşılması daha kolay, sağlam kod tabanı
• Kolaylaştırılmış proje katılımı
• Yalnızca lider ön uç geliştirici veya daha deneyimli geliştiriciler tarafından değil, herhangi bir ekip üyesi tarafından yapılabilecek standartlaştırılmış kod incelemeleri

Kirby Yardley, Sundance Institute tasarım sistemini ve CSS'yi yeniden düzenleme üzerinde çalıştı ve dahili kurallar ve en iyi uygulamalar oluşturmanın önemine dikkat çekti.

“Uygun kurallar ve strateji olmadan CSS, kötüye kullanıma uygun bir dildir. Geliştiriciler genellikle bu kodun diğer öğeler arasında nasıl yeniden kullanılabileceğini eleştirel olarak düşünmeden bir bileşene özel stiller yazarlar (…) CSS'mizi tasarlamaya nasıl yaklaşmak istediğimiz konusunda çok fazla araştırma ve müzakereden sonra, ITCSS adlı bir metodoloji kullanmaya karar verdik. “

trivago ekibinden önceki örneğe geri dönersek, dahili kurallar ve yönergeler oluşturmanın, yeniden düzenleme süreci için önemli bir adım olduğu kanıtlandı.

"Bir model kitaplığı sunduk, iş akışımızda atomik tasarım kullanmaya başladık, yeni kodlama yönergeleri oluşturduk ve CSS/UI'mizi büyük ölçekte koruma ve geliştirmede bize destek olmak için BEM ve ITCSS gibi çeşitli metodolojileri uyarladık."

Tüm kuralların ve standartların manuel olarak kontrol edilmesi ve uygulanması gerekmez. Stylelint gibi CSS linting araçları, hataları kontrol etmenize ve dahili standartları ve boş CSS kod bloklarına ve yorumlarına izin vermeme, yinelenen seçicilere izin vermeme, birimleri sınırlama, seçici maksimum özgüllüğünü ve yuvalama derinliğini ayarlama, seçici adı deseni, vb.

Çözüm

Parçacıklı bir kod tabanı yeniden düzenleme veya tam bir CSS yeniden yazma önermeye karar vermeden önce, gelecekte bunlardan kaçınabilmemiz ve süreç için ölçülebilir verilere sahip olabilmemiz için mevcut kod tabanıyla ilgili sorunları anlamamız gerekir. CSS kod tabanı, yeni özellikler eklerken beklenmeyen yan etkilere ve hatalara neden olan çok sayıda karmaşık yüksek özgüllük seçici içerebilir, belki kod tabanı ayrı bir yardımcı program sınıfına taşınabilen çok sayıda tekrarlanan kod parçasından veya belki de bunların karışımından muzdarip olabilir. çeşitli medya sorguları bazı beklenmedik çakışmalara neden oluyor.

CSS İstatistikleri ve Wallace gibi faydalı araçlar, CSS kod tabanına genel bir üst düzey genel bakış sağlayabilir ve kod tabanı durumu ve sağlığı hakkında ayrıntılı bir fikir verebilir. Bu araçlar ayrıca, yeniden düzenleme süreci için hedefler belirlemek ve yeniden düzenleme sürecini takip etmek için kullanılabilecek ölçülebilir istatistikler sağlar.

Yeniden düzenleme hedeflerini ve kapsamını belirledikten sonra, CSS kod tabanı için dahili yönergeleri ve en iyi uygulamaları belirlemek önemlidir - adlandırma kuralı, mimari ilkeler, dosya ve klasör yapısı vb. Bu, kod tutarlılığını sağlar, proje içinde belgelenebilecek temel bir temel oluşturur. ve işe alım ve CSS kod incelemesi için kullanılabilir. Stylelint gibi linting araçlarının kullanılması, kod inceleme sürecini kısmen otomatikleştirmek için bazı yaygın CSS en iyi uygulamalarının uygulanmasına yardımcı olabilir.

Bu üç bölümlük dizinin bir sonraki makalesinde, mevcut kod tabanı ile yeniden düzenlenmiş kod tabanı arasında sorunsuz bir geçiş sağlayan kurşun geçirmez bir CSS yeniden düzenleme stratejisine dalacağız.

Referanslar

• "ITCSS ile CSS Projelerini Yönetme", Harry Roberts
• “Trivago'da Büyük Ölçekli CSS Yeniden Düzenlemesi,” Christoph Reinartz
• “Sundance.org Tasarım Sistemi ve CSS Refactor,” Kirby Yardley
• "Semantik CSS'den Tailwind'e: Netlify UI Kod Tabanını Yeniden Düzenlemek," Charlie Gerard ve Leslie Cohn-Wein
• “CSS Denetim Araçları,” Iris Lješnjanin