BSkyB'nin kıdemli kullanıcı arayüzü geliştiricisi Harry Roberts'a göre, geliştiriciler, projelerdeki herhangi bir hızlı düzeltilmiş 'hack' CSS'sini silo etmek için shame.css adlı bir kavram kullanmalıdır.
Roberts, bir blog gönderisinde, bunun potansiyel olarak geliştiricilerin CSS'de biberli saldırıları görmesini engelleyeceğini ve bu nedenle bu tür şeylerin varsayılan olarak kabul edilebilir olduğunu düşündüğünü açıkladı.
Ek olarak, makale, böyle bir yaklaşımın, uygun şekilde belgelenmesi ve yineleme araçlarının eşlik etmesi halinde, bilgisayar korsanlarının kullanıldığı projelerde (herhangi bir nedenle) daha temiz CSS'ye doğru daha hızlı ilerlemeyi sağlayabileceğini belirtti.
.net, CSS'nin hacklenmesi ve shame.css'nin doğru kullanıldığında getirebileceği potansiyel avantajlar hakkında Roberts (HB) ile konuştu.
.net: Sektördeki bazı kişilerin, bir sitenin çalışmasını sağlamak için (umarım) kısa vadeli hack'lere duyulan ihtiyaç konusunda gerçekçi olmama eğilimi olduğunu düşünüyor musunuz?
HR: Büyük zaman. Yılda milyonlarca pound kazanan bir sitede veya üründe çalışıyorsanız, herhangi bir hata, kırılma veya tuhaflığın en kısa sürede düzeltilmesi gerekir. Ürün sahibiniz, CSS'nizin mükemmel olup olmadığını umursamıyor - sitenin çalışır durumda olmasını ve bu gelirin üzerinden geçmesini önemsiyor. İyi kod dır-dir önemlidir ve saldırılar ideal olmaktan uzaktır, ancak saldırıları her zaman önleyebileceğinizi ve kısa vadeli / hızlı düzeltmeler yapabileceğinizi düşünmek zordur.
.net: Yani iş dünyasında gerekli bir kötülük mü diyorsunuz?
HR: Bir müşteri başınızdan aşağı nefes aldığında veya canlı bir sitede bir özellik bozulduğunda, doğru paydaşları mutlu tuttuğunuzdan emin olmanız gerekir. İki dakikada yüzeysel olarak düzeltebileceğiniz bir şey için mükemmel bir düzeltme yazmak için bir saat harcarsanız, yanlış kişiyi, yani kendinizi mutlu ettiğinizi söyleyebilirim!
Kendi çalışmamda, hack'lere olan 'ihtiyacın' projenin büyüklüğü ile orantılı olarak arttığını buldum, ancak bunun iyi yanı, muhtemelen daha sonra bu hack'leri düzeltmeye adanmış daha fazla proje süresine sahip olacaksınız.
.net: shame.css burada devreye girer. Bu kavramla, CSS hackini özellikle neyi düşünüyorsunuz?
HR: Daha fazla zaman verildiğinde daha iyi yapılabilecek bir şey. Örnekleri bağlam dışında düşünmek zordur, ancak bir şeyin hack olduğunu çoğu zaman anlayacağınızı düşünüyorum. Bir meslektaşınıza açıklamaktan utanacağınız bir şey mi yazdınız? Muhtemelen bu bir hack!
Bu nedenle, shame.css, daha iyi yapabileceğiniz şeylerin bir dosyasını yapmak ve onları tekrar ziyaret etmek için zamanınız olduğunda daha iyisini yapmakla ilgilidir. Bu, kendi kendine yazılan bir yapılacaklar listesi, gerçekten - daha fazla zamanınız olduğunda düşünmek için bir tarafa koyduğunuz bir hack dosyası.
.net: Makalenizde, hack'leri belgelemekten bahsediyorsunuz, ancak geliştiricilerin sadece hackler için değil, genellikle CSS'yi daha fazla dokümante etmesi gerektiği bir argüman yok mu?
HR: Evet! Tüm geliştiricilerin daha fazla yapması gereken bir şey varsa, o da yorum yazmaktır. Yalnızca koddan hemen anlaşılmayan her şeyi yorumlamalısınız. Evinize giderken otobüs çarptığında iş arkadaşınızın ertesi gün işi devralabilmesi için kodunuzu belgeleyin.
.net: shame.css'yi entegre etmek açısından ne önerirsiniz?
HR: Ön işlemci kullanıyorsanız, @ithalat ayıp. [scss | daha az | vb] ideal olarak en sonunda dosya. (Bu her zaman özgüllük ve kaynak sipariş sorunlarına yol açabilir, bu nedenle kilometreniz değişebilir.)
Bir önişlemci kullanmıyorsanız, ancak iyi bir derleme süreciniz varsa, tüm CSS'niz dağıtımdan önce birleştirilmeli ve küçültülmelidir, böylece, yine, shame.css bunun sonuna kadar geçebilir.
Ön işlemci kullanmıyorsanız ve bir inşa süreciniz yoksa, o zaman muhtemelen bunu düzeltmelisiniz ve iki, stil sayfanızın sonundaki bir hack bölümü muhtemelen en iyi seçeneğinizdir. Shame.css genel görüntüleme için tasarlanmamıştır, bu nedenle asla işaretlemenizde bir bağlantı öğesi tarafından adlandırılan ayrı bir stil sayfası kullanmayın. Yalnızca birleştirilmiş ve küçültülmüş stil sayfası sunmalısınız.
.net: shame.css bir kavram olarak gerçekten hız kazanıyorsa, tasarım sürecini ve genel olarak web sitelerini nasıl değiştirebileceğini düşünüyorsunuz?
HR: Shame.css yalnızca onu uygulayan geliştiriciler kadar kullanışlıdır. Hack'leri izole etmek ve belgelemek her şey yolunda ve güzel, ancak onları asla düzeltmez veya tekrar ziyaret etmezseniz, eskisi gibi aynı gemide olursunuz.
Benim için shame.css, gelişimde daha geniş bir değişime işaret ediyor; CSS ile sınırlandırılmasına gerek yoktur. Kavram, yalnızca 'hack'lerinizi fark etmek, belgelemek ve onlara bir noktaya değinmek'tir. Bu düşünceyi her şeye uygulayabilirsiniz.
Shame.css ile ilgili gerçek çalışma, acil ekibinizi (geliştiricileri) işe almak ve ardından iş / PM'ler / scrum ustaları / BA'lar / ürün sahiplerinin (vb.) Bir ürünün bazen daha azını içereceği gerçeğinin farkına varmasını sağlamaktır. -than-ideal kod, ancak bu kodun iş gereksinimlerini karşılamak için mevcut olması.
Onlara bilgisayar korsanlarını izole ettiğinizi ve belgelediğinizi söyleyin ve işleri düzeltmek için biraz geliştirme zamanı ayırın. Bir kod tabanını toparlamak için bir iş vakası hazırlamak, eğer onu ölçebilirseniz daha kolaydır. Proje yöneticinize basitçe, "Özellik X'e geçmeden önce düzeltmem gereken bazı şeyler var" demeniz her zaman işe yaramayacaktır! Baş Müdürünüze bir şeyler listesi alın ve temizlik yapmak için yarım günlük sprint süresi ayırmaya çalışın.
Shame.css'nin arkasındaki fikir, hack'lerinizi daha şeffaf, ölçülebilir ve izole hale getirmektir. Bu bilgilerle ne yapacağınız size kalmış!
