09 Ağu 2025·1 dk
Angular’ın Büyük Uygulamalar İçin Yapı ve Görüşleri Benimsemesi
Angular, tutarlı kalıplar, araçlar, TypeScript, bağımlılık enjeksiyonu ve ölçeklenebilir mimariyle büyük ekiplerin sürdürülebilir uygulamalar geliştirmesini kolaylaştırmak için yapı ve görüşleri tercih eder.
Angular’da “Yapı ve Görüşler” Ne Anlama Gelir
Angular sık sık görüşlü (opinionated) olarak tanımlanır. Framework terimleriyle bu, sadece yapı taşları sunmakla kalmayıp bunların nasıl bir araya getirileceği konusunda da (önerilerde bulunup bazen dayatarak) yönlendirdiği anlamına gelir. Belirli dosya düzenleri, kalıplar, araçlar ve konvansiyonlar önerilir; bu sayede farklı ekipler tarafından inşa edilmiş iki Angular projesi bile “benzer” hissi verir.
Görüşlü olmak “kısıtlayıcı” değil—“kararlı” olmaktır
Angular’ın görüşleri, bileşenleri nasıl oluşturduğunuzda, özellikleri nasıl organize ettiğinizde, bağımlılık enjeksiyonunun nasıl varsayılan kullanıldığında ve yönlendirmenin tipik olarak nasıl yapılandırıldığında kendini gösterir. Birçok rekabet eden yaklaşımdan birini seçmenizi istemek yerine Angular önerilen seçenekleri daraltır.
Bu takas kasıtlıdır:
- Daha az karar: Mimari, klasör yapısı, durum sınırları veya derleme ayarları üzerine daha az tartışma harcarsınız.
- Daha az özgürlük: Eğer çok farklı bir stili tercih ediyorsanız, Angular bazen size karşı geliyormuş gibi gelebilir.
Neden büyük uygulamalar esneklikten çok tutarlılığı tercih eder
Küçük uygulamalar deneyleri tolere edebilir: farklı kod stilleri, aynı iş için birden fazla kütüphane veya zamanla evrilen ad-hoc kalıplar. Uzun yıllar bakım yapılan büyük Angular uygulamaları için bu esneklik yüksek maliyet doğurur. Büyük kod tabanlarında en zor problemler genellikle koordinasyon problemleridir: yeni geliştiricileri işe alıştırma, pull request’leri hızlıca inceleme, güvenle refaktör yapma ve onlarca özelliğin birlikte çalışmasını sağlama.
Angular’ın yapı yaklaşımı bu aktiviteleri öngörülebilir kılmayı hedefler. Kalıplar tutarlı olduğunda ekipler özellikler arasında kendinden emin hareket edebilir ve “bu parça nasıl yapılmış”ı yeniden öğrenmek yerine ürüne odaklanabilirler.
Bu yazıda neler ele alınacak
Yazının geri kalanında Angular’ın yapısının nereden geldiğini ele alacağız—mimari tercihleri (bileşenler, modüller/standalone, DI, yönlendirme), araçları (Angular CLI) ve bu görüşlerin ekip çalışmasını ve uzun vadeli bakımı nasıl desteklediğini.
SSS
Angular’ın “opinionated” (görüşlü) olduğu ne demektir?
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.
Angular’ın görüşleri büyük, uzun ömürlü projelerde nasıl fayda sağlar?
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” (code drift) nedir ve Angular bunu nasıl azaltır?
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.
Neden bileşenler Angular’da ölçeklenebilirlik için çekirdek yapı taşıdı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()` ve `@Output()` büyük arayüzlerde tahmin edilebilirliği nasıl artı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.
Özellik sınırları için NgModule mü yoksa standalone bileşenler mi kullanılmalı?
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.
Core vs Shared vs Feature kodunu nasıl düzenlemeli (ve “god shared module” tuzağından nasıl kaçınmalı)?
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.
Neden Angular’ın DI’si bir mimari varsayımdır?
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.
Bir servis root'ta mı yoksa özellik kapsamlı mı sağlanmalı?
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.
Routing, lazy loading, guards ve resolvers ölçeklenmeyi nasıl destekler?
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.