Bilişsel yük önemlidir

• Bu açık kaynak proje, yazılım geliştirmede bilişsel yükü azaltmanın çeşitli yöntem ve örneklerini sistematik biçimde derler
• Gereksiz derecede karmaşık kod, yapı ve soyutlamalar geliştirici verimliliğini düşürür ve bakım maliyetini artırır
• Modüllerde “küçük ve sığ” olmaktan ziyade, basit arayüzlere ve güçlü yeteneklere sahip derin yapılar tercih edilmelidir
• Aşırı soyutlama, framework bağımlılığı ve DRY ilkesinin kötüye kullanımı tersine bilişsel yükü artırır
• En iyi mimari, basit olan ve yeni geliştiricilerin de hızlıca anlayabildiği bir kod tabanıdır

---

Proje özeti ve önemi

Bu GitHub açık kaynak kaynağı, yazılım geliştirmenin temel ilkelerinden biri olarak ‘bilişsel yük’e (cognitive load) odaklanır. Bu deponun en büyük özelliği, ekip büyüklüğü ya da teknoloji trendlerinden bağımsız olarak geliştiricilerin gerçekte karşılaştığı karmaşıklık kaynaklarını çeşitli örnekler ve çözüm yollarıyla düzenlemesidir. Diğer best practice odaklı kaynaklardan farklı olarak, psikolojik ve bilişsel yükü de hesaba katar; bu sayede bakım ve yeni ekip üyelerinin onboarding süreçlerinde pratik avantaj sunar.

Giriş

• Geliştirme sahasında sık duyduğumuz trend kavramlar ve best practice'ler, gerçek geliştirme ortamında sık sık başarısız olur
• Gerçek iş hayatında hissedilen kafa karışıklığının ve bunun yol açtığı zaman/maliyet kaybının temel nedeni yüksek bilişsel yüktür
• Geliştiriciler kod yazmaktan çok kodu anlamaya ve okumaya zaman harcar
• Metin, gereksiz yere oluşan bilişsel yükü (Extraneous Cognitive Load) azaltmanın pratik yollarına odaklanır

Bilişsel yük nedir

• Bilişsel yük, geliştiricinin bir işi tamamlamak için zihninde tutmak zorunda olduğu bilgi miktarı anlamına gelir
• Ortalama olarak kısa süreli bellekte aynı anda yalnızca yaklaşık 4 adet ‘bilgi parçası’ (koşullar, değişken değerleri vb.) tutulabilir
• Bilişsel yük kritik eşiğe ulaştığında, anlama ve geliştirme hızında ciddi düşüş yaşanır

Bilişsel yük türleri

• İçsel bilişsel yük (Intrinsic): İşin kendi doğasındaki zorluktan kaynaklanır. Azaltılamaz
• Gereksiz bilişsel yük (Extraneous): Bilginin sunuluş biçimi, yapısal tasarım, gereksiz kalıplar gibi yapay karmaşıklıktan doğar. Aktif biçimde azaltılabilir

Pratik örnekler ve iyileştirme yolları

Karmaşık koşul ifadeleri

• Birden çok koşulun iç içe geçtiği kodda, her aşamada zihinde tutulması gereken içerik artar ve bilişsel yük yükselir
• Çözüm: Anlamlı ara değişkenler kullanarak her koşulun amacını net biçimde ayırmak

İç içe if ifadeleri vs Early Return

• İç içe if yapıları yerine Early Return deseni, önkoşulları akılda tutma yükünü azaltır
• Yalnızca ‘happy path’i hatırlamayı yeterli kılarak çalışma belleğini rahatlatır

Kalıtım yapısının yan etkileri

• Derin kalıtım hiyerarşileri (ör. sınıfA → sınıfB → sınıfC …), kodu anlamak için çok sayıda katman bilgisini aynı anda tutmayı gerektirir ve bilişsel yükü patlatır
• Çözüm: Önce composition, gereksiz kalıtım yerine bileşim kullanmak

Fazla sayıda sığ modül/fonksiyon

• 80 adet küçük ve sığ sınıf yerine, birkaç güçlü ve basit arayüze sahip derin modüller bakım açısından daha elverişlidir
• Örnek olarak UNIX I/O'nun basit arayüzü verilir: open, read, write, lseek, close

'Single Responsibility Principle' ilkesinin gelişigüzel yorumlanması

• “Sadece tek bir iş yapar” anlayışının muğlak yorumu, tersine sığ ve belirsiz soyutlamaların çoğalmasına yol açar
• Pratikte bunu ‘tek bir paydaşa karşı sorumludur’ diye yorumlamak, iş bağıntılarını anlamayı ve bilişsel yükü azaltmayı sağlar

Mikroservislerin aşırı kullanımı

