Frontend projelerde klasör yapısı genelde küçük bir detay gibi görülür. Ama proje büyüdükçe bu “küçük detay” en kritik konulardan birine dönüşür. Doğru yapı okunabilirliği, ekip hızını ve sürdürülebilirliği artırırken; yanlış yapı zamanla kaos üretir. Bu yazıda klasör yapısının uzun vadeli etkisini ve doğru yaklaşımı ele alıyoruz.
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.
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.
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 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.
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 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.
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.
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.
