Tailwind kullanım tartışması aslında soyutlama sorununa odaklanmalı

Yakın zamanda Dev.to platformunda ilginç bir tartışma başladı. "Tailwind'i Seviyorum – Affedersiniz!" ve "Tailwind'den Hoşlanmıyorum – Affedersiniz!" başlıklı iki makale, topluluğu ikiye böldü. Yüzlerce yorumun altında yatan ortak sorun, aslında uzun yıllardır teknoloji dünyasında tekrarlanan bir gerçeği gözler önüne serdi: Kodlama yaklaşımlarındaki tercihler, soyutlama düzeyleriyle doğrudan bağlantılıdır.

Primitifler mi, soyutlama mı? Asıl mesele bu

Bu tartışmaların arkasında yatan temel soru şu: Doğrudan ilkel bileşenleri mi kullanmalı, yoksa bunların üzerine soyutlama katmanları mı inşa etmelisiniz? Tailwind, size küçük, tek amaçlı ve birleştirilebilir yardımcı sınıflar sunan bir araç. Bu sınıflar, aslında CSS'in temel yapı taşları olarak kabul edilebilir. Tasarım kuralları tutarlıdır, adlandırma sistematiği mantıklı ve derleme sistemi kullanılmayan kodları otomatik olarak temizler.

Ancak Tailwind'in sunduğu bu ilkel düzey, doğrudan uygulama katmanınızda kullanılmamalıdır. Örneğin, aşağıdaki HTML koduna bakalım:

örnek

Görüldüğü gibi, bu yaklaşım CSS karmaşıklığını ortadan kaldırmıyor. Sadece bu karmaşıklığı, stilleri doğrudan şablonlara dağıtarak farklı bir forma dönüştürüyor. Ölçeklendikçe, bu sınıf dizileri giderek okunamaz hale geliyor. En azından CSS'in seçicileri, bileşenlere anlam katan isimlendirmeler sunuyordu.

Başarılı ekiplerin sırrı: Soyutlama katmanı

Tailwind'i seven ekipler, genellikle bu yardımcı sınıfları doğrudan kullanmazlar. Bunun yerine, bileşen kitaplıkları inşa etmek için Tailwind'i temel alırlar. Örneğin DaisyUI, Shadcn ve Headless UI gibi projelerde, yardımcı sınıflar bileşenlerin içinde tek bir kez tanımlanır ve kalan uygulama, bu bileşenleri kullanır. Soyutlama katmanı, gereken karmaşıklığı gizler ve okunabilirliği artırır.

Bu yaklaşım, yazılım mimarisindeki temel prensiplerle de paralellik gösterir. Örneğin:

• Veritabanı sorgularını doğrudan kontrolörlere dağıtmazsınız. Bunun yerine, bir model katmanı inşa edersiniz.
• HTTP çağrılarını görünüm dosyalarına yaymazsınız. Bunun yerine, hizmet katmanları oluşturursunuz.
• Mikroservisleri rastgele dağıtmazsınız. Bunun yerine, API geçitleri, servis ağları veya paylaşılan kitaplıklar kullanarak soyutlama düzeyini yönetirsiniz.

Mikroservisler de aslında ilkel bileşenlerdir: küçük, bağımsız ve tek amaçlı olarak tasarlanmışlardır. Ancak beş farklı servisin koordinasyonuyla tek bir özelliği hayata geçiriyorsanız, karmaşıklığı azaltmamış, sadece dağıtmış olursunuz. Başarılı ekipler, genellikle soyutlama katmanlarını doğru şekilde inşa ederler. Hatta bazı durumlarda, dağıtım maliyetini azaltmak için modüler monolitlere geri dönüş yaparlar.

Doğru dengeyi bulmak

İlkel bileşenler size güç ve esneklik sunar. Soyutlama katmanları ise okunabilirlik ve sürdürülebilirliği artırır. Buradaki kilit nokta, doğru dengeyi bulmaktır.

• Tailwind kullanıyorsanız, bileşenler inşa edin.
• Mikroservis mimarisini benimsiyorsanız, soyutlama katmanınızın dağıtım maliyetini haklı çıkaracak düzeyde olduğundan emin olun.
• Ham SQL kullanıyorsanız, işlevini açıklayan bir soyutlama katmanı inşa edin.

Araç asla sorun değildir. Sorun, ilkel düzeyi bitmiş mimari olarak görmektir.

Teknoloji dünyası, yıllar içinde bu tartışmaları farklı araçlarla yeniden yaşadı. REST mi GraphQL mi? Monolitik mi mikroservis mi? Vim mi Emacs mi? Farklı kılıflar altında hep aynı soruya yanıt aradık: İlkel bileşenleri doğrudan kullanmak yerine, üzerine inşa etmeyi nasıl başarabiliriz?

Cevap basit: Doğru soyutlama düzeyini belirleyin ve ilkel bileşenleri, uygulama katmanınızın altında saklayın.