Bilişsel yük önemlidir

 (github.com/zakirullin)
10 puan yazan GN⁺ 2025-08-31 | 1 yorum | WhatsApp'ta paylaş
  • 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

İlgili okumalar

1 yorum

 
GN⁺ 2025-08-31
Hacker News görüşü

  • En büyük aydınlanmayı John Ousterhout’un A Philosophy Of Software Design kitabından aldım; bu konuda en iyi kitap olduğunu düşünüyorum ve geliştiriciyseniz mutlaka okumanızı tavsiye ederim. Ana fikir, yazılım tasarımında hedefin karmaşıklığı en aza indirmek olması gerektiği; burada karmaşıklık, “değiştirmenin ne kadar zor olduğu” olarak tanımlanıyor ve bu “zorluk” da kodu anlamak için gereken bilişsel yük tarafından belirleniyor

    • Sorun şu ki hiçbir kural sonuçta muhakemenin, deneyimin ve sezginin yerini alamaz. Her kural tartışma aracı haline gelebilir ve mimari tartışmalarında asla kazanamazsınız. Bu yazının iyi tarafı şu: buna ihtiyacı olmayanlar zaten biliyor, gerçekten ihtiyacı olanlar ise bunu anlayamayacak. Sonuçta bu teknik bir sorun değil, insan ve kültür sorunu. Mimari de nihayetinde insanlardan ve kültürden çıkar. Nasıl Rob Pike ve Google varsa Go ortaya çıkıyorsa, sadece bir kitap okuyarak Go gibi bir dil doğmaz

    • DRY ilkesi (kendini tekrar etme) bence ancak uygulamayı gerçekten yeterince anladıktan ve birkaç sürümünü çıkardıktan sonra düşünülmesi gereken bir ilke. Başta ise tekrar ederek önce problem alanını anlamak, ikinci sürümde bakım yapılabilirliği düşünmek gerekir. Ancak üçüncü sürüm civarında DRY uygulamak mantıklıdır

    • Jeff Bezos’a para vermeden bu kitabı edinmek inanılmaz zor. John’u tanıyan biri varsa lütfen bu sorunu ona iletsin. Kampüs kitapçısında yoktu, yerel kitapçılarda ya da Powell’s’ta da bulamadım

    • Uzun zaman önce mükemmel yazılım çözümünü aramaktan vazgeçtim. Kimsenin bunu kusursuzca çözebilmiş olduğunu sanmıyorum. Sonuçta elimizdeki en iyi silah insanların bilgeliği ve deneyimi. Bağlam, sektör ve ekipler o kadar farklı ki bunu sayılarla ya da yasalarla net biçimde tanımlayamazsınız. Ben sonunda tasarımda “dağınıklık” ile “güzellik” arasında denge bulmayı hedef edindim. En zor kısım, iş dünyası belirsizken yazılımın deterministik olması; iş gereksinimleri sürekli değişiyor ve bunları bilgisayar sistemlerinin katılığına uydurmak zor. Artık kodu değiştirmeye çalışırken doğrudan rahatsızlık hissedersem refactor etmeye girişiyorum. O zaman da sadece asgari düzenlemeyi yapıyorum. Bu şekilde tekrar eden refactor döngüleri zamanla yeni kalıplar doğuruyor, bazen onları soyutlamaya dönüştürüyorum

    • Bu kitap tam olarak bu konudaki en iyi kaynak. Söz konusu yazı da bu kitaptan ilham aldı. Yazar John’la da yazının içeriği hakkında bir iki kez konuşmuştum

  • Başkalarının bilişsel yükünü azaltan kod yazabilmek çok nadir ve çok zor bir beceri. Bu yetenek sizde olsa bile sürekli çaba istiyor. Sonuçta geliştiricinin işi temel fikri sıkıştırıp özünü görünür kılmak ve yalnızca zorunlu olan karmaşıklığı açığa çıkarmak. Gerçekte bunu iyi yapanı neredeyse hiç görmedim

    • Gerçekten iyi yazılmış kod sonunda insanlara “Bu zaten baştan beri kolay bir problem miydi?” yanılsaması yaşatır. Buna karşılık, karmaşıklığı göze çarpan “iskambil kâğıdından ev” tarzı kod, harcanan emeğin kanıtı gibi görülür ve hatta terfiye kadar gidebilir

    • Bu durum arayüz ya da UX/etkileşim tasarımı için de aynen geçerli. Geliştiriciler bilişsel yükü sıradan insanlara göre çok daha iyi taşır, ama teknik olmayan insanların rahat kullanacağı bir şey yapmak için geliştiricinin kendi sezgisinin dışına çıkması gerekir; bu da çok zordur. Sıradan kullanıcıların karmaşık problemleri sezgisel biçimde çözmesini sağlayacak araçlar tasarlamak gerçekten zordur

    • Soyutlamaların çoğu gereksinimler değiştiğinde ayakta kalamaz. Benim sevdiğim framework’ler, sonsuza kadar kusursuz bir soyutlama katmanı kuramayacağını bilir ve kasıtlı olarak “kaçış kapıları” bırakır. (Örneğin web UI framework’lerinde html element’e doğrudan referans verme gibi.) Geleceği kusursuz öngöremeyeceğini bilmek önemli bir bilgeliktir

    • Aslında bu beceri birçok şirkette zorunluluktan çok bir artı değer. Büyük kod tabanlarına bakınca bunu kolayca görebilirsiniz

  • Kendimi “inekçe eğilimleri olan zeki geliştiricilerden” biri sayıyorum. Soyutlama kurmayı seviyorum. Sektörün son zamanlarda “if yığını mimarisine” kayması bana hem ilginç hem de kaygı verici geliyor. Basit göründüğü için anlaşılması kolay ve verilen ticket’ı kapatmak için yeterli olduğundan insanların bunu neden sevdiğini anlıyorum. Geliştirme süreçlerinin çoğu if yığınlarına dayanıyor ve bu yöntem belli bir ölçekte gerçekten işe yarıyor. Hatta büyük çaplı veri sızıntıları olsa bile çoğu zaman kimse hesap vermiyor. Ama mesele şu ki bundan daha iyi bir alternatif olup olmadığını da bilmiyorum. Gösterişli soyutlamalar ya da havalı mimariler de gerçekte kodun tutarlılığını artırmıyor gibi görünüyor. Özellikle kurumsal ortamlarda, iş mantığının sahipleri mantığın kendisine neredeyse hiç dikkat etmediği için dikkatle güzel soyutlamalar kurmak mümkün olmuyor. Sonunda “sipariş yalnızca tek bir adrese gönderilir” gibi bir gereksinim varken aniden “büyük müşteri birden fazla adrese teslim istiyor” deniyor ve böyle bir kaos içinde hatasız soyutlama kurmak zorlaşıyor. Bazen gerçekten kurumsal yazılımda if yığınlarının en iyi seçenek olup olmadığını düşünüyorum

    • “If yığını” yaklaşımı en iyisi mi sorusuna cevaben, gerçek dünyadaki büyük yazılım mimarilerini ele alan Big Ball of Mud makalesini ve özet yazısını öneririm. Gerçek sistemler her zaman evrilir; başlangıçta bir “çamur topu” gibi başlar, parçalar halinde iyileşir, sonra yeni değişimler gelince bir zamanların güzel soyutlamaları da çöker. Esas nokta, küçük bir kasabanın şehre dönüşmesi gibi, alan modelleme, yeterli düzeyde soyutlama ve gerektiğinde yıkıcı değişimlerin birleşimiyle sistemi büyütmektir

    • Bu tür yazılımlarda da güzel soyutlamalar kurulabilir, ama iş mantığı devreye girdiği andan itibaren bunları korumak zorlaşır. Soyutlamanın görece sağlam kaldığı alanlar genelde ürünsel kısımlardır: örneğin kimlik doğrulama, yetkilendirme, loglama, veritabanı, middleware, altyapı gibi. İç iş mantığı soyutlamayı etkilemeye başladığında işler yine dağılır. Bazı yerlerde iş tarafındaki kişilerin mantığı doğrudan yönetmesi denendi; bunun sonucu test etmesi zor, anlaması imkânsız, hatta simülasyonu bile yapılamayan sistemler oldu. Sonunda operasyon gerekince junior geliştiricinin grafik araçla kod yazdığı durumlar ortaya çıktı. Kaç kez yeniden yazarsanız yazın, 2-3 yıl sonra her şey yine karmakarışık oluyor

    • İş tarafındaki insanların iş mantığını uygulayıcıya eksiksiz anlatması imkânsız. Kendileri anlıyor olsalar bile bunu kodlama perspektifinden ifade edemiyorlar. Hatta uygulayıcılardan en az birinin kullanıcı deneyimini iliklerine kadar yaşamış olması gerekiyor ki gerçekten anlayabilsin. Gerçekte şirketler departman ayrımını dayatıyor ve “iş mantığı” kimsenin sahiplenmediği bir bölgeye dönüşüyor; sonunda yalnızca if’lerle oynanıyor

    • Asıl nokta şu: gerçekliğin kendisi, yani iş dünyasının kendisi zaten bir if yığını. Problem ya da alan belirgin biçimde teknikse veya genelleştirilebiliyorsa, soyutlama ile if’leri azaltabilirsiniz; ama alanın kendisi kaotikse, soyutlamanın da temelinde “esneklik” olmak zorunda. Hatta çelişki bile bir özellik haline gelebilir

    • Codex CLI gibi araçlarla oynarsanız, bu araçların bir hatayla karşılaşınca sürekli belirli bir duruma özel if yaması ürettiğini görürsünüz. Ona doğrudan bir kalıp öğretip yeni bir soyutlama istemezseniz, durmadan “heuristic” dediği yeni if’ler ekler. Belirli türde 10 hata için 10 yama üretir ve 11. benzer hata geldiğinde doğal olarak çalışmaz. Codex’in sunduğu çözüm, tekrar eden if’lerin toplamı oluyor

  • Tamamen yabancı olduğunuz bir projede değişiklik yapmanızın istenmesi gerçek hayatta ne kadar sık oluyor, emin değilim. Projeden projeye çok sık geçmiyorsanız belki iki yılda bir olur. Deneyim eksikliği değil, gerçekten zor problemlere odaklanmak daha mantıklı bence

  • Microsoft geliştirici organizasyonunda 8 yıl çalışırken, ilk dönemlerdeki mühendis tipleri modeli çok faydalı olmuştu. Üç persona vardı; sonra daha karmaşık bir çerçeveye geçildi. Yine de o ilk personelar bugün bile kariyerim boyunca diğer mühendislerle etkili iletişim kurmama çok yardımcı oldu.

    • Mort: Pragmatik mühendis; iş sonucu birinci öncelik. İsterse if yığını olsun, hızlı çalışıyorsa yeter.
    • Elvis: Önceliği yenilik; en yeni teknolojileri kullanmak ister, kendi dehasının fark edilmesini bekler. Yeni framework’ler, kırılgan kod, görünürlük ve inovasyon takıntısı.
    • Einstein: Performans, zarafet ve teknik doğruluğa takıntılı. Kodun tutarlılığını ve teknik mükemmelliği daha çok önemser. Gerçekte her mühendis bu üçünün bir karışımıdır. Birkaç PR ve tasarım incelemesinden sonra baskın eğilimi kabaca anlayabilirsiniz

    • Buna Amanda diye bir mühendis tipi de eklenmeli bence. 20 yıl boyunca kendi ve başkalarının dağınık kodunu inceleye inceleye artık kodun her şeyden önce insanlar tarafından okunmak için var olduğunu içselleştirmiş kişi. Keşke sadece böyle Amanda’lardan oluşan bir ekibim olsa

    • Mort pragmatisttir, Einstein mükemmeliyetçidir, Elvis ise... dürüst olmak gerekirse projeye zararlı bir figürdür. Biraz motive edici olabilir ama ideal ekip Mort ile Einstein’ın iyi bir karışımıdır. Gerektiği kadar basit, ama yeterince doğru olmalı ki bakım eziyete dönüşmesin. Hatta Mort’a uzun soluklu bir proje verince zamanla Einstein gibi özen göstermeye başlıyor. Bu arada, son dönemde otomatik kodlama ajanları o kadar Mort ağırlıklı ki, ben bile onları yöneten bir Mort olmak zorunda kalıyorum

    • Persona’lar iyi bir araçtır. Benim deneyimimde zamanla yanlış kestirme yollara dönüşüyorlar. Elvis gerçekte kurum içi siyasette kullanılan bir terimdi ve Goodhart yasasında olduğu gibi, mantıklı görünmeye başlayınca herkes bunu tartışmalarda kullanmak istedi, böylece faydası azaldı. Alan Cooper zamanında Visual Basic geliştirme süreciyle birlikte persona kavramını öne çıkarmıştı. Benim bakış açımdan önemli olan, bilim insanı ile firmware geliştiricisinin değerlerinin farklı olduğunu anlayabilmek. İlgili kitap

    • En iyi mühendisler bence bu üç eğilimi projeye, duruma ve kişisel hedeflere göre ayarlayabilenlerdir. Her rol farklı oranlar ister. Örneğin compiler optimizasyonunda Einstein ve Mort daha fazla gerekirken, oyun motoru kodunda oran değişebilir. Bu özelliklerin birebir doğru olup olmadığı tartışılabilir, ama esas mesele herkesin zaman içinde farklı biçimde çalışması gerektiğidir

    • Bu yaklaşımın sınırları olmalı. İnsanları fazla basit kategorilere ayırmak haksız ve kalıcı etiketlemeye dönüşebilir. Benim deneyimimde yöneticiler Elvis’ten çok Mort’u tercih ediyor. Gerçek çözümün liderlik ve yönetimde olduğunu düşünüyorum. Mort’a kod kalitesi standartlarını gereksinimlere dahil edip verirseniz, biraz daha yavaş olsa da gayet iyi sonuç çıkarabilir. Elvis’e sınır koymak, Einstein’lara da pratik teslim koşullarını net vermek gerekir. Yine de bu yaklaşım insan karmaşıklığını göz ardı etme sınırına sahip

  • Yapay zekânın yazılım sektörüne zarar vermesinden endişe ediyorum. Yapay zekâ insan sınırlarına sahip değil; bu yüzden çok karmaşık, okunması zor ama çalışan kod üretebilir ve bir gün o sistem bozulduğunda kimse düzeltemeyebilir. Bu yüzden junior mühendislere yalnızca yapay zekâya yaslanmamalarını, kod tabanının karakterini öğrenmelerini tavsiye ediyorum. Yoksa kendi başlarına kod yazabilme becerilerini kaybederler

    • Yapay zekâ çalışmayı bıraksa bile yeniden düzeltilebilir, o yüzden bu iddia bana pek ikna edici gelmiyor

    • Ben kendi deneyimimde, yapay zekâdan yazdığı kodu anlayabileceğim noktaya kadar sürekli sadeleştirmesini istiyorum. Karmaşık bir yaklaşım seçerse daha basit hale getirmesini, gereksiz dış kütüphane kullanıyorsa çıkarmasını, stdlib ile çözmesini ya da mevcut bağımlılıklarla yetinmesini söylüyorum. Yapay zekâ kodu benim yerime yazıyor; kendisi için değil

    • Hatta tam tersine, yapay zekâ sayesinde düşük seviyeli tasarımın bilişsel yükü azalacağı için üst seviye mimari üzerine daha çok düşünebilir ve yazılım kalitesi artabilir diye düşünüyorum

  • Yazıda geçen “zeki geliştiricilere özgü alışkanlıklar” ifadesi bence yazarın yalnızca kendi yazdığı ya da kendi tarzında yazılmış kodu anlayabildiği anlamına geliyor gibi. Oysa bilişsel yükü azaltmanın gerçek yolu, okunması gerekmeyen kod miktarını en aza indirmektir. Güçlü sınırlar ve net API’ler değişiklik yapmayı kolaylaştırır; mesele tüm kod değil, iyi tanımlanmış arayüzlerden türeyen karmaşıklıkla ilgilenmektir. “Zeki geliştirici” tuhaflığı aslında yüzeysel bir sorun

    • Mikroservis fikrinin en büyük avantajı tam da bu. İki ekip yalnızca API üzerinden konuşuyorsa ve schema gibi araçlarla sınırlar sert biçimde tanımlanıyorsa, insanlar değişime aşırı temkinli yaklaşır ve önceden çok daha derin düşünür. Değişmesini istemediğiniz noktalara teknik olarak yapay sürtünme eklemek gibi bir etki yaratıyor

    • Debug yaparken çok hissettiğim bir şey var: çağrı yığını üzerinde doğrudan debug etmeniz gereken kod aşırı optimize edilmişse çok yorucu oluyor. Bu yüzden belirli kısımları fonksiyonlara ayırıp commit’leri bölmek iyi oluyor; istenmeyen değişiklikleri rollback etmek kolaylaşıyor ve kod odağı artıyor. PR’da tek seferde gelebilir ama sınırlar netse yine de çok daha iyi

    • Geliştiriciler genelde “sözleşmeler ve arayüzler” üzerinden düşünmekte çok iyi değil. Amaç, insanların iç uygulamaya değil dışarıya verilen sözlere bakması olmalı. Hedef, kodu okumadan da anlaşılabilmesi. Eğer benim kodumu anlamak için insanların gidip içine bakması gerekiyorsa, başarısız olmuşum demektir

    • API ne kadar net olursa olsun, iç kod yine de kolay anlaşılır olmayabilir. Dışarıdan düzgün çalışıyor gibi görünse de pratikte çoğu zaman içine inmek zorunda kalırsınız

  • Bu yazının deneyimlerimi çok iyi özetlemesini gerçekten sevdim. Resmî olarak öğrendiğim programlama metodolojilerinin çoğu, bir başkası benim kodumu okumak zorunda kaldığında ters etki yapıyor. Rust ve C++ gibi karmaşıklığı saklayan diller zorlayıcı; C gibi kodu altı kat template arkasına gizleyemediğiniz yapılarda ise daha huzurlu hissediyorum

    • Benim deneyimimle de örtüşüyor. Ben de aynı nedenle C’yi seviyordum; son dönemde Golang’a geçtim ve onun bu sadeliğini seviyorum

  • Kod erişilebilirliğinin birinci sınıf bir unsur gibi ele alınması gerektiği sözü bana çok anlamlı geliyor. Kuralları rehber olarak alın; gerçekten usta olanlar, kodu okunur kılmak için hangi bağlamda kuralları ne zaman esneteceğini ya da tamamlayacağını bilir. Sonuçta önemli olan, kodun bilişsel yükünü ve tavizlerini sezgisel olarak hissedebilme yeteneği. İster tekrar olsun ister soyutlama, altı ay sonraki kendinizi de dahil olmak üzere sıradaki kişiyi hep düşünmek gerekir. Bir kural daha ekleyelim talebi ise kendi başına aynı sorunun tekrarı. Temel yönergelerden sonra mesele tacit knowledge, yani deneyimden doğan örtük bilgidir. Zaman geçtikçe hangi kodun iyi, hangisinin kötü olduğunu kendiniz hissetmeye başlarsınız. Sonunda bunu bizzat hissetmeniz gerekir

    • Kod erişilebilirliğinin özüne katılıyorum ama yazarın germane overhead’i (alıcının bilişsel kaynak tüketimi) göz ardı etmesi üzücü. Sonuçta kod erişilebilirliğini artırmak için intrinsic, extraneous ve germane olmak üzere üç tür overhead’in hepsini düşünmek gerekir

  • “Neden”i belgeleyin denir ama ben “neden” ile “ne”yi ayırmakta zorlandığım için ikisini de yazarım. En kötü yorumlardan biri şudur:

    x = 4 // x'e 4 ata

    Kodla yorumu karıştırınca okumak zorlaşıyor ve bağlam değişimi artıyor. Onun yerine

    // bunu neden yaptığımız ve ne yapacağımız