• Çok sayıda sığ mikroservis, servisler arası ilişki ve entegrasyon bilgisini sürekli zihinde tutmayı gerektirir; bu da bilişsel yük ile debug/release maliyetini artırır
• Başlangıçta iyi kurgulanmış monolitik yapı, bakım açısından daha avantajlı olabilir

Dillerde aşırı özellik/seçenek yoğunluğu

• Dilin kendi içinde çok sayıda yeni özellik barındırması (özellikle C++ gibi), ‘neden böyle implemente edilmiş’ sorusunu takip ederken bellek yükünü biriktirir
• İş alanıyla ilgisiz ikincil bilişsel yükler üretir

HTTP durum kodları ile iş mantığı eşlemesi

• HTTP durum kodlarıyla (401, 403, 418 vb.) iç iş mantığı anlamlarının keyfi biçimde eşlenmesi, tüm ekip üyelerinin bunu ezberlemesini gerektirir
• İyileştirme: Kendini açıklayan string kodlar (ör. "jwt_has_expired") kullanarak tutarlı iletim sağlamak

DRY (Do not repeat yourself) ilkesinin kötüye kullanımı

• Karmaşık kod tabanlarında zorla tekrar kaldırmaya çalışmak, güçlü bağımlılıklar üretir; bunun sonucu olarak bilişsel yük ve değişiklik maliyeti artar
• Rob Pike’ın, yerelde ‘bir miktar kopyalamanın’ daha iyi olabileceğine dair sözü aktarılır

Framework bağımlılığı ve Layered Architecture'ın zararları

• Framework'ün ‘sihirli’ yapısına derin bağımlılık olduğunda, yeni geliştiricilerin iç mantığı kavraması uzun zaman alır
• Soyutlama katmanlarının birikmesi, gerçek sorun izleme anında bilişsel yükü sıçratır
• Asıl odak, temel ilkelere yönelmelidir: Dependency Inversion, Info Hiding, Cognitive Load control

Domain-Driven Design (DDD) hakkındaki yanlış anlamalar

• DDD'nin özü problem alanını analiz etmektir; klasör yapısı ya da kalıplara aşırı takılmak tersine öznel yorumlar ve bilişsel yük üretir
• ‘Team Topologies’ gibi framework'ler, bilişsel yükü bölüştürmede daha etkili olabilir

Aşinalık vs sadelik

• Aşinalık, sadelikle aynı şey değildir. Bir şeye alışkın olmak onu hafif hissettirebilir, ama yapı gerçekte daha basit olmuş olmaz
• Yeni katılan bir çalışan 40 dakikadan uzun süre kafa karışıklığı yaşıyorsa, bu kodun iyileştirilmesi gerektiğine dair bir işarettir

Gerçek başarı/başarısızlık örnekleri

• Instagram örneğinde olduğu gibi, basit monolitik mimari ile de yüksek ölçeklenebilirlik ve bakım deneyimi mümkündür
• “Gerçekten çok zeki geliştiricilerin” karmaşık yapılar kurduğu şirketlerde ise tersine başarısızlık deneyimleri sık görülmüştür
• Tüm geliştiricilerin kolayca okuyabildiği ve hızlı onboarding sağlayan yapı, verimliliği artırmada kilit rol oynar

Sonuç

• Asıl işin ötesine geçen gereksiz bilişsel yük, geliştirme sürecindeki herkes için zararlıdır
• En iyi kod, gelecekte başka geliştiricilerin ve kişinin kendisinin olabildiğince hızlı anlayabildiği koddur
• “Akıllıca görünmeye çalışan” yapılar yerine sıradan ve doğrudan çözümler, uzun vadede bakım ve ekip verimliliği için daha avantajlıdır

Referanslar/son notlar

• Rob Pike, Andrej Karpathy, Elon Musk, Addy Osmani, antirez (Redis geliştiricisi) gibi tanınmış geliştiricilerin görüşlerine de yer verilir
• Chromium, Redis, Instagram gibi gerçek büyük ölçekli örneklerle örtüşen çıkarımlar sunulur
• Sadelik, açıklık ve bilişsel yükü azaltma, yazılım sürdürülebilirliğinin özüdür

Bu açık kaynak projenin değeri

• Birçok yazılım tasarımı kitabı ya da kalıbının gözden kaçırdığı gerçek geliştirici deneyimi ve uygulanabilir örnekler üzerine kurulu bir kaynak
• Geliştirici onboarding'i, mimari incelemeleri ve uzun vadeli bakım gibi farklı ekip ihtiyaçlarına hemen pratik katkı sağlar
• Kodu ‘bilişsel yük’ adlı net bir çerçeveyle yeniden gözden geçirmek için bir kontrol listesi işlevi görür