Front-End Style Guide: Asıl Mesele Koddan Kopmaması
Çoğu front-end style guide iyi niyetle başlar, birkaç ay sonra kimse açmaz. Sebep genelde eksik bir bileşen değil: doküman koddan koptuğu an gerçeği yansıtmayı bırakır. Bu yazı o kopmayı nasıl engelleyeceğine bakıyor, bileşen listesini uzatmaya değil.
Önce şunu ayır: bu bir marka rehberi değil
Marka rehberi logoyu, rengi, tipografiyi tarif eder; editoryal rehber dilin kurallarını. Front-end style guide bunların koda döküldüğü yerdir: bir butonun nasıl görünmesi gerektiğini değil, hangi işaretleme ve stille üretildiğini söyler. Karışıklık burada başlıyor, çünkü çoğu ekip marka rehberini PDF olarak alıp style guide sanıyor. İkisi ayrı işler; biri nasıl görünmeli der, diğeri nasıl yapılır.
Asıl faydası tekrarı değil, çelişkiyi engellemesi
Bir butonu bir kez tanımlarsın, her ekranda aynı buton çıkar. Fayda genelde "kod tekrarını azaltmak" diye anlatılıyor ama daha önemlisi, aynı işi yapan iki farklı butonun aynı üründe belirmesini önlemesi. Kullanıcı açısından tutarlılık tam olarak budur: aynı şey her yerde aynı davranır. Modülerlik güzel bir yan etki, amacın kendisi değil.
Style guide'ları öldüren şey
Style guide'lar eksik bileşenden değil, koddan koptukları için ölür. Butonun köşe yarıçapını üründe değiştirip rehberde güncellemeyi unutursan, iki gün sonra rehber yalan söylemeye başlar; bir kez yanlış çıktıktan sonra kimse ona güvenmez ve açmayı bırakır. Bunu elle senkron tutmaya çalışma. Her bileşen değişikliği iki ayrı düzenleme demektir ve teslim baskısı geldiğinde her seferinde atlanan, ikinci düzenleme olur.
Çözüm, dokümanı üretim bileşenlerinden üretmek: rehberde butonun ekran görüntüsünü değil, gerçek bileşenin kendisini göster. Böylece kod değiştiğinde rehber de değişir, ayrıca bakılacak bir iş kalmaz. "Canlı doküman" ifadesi çoğu yerde bir dilek olarak geçiyor; oysa tek somut karşılığı bu, dokümanın kodla aynı kaynaktan render edilmesi.
Neyi koy, neyi boş ver
Yaygın listeler yirmi beş bileşeni tek tek saymanı ister. Gerek yok. Hepsinin altında yatan kararları sabitle: renk, boşluk, tipografi, grid. Bunları token olarak tanımladığında (bir renk için sabit bir değişken, her yere elle girilen HEX değil), üstüne kurulan her bileşen zaten tutarlı çıkar.
Responsive tarafı da aynı mantık. Her bileşene ayrı kırılım noktası yazmak yerine grid ve boşluk ölçeğini bir kez tanımla, bileşenler o ölçeğe otursun. Projene özel bir eleman varsa ekle; ama var olmayan bir bileşeni "belki lazım olur" diye rehbere koyma, çünkü bakımı olan her satır sonunda eskiyen bir satırdır.
Nereden başlanır
Her şeyi belgelemeye çalışma. Token'larla ve en çok tekrarlanan üç dört bileşenle başla, hepsini gerçek koddan üret. Küçük ama doğru bir rehber, kapsamlı ama eskimiş bir rehberden her zaman daha çok iş görür. Bir style guide'ın değeri kaç bileşen içerdiğinde değil, kaç aydır hâlâ doğru olduğunda.