Yıllarca şöyle öğretildi: büyüün, ayrışın, her servis kendi deposunda. Her proje kendi deposunda, kendi betiklerinde, kendi sürümünde... Sonra küçük ekip işinin yarısı "hangisi hangi repodaydı?" sorusunu cevaplamak oldu. Son yıllarda ise sessiz ama belirgin bir dönüş var: küçük ekipler yeniden tek çatı altında, monorepo'ya dönüyor. Bu tesadüf değil; ihtiyaç.

Dağınık Deponun Bedeli

Beş kişilik bir ekip, dört depo ve on iki ayrı kopya arasında uyumu korumaya çalışınca ne oluyor? Ortak tip tanımları bir repodan diğerine elle kopyalanıyor. Bir değişiklik için üç ayrı depoda ardışık pull request açılıyor. Sürüm numaraları birbirine karışıyor, "çalışıyor ama hangi sürümde?" sorusu rutin hâle geliyor. Dağınık düzen büyük ekiplerde sorumluluk sınırları çizerken, küçük ekipte ağırlık merkezini bozuyor: insanlar kod yazmak yerine düzeni ayakta tutmaya çalışıyor.

Tek Çatı, Tek Kaynak

Monorepo'nun küçük ekip için vaadi basit: tek gerçek kaynak. Ortak tipler ve yardımcı paketler tek yerde; kimse kopyalamıyor, herkes içinden çekiyor. Bir arayüz değiştiğinde o arayüzü kullanan uygulamalar aynı commit'te düzeltilebiliyor; mantıksal olarak tek işin parçaları olan değişiklikler tek pull request'te, tek review'da, tek deploy'da birleşiyor. Modern araçlar bu düzeni ucuzlattı: pnpm workspaces bağımlılıkları tek yerde topluyor, Turborepo benzeri araçlar yalnızca değişen kısmı derleyip test ederek "tek depo yavaş demektir" efsanesini çürüttü. Küçük ekipte günün sonunda tek bir yeşil CI hattı, üç tanesinden kıymetlidir.

Dönüşümün en az konuşulan kazançlarından biri de hafıza. Tek depoda tarih, ekibin ortam hafızasıdır: iki yıl önce bir karar neden alındı, hangi hatadan kaçınıldı, hangi çözüm denenip neyle reddedildi — hepsi aynı yerde durur. Ayrı depolarda ise bu hafıza, insanların belleğine ve şirketten ayrılmış kişilerin ekranlarına mahkûmdur. Yeni katılan bir meslektaşın "buraya nasıl alışacağım?" sorusunun cevabı, tek çatı altında çok daha kısa yazılır.

Her Derde Deva Değil

Dürüst olalım: monorepo sihirli değnek değil. Erişim izinlerini katı bölmek gerekiyorsa, sürümleri bağımsız yöneten çok sayıda takım varsa ya da açık kaynak projede dış katkıyı sınırlı tutmak zorundaysanız, çoklu depo hâlâ makul bir seçim. Soru "monorepo mu, çoklu depo mu?" değil; "şu anki düzen, ekibimizin iletişim biçimini yansıtıyor mu?" Küçük ekipte cevap genellikle net: iletişim zaten aynı masada, kodun da öyle olmasın.

Mimarlık, ekibin kendi kendine konuşma biçimidir. Ekip tek masadaysa, kodun da tek çatısı olsun.

Bizce bu dönüş, modaya değil ölçüye dayanıyor. Küçük ekiplerin en kıt kaynakları olan zaman ve dikkat, yeni düzeni üstünde değil, ürünün üstünde harcanmayı hak ediyor.