setup();
t = setupThing();
t.useThing(42);
t.theWidget(need=true);
...

    gibi yorum ile kodu net biçimde ayırmak daha iyi. Yine de “ne”yi yazmak bile hiçbir şey yazmamaktan çok daha iyidir ve bilişsel yükü azaltır

    • Bu biçimdeki yorumları çoğu zaman güncel tutmak zordur; uygulama yılda beş kez değişir ve yorumlar hızla bayatlayıp kafa karıştırır. Son projelerimde gerçekten zor mantık ve en üst seviye dokümantasyon dışında yorumların çoğunu sildim

    • Bence bazen ikisini de, yani why/what’ı belgelemek gerekir. Kimi zaman gerekçeyi, kimi zaman davranışı netleştirmek önemlidir. Bugünlerde yorumların değeri bence küçümseniyor. Her satıra yorum eklemek gerekmez ama “kendi kendini belgeleyen kod” denilen şeylerin çoğu da pek kolay okunmuyor

    • Son zamanlarda en zor şeyin neyi kodda bırakıp neyi tasarım/teknik dokümana koyacağına karar vermek olduğunu düşünüyorum. Benim vardığım sonuç şu: kod içi yorumlar, sezgisel olmayan ya da gizli niyetleri açıklamak için en uygunu. Örneğin: “Bunu memoize etme nedenimiz X”

    • ChatGPT tarzı x=4 yorumuna güldüm. Ama önerilen yaklaşımın dezavantajı da şu: yorumların kodla uyumsuz şekilde eskimesi riski. Kodu değiştirirken yorumu da mutlaka güncellemek gerekir

    • Ben eğitim olarak programcı değil, fizikçiyim; bu yüzden yorum yazarken her seferinde bunu bu biçime çevirmeye çalışıyorum. Öğrenciyken not almak için olabildiğince çok yorum yazmak bir alışkanlıktı