Frontend Klasör Yapısı Sandığınızdan Daha Önemlidir

Frontend projeye başlarken klasör yapısı genelde çok düşünülmez. Çoğu zaman hızlı başlamak için basit bir yapı kurulur: components, pages, utils gibi birkaç klasör açılır ve geliştirme başlar. İlk başta her şey gayet düzenli görünür. Dosyalar bulunabilir, ekip küçükse herkes neyin nerede olduğunu bilir. Problem genelde burada başlamaz.

Problem proje büyüdüğünde başlar.

Feature sayısı arttıkça, component’lar çoğaldıkça ve ekip genişledikçe başlangıçta “yeterli” olan yapı yavaş yavaş zorlanmaya başlar. Aynı klasör içinde onlarca dosya birikir, isimlendirmeler tutarsızlaşır ve bir şeyi bulmak için klasörler arasında gezinmek gerekir. Kod hâlâ çalışıyordur ama geliştirme hızı düşmeye başlar.

Aslında burada yaşanan şey teknik bir problemden çok organizasyon problemidir.

Dosya Yapısı = Düşünce Yapısı

Klasör yapısı sadece dosyaları gruplamak değildir. Projeyi nasıl düşündüğünü gösterir. Kodun nasıl organize edildiği, sistemin nasıl kurgulandığını doğrudan yansıtır.

Örneğin tamamen “type-based” bir yapı düşünelim:

Bu yapı başlangıçta sade ve anlaşılırdır. Ama zamanla şu problem ortaya çıkar: Aynı feature’a ait kodlar farklı klasörlere dağılır. Bir sayfanın logic’i hooks içinde, UI’ı components içinde, API çağrısı services içinde olur. Bir değişiklik yapmak için birden fazla klasör arasında gezmen gerekir.

Bu da context switching maliyeti oluşturur.

Feature-Based Yaklaşım

Bu noktada birçok ekip “feature-based” yapıya geçer:

Bu yaklaşımda ilgili her şey aynı yerde tutulur. Bu da özellikle büyük projelerde okunabilirliği ciddi şekilde artırır. Çünkü bir feature ile ilgili çalışırken tek bir klasör içinde kalırsın.

Ama bu yaklaşım da tek başına çözüm değildir. Kontrolsüz kullanıldığında feature klasörleri kendi içinde mini bir monolite dönüşebilir.

En Sık Yapılan Hata

En sık yapılan hatalardan biri şu: Yapıyı baştan “mükemmel” kurmaya çalışmak.

Gerçek şu ki doğru klasör yapısı proje ile birlikte evrilir. Başlangıçta fazla karmaşık bir yapı kurmak, ihtiyacın olmayan abstraction’lar üretir. Bu da geliştirmeyi yavaşlatır.

Diğer uçta ise hiç düşünmeden ilerlemek vardır. Bu da zamanla refactor maliyetini büyütür.

Küçük Kararlar, Büyük Etki

Bir component’i nereye koyduğun
Bir hook’u nasıl ayırdığın
Bir util’in scope’unu nasıl belirlediğin

Bunlar küçük kararlar gibi görünür. Ama zamanla birikir ve projenin sürdürülebilirliğini belirler.

Örneğin reusable olmayan bir component’i global components klasörüne koymak kısa vadede kolaydır. Ama zamanla o klasör şişer ve gerçekten reusable olanlar kaybolur.

Benzer şekilde, sadece tek bir yerde kullanılan bir helper fonksiyonu utils altına atmak, ileride gereksiz bağımlılıklar yaratır.

İyi Bir Yapının Özellikleri

İyi bir klasör yapısı şu özelliklere sahiptir:

• Bulması kolaydır

• Taşıması kolaydır

• İzole edilebilir

• Büyüdüğünde kırılmaz

Ve en önemlisi: ekip tarafından anlaşılırdır.

Gerçek Hayat Senaryosu

Diyelim ki sepete ürün ekleme özelliğinde bir değişiklik yapacaksın.

Type-based yapıda şunları gezersin:
components → hooks → services

Feature-based yapıda ise direkt cart klasörüne girersin ve işini halledersin.

Aradaki fark küçük gibi görünür ama gün içinde defalarca tekrarlandığında ciddi bir verim farkı yaratır.

Sonuç

Frontend klasör yapısı küçük bir detay değildir. Uzun vadede proje hızını, ekip verimliliğini ve kod kalitesini doğrudan etkiler.

Tek bir doğru yapı yoktur. Ama yanlış yapıların ortak özelliği aynıdır: büyüdükçe yavaşlatır.

İyi mühendislik burada devreye girer. Yapıyı ihtiyaçlara göre şekillendirmek, gereksiz karmaşıklıktan kaçınmak ve sistemi sürdürülebilir tutmak.

Çünkü günün sonunda mesele sadece kod yazmak değil, o kodun yaşayacağı ortamı doğru kurmaktır.