Ekibe yeni katılan bir mühendis ilk haftasının sonunda sordu: “Tek bir alan eklemek neden iki gün sürüyor?” Soru masumdu, teşhis netti. Kimse o sistemi bir gün oturup “karmaşıklaştıralım” diye kararlaştırmamıştı. Karmaşıklık öylece birikmişti.

Sorun da burada: karmaşıklık tek bir kararla gelmez, fark edilmeden birikir. Onu geri almak için önce onu görebilmek gerekir.

Karmaşıklık nasıl birikir

Hiçbir karmaşık sistem, karmaşık olmaya karar vermez. Her adım tek başına makul görünür: “şimdilik bir interface açalım”, “bu duruma bir flag koyalım”, “araya bir katman daha”. Her biri küçük, her biri savunulabilir.

Toplamları savunulabilir değil. Karmaşıklık bir olay değil, bir birikim — ve birikim, adı konmadığı sürece görünmez. Bu yüzden sadeleştirme bir his ile başlayamaz; somut sinyallerle başlar.

Somut sinyaller

Bir sistemin gereğinden karmaşık olduğunu söyleyen, tartışmaya kapalı kırmızı çizgiler:

  • Tek bir özelliği anlamak için çok sayıda dosya açıyorsunuz. Bir isteğin nereye gittiğini görmek altı dosya ve dört dolaylılık gerektiriyorsa, problem sizde değil, yapıdadır.
  • Tek satırlık bir değişiklik bir düzine dosyaya dokunuyor. Bir alan eklemek için migration, model, DTO, mapper, interface, factory, test fixture… Değişimin maliyeti, değişimin büyüklüğüyle orantılı değil.
  • Tek implementasyonlu interface’ler. “İhtimale karşı” açılmış, asla ikinci implementasyonu gelmemiş soyutlamalar. Bu, spekülatif genelliğin kod tabanında bıraktığı tortudur.
  • Onboarding haftalar sürüyor. Olgun ve sade bir sistemde yeni mühendis ilk günlerde üretkendir. Haftalar sürüyorsa, kod kendini anlatmıyordur.
  • Kimse sistemi tahtaya çizemiyor. “Şu kutu şuraya bağlı” diye anlatılamayan bir mimari, anlaşılmıyor demektir.
  • Test kurulumu testin kendisinden uzun. Bir davranışı test etmek için kurulması gereken on mock, o davranışın çok fazla şeye bağlı olduğunun itirafıdır.
  • “Oraya dokunma, kırılır.” Bir kod bölgesi dokunulmaz ilan edilmişse, o bölge zaten kırıktır — sadece henüz patlamamıştır.
  • Kimsenin kullanmadığı config, flag ve seçenekler. Açılıp unutulmuş her seçenek, kodu her okuyanın hesaba katması gereken bir daldır.

Bir sistemde bu sinyallerden ikisi-üçü varsa, tartışma “karmaşık mı” değil, “nereden başlayacağız”dır.

Sadeleştirmeye nereden başlanır

Sadeleştirme bir yeniden yazım değildir; çoğu zaman bir çıkarma işlemidir. Sırayla:

  1. Ölü kodu sil. Kullanılmayan flag, çağrılmayan method, ulaşılmayan branch. En düşük riskli, en yüksek getirili adım — silinen kodun bug’ı olmaz.
  2. Tek implementasyonlu interface’leri çök. Soyutlama gerçek bir ikinci kullanım kazanana kadar somut sınıfı doğrudan kullanın. Dikiş gerçekten gerektiğinde — ihtiyaç kanıtlandığında — birkaç saatlik bir refactor’la geri gelir.
  3. Erken dolaylılığı satır içine al. Tek yerden çağrılan, sadece argümanı bir başka fonksiyona geçiren katmanları kaldırın.
  4. Sınırları netleştir. Geriye kalan karmaşıklığı modüler monolitteki gibi net sınırların arkasına toplayın — böylece bir dahaki birikim erken görünür.

Her adımdan sonra durun ve ölçün. Sadeleştirme de aşırıya kaçabilir; amaç “en az kod” değil, “en az gereksiz kod”.

Karmaşıklık her zaman kötü değil

Önemli bir ayrım: karmaşıklığın iki türü var. Fred Brooks’un kavramlarıyla — özsel (essential) ve tesadüfi (accidental).

Özsel karmaşıklık domain’in kendisinden gelir. Vergi hesabı karmaşıktır, çünkü vergi mevzuatı karmaşıktır; bunu silemezsiniz, sadece dürüstçe modelleyebilirsiniz. Tesadüfi karmaşıklık ise sizin eklediğinizdir: gereksiz katman, erken soyutlama, unutulmuş flag.

Sadeleştirmenin hedefi tesadüfi olanı temizlemektir — özsel olanı değil. Bir sistemi “çok basit” yapıp domain’in gerçek karmaşıklığını görmezden gelmek de bir hatadır; o karmaşıklık silinmez, sadece yanlış yere — genelde çağıran kodun içine — taşınır.

İyi mimari, domain ne kadar karmaşıksa o kadar karmaşıktır; daha fazlası değil.

Karmaşıklık fark edilmeden birikir; bu yüzden onu fark edilir kılan sinyalleri ezbere bilmek bir mühendislik becerisidir. Sinyali adlandıramıyorsanız, sadeleştirmeye de başlayamazsınız.

Bir sistemi basit tutmak, onu basit kurmaktan daha çok emek ister — ve o emeğe değer.