Yönetilebilir ve sürdürülebilir CSS
Hiçbir şey bilmeyen birisi için birkaç haftalık süreç CSS ve HTML yazmayı öğrenmek için yeterlidir.
Acaba gerçekten öyle mi?
Evet form elementlerini DOM ağacına yerleştirmek ve bu elementlere renk, boyut, konum özelliklerini vermek çok zor olmayan şeyler. Fakat büyüyen ve karmaşıklaşan yapılarda maalesef her şey bu kadar kolay olmuyor.
Biz de Hesapkurdu.com ekibi olarak “önceki yazılımcılardan” kalan legacy kodlar ile boğuştuğumuz ve zaman zaman halen buna maruz kaldığımız zorlu bir süreç geçirdik.
Peki bize zorluk çıkaran temel sorunlar nelerdi?
· Yapıları ve parçaları doğru oluşturulmayan mimari,
· Komponent yapısını terketmiş sayfa bazlı yazım tekniği ve bunların sebep olduğu kendini tekrar eden onlarca satır kod,
· Binlerce satırdan oluşan ve içinde kaybolunan kod yapıları (4000 satırlık SCSS dosyaları gördüm),
· Yanlış mimariden kaynaklanan çok büyük nested (iç içe kod) yapıları ve bunları ezmek için artık sayısı hesaplanamayan !important kuralları.
Biz bunlardan kurtulmak için ne yaptık konusuna gelmek gerekirse…
Öncelikli olarak kendimize bir naming convention seçtik. Tercihimiz BEM oldu. Bu seçimimiz mimarimiz için de bize bir yol gösterici oldu aslında. Artık sayfa yapısından çıkıp komponent bazlı ve yeniden kullanılabilir arayüzler yazmak için bir karar almış oluyorduk böylece.
BEM için kısa bir özet geçmek gerekirse; css methodları 3 ana başlığa ayrılır. Bunlar;
· Block,
· Element ve
· Modifier dir.
Her komponent bir “block”tur. Komponentlerin içerisindeki nested elemanlar ise “element”tir. Blocklar üzerinde spesifik kodlar yazmak için ise modifierleri kullanırız.
card -> Block
card__item -> Element (elementler iki tane alt çizgi ile kullanılır.)
card — positive -> Modifier (modifierler iki çizgi ile kullanılır.)
BEM kararının ardından sırası ile diğer adımlara geçtik.
Mevcut durumda kodlarımız SCSS üzerinde yazılıyordu ve bunu değiştirmek için şu an itibari ile geçerli bir sebep görmedik. Fakat mimari üzerinde ciddi ölçüde dönüşümlere gittik. Bir kısmını tamamlamakla beraber halen tamamlamamız ve buraya taşımamız gereken bir çok noktamız bulunmakta.
Çizmiş olduğumuz mimari ise şu şekilde işliyor;
_base.scss : Tema için gerekli dosyaları ve kütüphaneleri import eden dosyadır. Bootstrap, mixin kütüphaneleri, boyut, renk değişkenleri, font ayarları gibi.
Settings klasörü : Değişkenler, tema ayarları gibi scss dosyalarını saklayan klasördür.
GUI klasörü : Temamızı oluşturan ana kod bloklarını içeren klasördür. Temayı bir organizma olarak düşünürsek birleşerek daha büyük parçalar oluşturan yapılar ortaya çıkartırlar.
Page klasörü : Sayfalar özelinde bundle edilecek dosyaları içeren scss dosyalarıdır. Bu kısımda hiçbir zaman yeni bir css kodu yazılmaz. Sadece o sayfa için gerekli scss dosyaları import edilir. Gerekli css kodları “/gui/layout/” dizini içerisinde yazılır.
Bunlarla beraber daha önce Orhun’un yazısında bahsettiği gibi Devops süreçleri içerisinde kod analizleri ile sıkıntılı kodlarımızın temizliğini gerçekleştirdik.
Bütün bunlar bize ne katıyor?
Aslında temel olarak Front end geliştirme ortamı olarak daha rahat çalışılabilecek bir ortam açıyoruz kendimize. Daha az efor harcayarak koda daha kontrollü dokunuşlar gerçekleştirebiliyoruz. Bi yeri yaparken başka yerleri kırıp dökmüyoruz.
Komponent bazlı mimari ile kendimizi tekrar etmiyoruz. Yazdığımız kodu yeniden yazmıyoruz. Kaynağımızı gereksiz şişirmeyip aynı zamanda kendi eforlarımızı azaltıyoruz.
Kod parçalarımızı küçültüyoruz. Artık toplam kodu 100 satır olan dosyalar üzerinde düzenlemeler yapmaya başladık.
BEM ile ne yaptığı tahmin edilebilir kodlar ortaya çıkartıyoruz. Element ve modifier mantığı ile nested element kullanımlarına son veriyoruz. Bu da kod ezmek istediğimiz zamanlarda bunu çok kolay yapabilmemizi sağlıyor. Sıfır (0) sayıda !important kuralı kullanıyoruz.
Bütün bunların ışığında katettiğimiz oldukça ciddi bir mesafe var fakat bundan çok daha fazlasını yapabileceğimizi biliyoruz. Gerçekleştirdiğimiz ve denediğimiz her şeyi buradan paylaşmaya devam edeceğiz.
Yeni yazılarda görüşmeyi umuyoruz :)
