Yeni bir projeye başlarken çoğumuzun yaptığı ilk şey yanlış: hangi teknolojiyi kullanacağımıza karar vermeye çalışmak. "React mı Vue mu, Postgres mi Mongo mu, monolit mi mikroservis mi" diye düşünmeye başlarız. Oysa bu soruların hiçbirinin, daha önce sorulması gereken soruları cevaplamadan bir anlamı yok.

Bu yazıda, bir projeye başlarken mimari ve teknoloji kararlarını neye göre verdiğimi — yani aracı seçmeden önce hangi soruları sorduğumu — anlatacağım. Burada amaç "şu stack'i kullan" demek değil; kararı nasıl vereceğin üzerine bir düşünme çerçevesi kurmak.

Teknolojiden değil, sorulardan başla

Mimari, bir teknolojiler listesi değildir. Mimari, kısıtlarına verdiğin cevaptır. O yüzden ilk iş, kısıtları netleştirmek. Herhangi bir araç seçmeden önce şu soruların cevabını bilmem gerekir:

• Ölçek nedir? 100 kullanıcı mı, 1 milyon mu? Günde 10 istek mi, saniyede 10.000 mi? Çoğu projenin gerçek cevabı düşündüğünden çok daha küçüktür — ve bu çok şeyi basitleştirir.
• Ekip ne biliyor? En "iyi" araç değil, ekibin en iyi bildiği araç çoğu zaman doğru seçimdir. Tanımadığın bir teknolojiyle başlamanın bedeli, o teknolojinin sağladığı avantajdan büyük olabilir.
• Ne kadar sürede çıkması gerekiyor? İki haftalık bir MVP ile beş yıl yaşayacak bir ürün aynı kararları vermez.
• Veri neye benziyor? İlişkisel mi (kullanıcılar, siparişler, yorumlar birbirine bağlı mı), yoksa gevşek ve yapısız mı? Bu tek soru, veritabanı kararının büyük kısmını verir.
• Ne kadar etkileşimli / gerçek zamanlı? Bir blog mu yazıyorsun, yoksa eş zamanlı düzenleme yapılan bir uygulama mı?
• Bunu kim, ne kadar süre bakacak? Altı ay sonra projeyi sen mi sürdüreceksin, yoksa devredecek misin?

Bu soruları cevaplamadan teknoloji seçmek, ölçüleri almadan elbise dikmeye benziyor.

En kullanışlı çerçeve: tersine çevrilebilir mi?

Aldığım her kararı tek bir soruyla ikiye ayırırım: bu kararı sonradan geri almak kolay mı, zor mu?

Bazı kararlar "tek yönlü kapı"dır — geçtikten sonra geri dönmek çok pahalıdır. Veritabanını proje büyüdükten sonra değiştirmek, temel veri modelini baştan kurmak, bir mikroservis mimarisini geri monolite toplamak... Bunlar tek yönlü kapılardır ve zaman ayırmayı hak ederler.

Bazı kararlarsa "çift yönlü kapı"dır — beğenmezsen kolayca geri dönersin. Bir CSS framework'ü, bir log kütüphanesi, klasör yapısı... Bunlar için saatlerce tartışmak israftır; en makul olanı seç ve devam et. Yanılırsan yarım günde değiştirirsin.

Junior ve senior geliştirici arasındaki farkın büyük kısmı burada: deneyimli geliştirici, hangi kararın hangi kapı olduğunu hızlı ayırır ve enerjisini doğru yere koyar. Çift yönlü kapılarda hızlı, tek yönlü kapılarda yavaş ve dikkatli olur.

Mimari seçimi: neredeyse her zaman monolitle başla

"Mikroservis mi monolit mi" sorusu yeni projelerde gereksiz yere çok tartışılır. Pratik cevabım net: monolitle başla.

