Frontend Fundamentals

Toss frontend ekibi, iyi frontend kodu için benimsedikleri ölçütleri tanıtan bir site yayınladı.

• Frontend geliştiricilerinin ağırlıklı olarak kullandığı TypeScript temel alınarak anlatılıyor
• Okunabilirlik/öngörülebilirlik/bağlılık/coupling olmak üzere 4 bakış açısından best practice sunuluyor
• Gerçek frontend geliştirmede sık kullanılan kütüphanelerden yararlanan örnekler veriliyor

4 ölçüt

1. Okunabilirlik
   Okunabilirlik (Readability), kodun ne kadar kolay okunabildiğini ifade eder. Kodun değiştirilmesinin kolay olması için önce kodun ne yaptığını anlayabilmek gerekir.

2. Öngörülebilirlik
   Öngörülebilirlik (Predictability), birlikte çalışan ekip arkadaşlarının bir fonksiyonun ya da bileşenin davranışını ne kadar tahmin edebildiğini ifade eder. Öngörülebilirliği yüksek kod, tutarlı kuralları takip eder; ayrıca yalnızca fonksiyon ya da bileşenin adı, parametreleri ve dönüş değeri görülerek nasıl davranacağı anlaşılabilir.

3. Bağlılık
   Bağlılık (Cohesion), değiştirilmesi gereken kodun her zaman birlikte değiştirilip değiştirilmediğini ifade eder. Bağlılığı yüksek kodda, kodun bir bölümünü değiştirseniz bile başka bölümlerde istemeden hata oluşmaz. Çünkü birlikte değiştirilmesi gereken kısımlar, mutlaka birlikte değiştirilecek şekilde yapısal olarak desteklenir.

4. Coupling
   Coupling, kod değiştirildiğinde etki alanının ne kadar geniş olduğunu ifade eder. Kodu değiştirdiğinizde etki alanı küçükse ve değişikliğin kapsamı öngörülebiliyorsa, o kodun değiştirilmesi kolaydır.

[savvykang]

Bileşenler ve hook’lar için neden en küçük yönetim birimi olarak dosyanın kullanıldığını merak ediyorum. Bunun IDE desteğinin ya da tree shaking’in yetersiz olmasından kaynaklandığını tahmin edebiliyorum ama emin olmadığım için sormak istiyorum.

Kod okurken tek bir fonksiyondan oluşan dosyalar ya da sadece import/export ifadeleri bulunan index.ts dosyaları gördüğümde, akılda tutulması gereken şeylerin arttığını hissediyorum. Bunu, tek bir dosya içinde hook ve bileşenlerin birlikte kullanıldığı yaklaşımla karşılaştırınca, gereğinden fazla bilişsel yük oluşturan bir düzen gibi geliyor. Buna rağmen böyle bir düzeni kullanmanın avantajları ya da sebepleri var mı?

[firea32]

Genelde böyle yerlerde sözü edilen “iyi geliştirme”nin temel öncülü, birçok geliştiricinin birlikte çalışıyor olmasıdır.
Bahsettiğiniz gibi hatırlanması gereken şeylerin artması = kişinin projenin tamamı üzerinde sorumluluk taşıdığı anlamına gelir, ama
geliştiricinin çok olduğu ortamlarda herkes yalnızca kendi üstlendiği kısmı geliştirir.
Bir sorun çıkarsa sadece o kısma bakmak yeterlidir; ilgili olan her parçaya bakmak gerekmez.
Bir açıdan bakınca bunun, aşırı optimizasyon yerine üretkenliğin seçilmesi olduğunu düşünüyorum.

[savvykang]

Belirttiğiniz gibi, iş bölümünün ayrıntılı biçimde yapılabildiği bir ortamda metindeki içerik doğru bir tercih. Kod ayrımı yapılırken ortaya çıkan trade-off'lar ve karar verme ölçütleri de açıklansaydı, bence daha bütünlüklü bir yazı olurdu.

[beenzinozino]

Benim durumumda, frontend geliştirme yaparken bileşenler veya hook’lar için en küçük yönetim birimi olarak dosyayı kullanmamın nedenleri aşağıdaki gibi.

1. Test kolaylığı.

Yani, tek bir modülle tek bir unit test’i eşleştirmek daha kolay oluyor.

Frontend geliştirmenin büyük ölçüde saf fonksiyonlar üzerinden bir paradigmayı takip ettiğini düşünüyorum; bu yüzden tek bir dosyada birden fazla fonksiyon varsa unit test yazarken bire bir eşleştirme zorlaşıyor.

Örneğin remark-plugin.js adlı tek bir dosyanın içinde birden fazla utility fonksiyonu varsa testi nasıl yazmalıyız? Sadece bir tane remark-plugin.test.js dosyası oluşturup birden fazla utility fonksiyonu için testleri topluca yazmak iyi bir tercih olur mu?

Böyle bir durumda remark-plugins adlı bir dizin oluşturup utility fonksiyonlarını onun içinde tek tek bölerek ayırıp test yazarsak, sonrasında fonksiyonların rollerini daha net hâle getirebiliriz ve GitHub commit takibi de çok daha düzenli olur gibi avantajlar olduğunu düşünüyorum.

2. Dizin yapısını düzenleme

Sunucu geliştirmedeki commonjs ya da istemci tarafındaki webpack gibi modül bundler’lar, index.js dosyasını belirli bir dizinin giriş dosyası olarak tanımlayan durumlarda sıkça kullanılıyor. Bu aynı zamanda eskiden beri sık kullanılan bir alışkanlık olduğu için, bir kısmı da bunu olduğu gibi kabul edip kullanmaktan kaynaklanıyor.

Ama bence en önemli neden şu: fonksiyonel programlamadaki saf fonksiyon paradigmasında dış duruma bağımlı olunmaması gerekir; dolayısıyla bir dosyada birden fazla fonksiyon toplanırsa dış duruma referans verme hatası yapma olasılığı artıyor. (ES6’da modül scope’unun neden ortaya çıktığını düşünürseniz iyi olabilir.)

3. Commit takibini kolaylaştırması.

Bana göre tek bir dosyanın içinde birden fazla utility fonksiyonunun karışık hâlde bulunmasındansa, fonksiyonların ayrı ayrı dosyalara bölünmüş olması commit geçmişini takip etmeyi çok daha kolaylaştırıyor.

Bir modüle özellik eklendiğinde ya da bir bug düzeltildiğinde, başka modüllere bakmaya gerek kalmadan sadece o modüle odaklanmak yeterli oluyor.

---

Yazarken metin uzadı ve biraz dağınık olmuş. (Tree shaking konusunda hâlâ yeterince iyi anlamadığımı düşündüğüm için o konuda çok konuşmayayım...) Elbette benim söylediklerim tek doğru olmayabilir, o yüzden bunu bir referans olarak değerlendirirseniz iyi olur!

[thkimdev]

Bu güzelmiş.

[illiil1lii]

Oldukça akıcı ve iyi yazılmış. Tavsiye ederim.

[tsboard]

Paylaştığınız için teşekkürler! Benim de dikkatlice okumam gerekecek.

[bbulbum]

FE ile sınırlı yazılmış olsa da, genel olarak yazılım için de uygulanması iyi olacak şeyler gibi görünüyor. Güzel içgörüleri paylaştığınız için teşekkürler.