Angular’ın Büyük Uygulamalar İçin Yapı ve Görüşleri Benimsemesi

Angular’da “yapı”, framework ve araçların teşvik ettiği varsayılan kalıplardır: şablonlu bileşenler, bağımlılık enjeksiyonu, yönlendirme yapılandırması ve CLI tarafından oluşturulan ortak proje düzenleri.

“Görüşler” bu kalıpları nasıl kullanacağınız konusunda önerilen yaklaşımlardır—bu yüzden çoğu Angular uygulaması benzer şekilde düzenlenir ve büyük kod tabanları daha kolay gezilebilir ve sürdürülebilir olur.

Büyük ekiplerde koordinasyon maliyetlerini azaltır. Tutarlı konvansiyonlarla geliştiriciler klasör yapıları, durum sınırları ve araç seçimleri üzerinde daha az tartışır.

Ana ödün esnekliktir: Ekip Angular’ın varsayılanlarından çok farklı bir mimari tercih ediyorsa, bu durum sürtüşmeye neden olabilir.

Kod sürüklenmesi, geliştiricilerin yakınlarda gördüklerini kopyalayıp küçük farklılıklar zamanla çoğaldığında ortaya çıkar.

Sürüklenmeyi sınırlamak için:

• Özellik yapısını standartlaştırın (ör. features/orders/, features/billing/).
• Yeni kodun aynı biçimde başlaması için CLI jeneratörlerini kullanın.
• Linting/formatlama ve kod inceleme kontrol listeleriyle kuralları uygulayın.

Angular’ın varsayılanları bu alışkanlıkların tutarlı şekilde benimsenmesini kolaylaştırır.

Bileşenler size tutarlı bir UI sahipliği birimi verir: şablon (render) + sınıf (durum/behaviour).

Aşağıdaki sınırlar net olduğu için ölçeklenirler:

• @Input() bileşenin hangi veriyi beklediğini tanımlar.
• @Output() hangi olayları yaydığını belirtir.
• Dosyalar genellikle birlikte bulunur, bu da özellikleri keşfetmeyi kolaylaştırır.

@Input() üstten alta veri geçirir; @Output() çocuktan üste olay gönderir.

Bu, tahmin edilebilir ve incelemesi kolay bir veri akışı oluşturur:

• Bir bileşenin açık API’sini hızlıca görürsünüz.
• Takımlar iç mantığı yeniden düzenleyip tüketicileri bozmadan değişiklik yapabilir.
• Ekranlar birbirine sıkı bağlanmak yerine bileşenler halinde birleşir.

NgModules tarihsel olarak ilgili deklarasyonları ve sağlayıcıları bir özellik sınırında toplardı. Standalone bileşenler modül yükünü azaltırken yine de yönlendirme ve klasör yapılarıyla net “özellik dilimleri” teşvik eder.

Pratik kural:

• Yeni UI parçaları için standalone tercih edin.
• Modül kullanıp kullanmamanıza bakılmaksızın özellik sınırlarını rotalar ve dizinler ile açık tutun.

Yaygın bir ayrım:

• Core: uygulama genelindeki tekil bileşenler ve altyapı (auth, interceptors, global servisler).
• Shared: tekrar kullanılabilir UI parçaları ve yardımcılar.
• Feature: alan-spesifik kod, genelde her yerde kullanılmamalı.

“God shared module” hatasından kaçınmak için shared parçaları bağımlılık açısından hafif ve odaklı tutun; her özellik yalnızca ihtiyacı olanı içersin.

Bağımlılık Enjeksiyonu (DI) bağımlılıkları açık ve değiştirilebilir yapar:

• Test etmeyi kolaylaştırır (gerçek servislerin yerine fake/mock koyabilirsiniz).
• Refaktörleri güvenli hale getirir (constructor bağımlılıkları bir sınıfın neye ihtiyaç duyduğunu gösterir).
• Tekrardan kaçınarak çapraz kesen davranışları paylaşmanızı sağlar.

new ApiService() yerine bileşenler ihtiyaç duyduklarını ister ve Angular doğru örneği sağlar.

Sağlayıcı kapsamı yaşam döngüsünü belirler:

• providedIn: 'root' uygulama çapında bir singleton gibidir—çapraz kesen endişeler için iyidir ama gizli paylaşımlı durum için risklidir.
• Özellik/rota düzeyinde sağlayıcılar, durumu o özellikle ya da navigasyon bağlamıyla sınırlar.

Niçin açık niyetli olun: durum sahibi net olmalı ve tekillikler yüzünden “gizemli global” durumlar birikmesine izin vermeyin.

Lazy loading hem performans hem de takım sınırları için faydalıdır:

• Kullanıcılar başlangıçta daha az kod indirir.
• Özellikler global kablolamaya daha az dokunarak evrilebilir.

Guards ve resolver’lar navigasyon kurallarını netleştirir:

• Guards auth/izin/kalıcı değişiklik uyarıları gibi politikaları uygular.
• Resolvers rota etkinleşmeden önce gerekli veriyi getirir; böylece yarım render olan ekranlar azalır.