Mikroservislerin çözdüğü problemler — bağımsız ölçekleme, ekiplerin bağımsız çalışması, hata izolasyonu — gerçek problemlerdir ama büyük projelerin problemleridir. Henüz birkaç kullanıcın varken mikroservise geçmek, olmayan bir hastalığa ilaç almak gibidir. Karşılığında dağıtık sistem karmaşıklığını, ağ gecikmelerini, deploy zorluğunu bedavadan satın alırsın.

Doğru yol şu: iyi modüllere bölünmüş bir monolitle başla. Sınırları temiz tut. Gün gelir gerçekten bir parça bağımsız ölçeklenmek isterse, o zaman onu ayır. Bu, "tek yönlü kapı"yı mümkün olduğunca geç açmak demek — ve genelde hiç açman gerekmez.

Veritabanı: varsayılanın ilişkisel olsun

Veritabanı kararı tek yönlü bir kapıdır, o yüzden dikkat ister. Benim pratik kuralım: veri ilişkiselse (ki çoğu uygulamada öyledir), ilişkisel bir veritabanıyla başla. Postgres çoğu durumda fazlasıyla yeterli ve seni ileride pişman etmeyecek güvenli bir varsayılandır.

NoSQL'in (Mongo gibi) yeri vardır — gerçekten yapısız veri, çok büyük ölçek, ya da şemanın sürekli değiştiği durumlar. Ama "esnek olur" diye NoSQL'le başlamak, çoğu zaman ileride elle kurmak zorunda kalacağın ilişkileri ve tutarlılık garantilerini kaybetmek demektir. İlişkin varsa — kullanıcının siparişleri, siparişin ürünleri — ilişkisel veritabanı zaten o iş için tasarlanmıştır.

Kural: NoSQL'i "havalı" olduğu için değil, ölçülebilir bir ihtiyaç onu zorunlu kıldığı için seç.

Aşırı mühendislikten kaç: bugünün problemini çöz

Yeni projelerdeki en sinsi hata, henüz var olmayan bir geleceğe göre tasarım yapmaktır. "Ya milyonlarca kullanıcı gelirse?", "Ya ileride şu özelliği eklersek?" diye bugün karmaşıklık eklemek, neredeyse her zaman israftır. Çünkü:

• O gelecek çoğu zaman hiç gelmez.
• Geldiğinde de ihtiyaçlar tahmin ettiğinden farklı çıkar.
• Bu arada, taşıdığın gereksiz karmaşıklık her gün seni yavaşlatır.

En basit çalışan çözümle başla. Gerçek bir acı hissedince — gerçekten yavaşladığında, gerçekten sınıra dayandığında — o zaman karmaşıklık ekle. Erken optimizasyon, çözmediğin bir problem için ödediğin peşin faturadır.

Pratikte: başlamadan önceki kontrol listem

Bir projeye girişmeden önce zihnimden geçirdiğim sıralama şu:

1. Ne inşa ediyorum ve kim için? Bir cümlede anlatabiliyor muyum?
2. Gerçek kısıtlar neler? Ölçek, süre, ekip, veri şekli.
3. En riskli / en belirsiz kısım hangisi? Önce onu netleştir; gerisi ona göre şekillenir.
4. Hangi kararlar tek yönlü kapı? Onlara zaman ayır, gerisini hızlı geç.
5. Bunu mümkün olan en basit haliyle nasıl yaparım? Karmaşıklığı sonraya, gerçekten gerekince sakla.

Sonuç

İyi mimari, en yeni ya da en güçlü araçları seçmek değil; bu projenin gerçek kısıtlarına en uygun ve en basit cevabı vermektir. "En iyi mimari" diye bir şey yoktur — bağlamına en uygun mimari vardır.

O yüzden bir sonraki projede "hangi teknolojiyi kullansam" diye başlamak yerine, "bu projenin gerçek derdi ne, hangi kararı geri almak zor, ve en basit çalışan şey ne" diye sor. Teknoloji seçimi, bu soruların cevabından kendiliğinden çıkacaktır.

Sen yeni bir projeye başlarken ilk hangi soruyu soruyorsun? Karar verirken en çok neye dikkat ediyorsun, merak ediyorum.