Dijkstra ve Yapısal Programlama: Ölçeğini Koruyan Disiplin

Dijkstra, Yazılım Büyüdüğünde Neden Hâlâ Önemli?\n\nYazılım nadiren yazılamadığı için başarısız olur. Başarısız olmasının nedeni, bir yıl sonra kimsenin onu güvenle değiştiremiyor olmasıdır.\n\nKod tabanları büyüdükçe her “küçük” düzeltme dalga etkisi yaratır: bir hata uzak bir özelliği bozar, yeni bir gereksinim yeniden yazmaları zorunlu kılar ve basit bir refaktör dikkatli koordinasyon gerektiren bir haftaya dönüşür. Zor olan şey kod eklemek değil—çevresindeki her şey değişirken davranışı öngörülebilir tutmaktır.\n\n### Vaad: Doğruluk ve sadelik uzun vadeli maliyeti düşürür\n\nEdsger Dijkstra, doğruluk ve sadeliğin birer zorunluluk olması gerektiğini savunuyordu, sadece hoş bir seçenek değil. Getiri akademik değil. Bir sistem üzerinde akıl yürütmek daha kolay olduğunda, ekipler yangın söndürmek yerine inşa etmekle uğraşır.\n\n- Doğruluk hataların maliyetini azaltır: daha az olay, daha az regresyon, daha az “buna dokunma” kodu.\n- Sadelik değişiklik maliyetini azaltır: daha az gizli varsayım, daha az özel durum, incelemeler sırasında daha az sürpriz.\n\n### “Ölçek” aslında ne demek?\n\nİnsanlar yazılımın “ölçeklenmesi” gerektiğini söylediklerinde genellikle performansı kastediyor. Dijkstra’nın vurgusu farklı: karmaşıklık da ölçeklenir.\n\nÖlçek şu şekillerde görünür:\n\n- Daha fazla özellik: yeni akışlar, kenar durumlar ve kullanıcı beklentileri.\n- Daha fazla insan: el değişimleri, farklı stiller ve değişen bağlamlar.\n- Daha fazla entegrasyon: harici API'ler, veri kaynakları ve hata modları.\n- Daha fazla zaman: miras kararları, değişen gereksinimler ve kısmi yeniden yazımlar.\n\n### Temel fikir: yapı davranışı tahmin etmeyi kolaylaştırır\n\nYapısal programlama katı olmak için değildir. Kontrol akışını ve ayrımı, şu iki soruyu yanıtlamayı kolaylaştıracak şekilde seçmektir:\n\n- “Sonraki ne olur?”\n- “Hangi koşullar altında?”\n\nDavranış öngörülebilir olduğunda, değişiklik rutin haline gelir; riskli olmaz. Bu yüzden Dijkstra hâlâ önemli: onun disiplini, büyüyen yazılımın gerçek darboğazını hedefler—onu geliştirebilecek kadar iyi anlamak.\n\n## Edsger Dijkstra ve Onun Amacına Kısa Bir Giriş\n\nEdsger W. Dijkstra (1930–2002), güvenilir yazılım inşa etme konusunda programcıların düşünme biçimini şekillendiren Hollandalı bir bilgisayar bilimcisiydi. Erken işletim sistemleri üzerinde çalıştı, adıyla anılan en kısa yol algoritması da dahil olmak üzere algoritmalara katkıda bulundu ve—günlük geliştiriciler için en önemlisi—programlamanın haklı çıkarılabilir bir etkinlik olması gerektiğini savundu; yani sadece “çalışana kadar deneme” değil, mantıklı şekilde açıklanabilmeliydi.\n\n### Onun temel odağı: “makinemde çalışıyor”dan daha fazlası\n\nDijkstra, bir programın birkaç örnek için doğru çıktı üretip üretmediğinden çok, neden doğru olduğunu açıklayabilmemiz ile ilgileniyordu.\n\nEğer bir kod parçasının ne yapması gerektiğini ifade edebiliyorsanız, adım adım bunun gerçekten gerçekleştiğini savunabilmelisiniz. Bu zihniyet doğal olarak izlenmesi, gözden geçirilmesi ve kahramanca hata ayıklamaya daha az bağımlı kodlara yol açar.\n\n### Neden katı gelir—ve bunun nasıl yardımcı olduğu\n\nDijkstra’nın bazı yazıları sert gelebilir. O, “zekice” hileleri, gevşek kontrol akışını ve akıl yürütmeyi zorlaştıran kodlama alışkanlıklarını eleştirmiştir. Bu sertlik bir stil polisi değil; belirsizliği azaltma amacıdır. Kodun anlamı net olduğunda, niyetler üzerine tartışmak yerine davranışı doğrulamaya daha fazla zaman harcanır.\n\n### “Yapısal programlama” ne demek (yüksek seviyede)\n\nYapısal programlama, programları küçük bir dizi net kontrol yapısından—sıra, seçim (if/else) ve yineleme (döngüler)—kurma pratiğidir; karışık atlamalara güvenmek yerine. Amaç basit: programın içindeki yolu anlaşılır kılmak, böylece onu güvenle açıklayabilir, sürdürebilir ve değiştirebilirsiniz.\n\n## Doğruluk: Kullanıcılarınızın Güvendiği Gizli Özellik\n\nİnsanlar yazılım kalitesini genellikle “hızlı”, “güzel” veya “özellik dolu” olarak tanımlar. Kullanıcılar doğruluğu farklı deneyimler: uygulamanın onları şaşırtmayacağına dair sessiz bir güven olarak. Doğruluk olduğunda kimse fark etmez. Eksik olduğunda, diğer her şey önemsizleşir.\n\n### “Şimdi çalışıyor” vs “çalışmaya devam ediyor”\n\n“Şimdi çalışıyor” genellikle birkaç yol denediniz ve beklenen sonucu aldınız demektir. “Çalışmaya devam ediyor” ise refaktörler, yeni entegrasyonlar, artan trafik ve yeni ekip üyeleri kodla oynadıktan sonra bile amaçlandığı gibi davranması demektir.\n\nBir özellik “şimdi çalışabilir” ama hâlâ kırılgan olabilir:\n\n- Girdinin her zaman temiz olduğu varsayımına dayanabilir.\n- Bir ağ çağrısının her zaman hızlı döneceğini varsayabilir.\n- Sadece mutlu yolu kapsayan testleri geçiyor olabilir.\n\nDoğruluk, bu gizli varsayımları kaldırmak veya onları açıkça ifade etmektir.\n\n### Küçük hataların büyük sistemlerde nasıl çoğaldığı\n\nKüçük bir hata yazılım büyüdükçe nadiren küçük kalır. Bir yanlış durum, bir off-by-one sınırı veya belirsiz hata işleme kuralı yeni modüllere kopyalanır, başka servislerin etrafında sarılır, önbelleğe alınır veya “dolaşılan” bir sorun haline gelir. Zamanla ekipler “neyin doğru olduğunu” sormayı bırakır ve “genelde ne olur” sorusuna dayanır. O zaman olay müdahalesi arkeolojiye döner.\n\nÇarpan bağımlılıktır: küçük bir yanlış davranış birçok aşağı akış yanlış davranışına dönüşür ve her biri kendi kısmi düzeltmesini getirir.\n\n### Açıklık bir doğruluk aracıdır (sadece stil seçimi değil)\n\nAçık kod doğruluğu geliştirir çünkü iletişimi geliştirir:\n\n- Kod incelemeleri niyet açık olduğunda gerçek sorunları yakalar.\n- Onboarding kurallar okunabilir olduğunda daha hızlı olur; kabile bilgisinden ziyade belgelendirme vardır.\n- Olaylar kontrol akışı ve hata modları kolay takip edilebildiğinde daha çabuk çözülür.\n\n### Ürün ekipleri için pratik bir doğruluk tanımı\n\nDoğruluk demek: desteklediğimizi iddia ettiğimiz girdiler ve durumlar için sistem, vaat ettiğimiz sonuçları tutarlı şekilde üretir—ve yapamadığında öngörülebilir, açıklanabilir şekillerde başarısız olur.\n\n## Sadelik Bir Strateji, Stil Tercihi Değil\n\nSadelik kodu “sevimli”, minimal veya zekice yapmakla ilgili değildir. Sadelik, davranışı korkmadan tahmin etmeyi, açıklamayı ve değiştirmeyi kolaylaştırmaktır. Dijkstra sadeliği, özellikle kod tabanı ve ekip büyüdüğünde programlar hakkında akıl yürütme yetimizi geliştirdiği için değer verdi.\n\n### Sadelik nedir (ve ne değildir)\n\nBasit kod aynı anda az sayıda fikri işler: net veri akışı, net kontrol akışı ve net sorumluluklar. Okuyucunun kafasında birçok alternatif yolu simüle etmesini zorunlu kılmaz.\n\nSadelik değildir:\n\n- Her ne pahasına olursa olsun daha az satır\n- “Akıllı” numaralar, yoğun tek satırlar veya ağır soyutlamalar\n- Esnek görünmek için yapıyı atlamak\n\n### Kazara karmaşıklık: istemeden ekledikleriniz\n\nBirçok sistem zor değişir hale gelmez çünkü domain doğası gereği karmaşıktır; bunun yerine kazara karmaşıklık ekleriz: beklenmedik şekilde etkileşen bayraklar, asla kaldırılmayan özel yamalar ve önceki kararların etrafında dönen katmanlar.\n\nHer ekstra istisna anlama vergi koyar. Maliyet, birisi bir hatayı düzeltmeye çalıştığında bir değişikliğin birkaç diğer alanı ince şekilde bozduğunu keşfettiğinde ortaya çıkar.\n\n### Basit tasarımlar kahramanlıklara ihtiyaç duymaz\n\nBir tasarım basitse ilerleme sürekli çalışmadan gelir: gözden geçirilebilir değişiklikler, daha küçük diff'ler ve daha az acil düzeltme. Ekiplerin her zaman her tarihi kenar durumu hatırlayan “kahraman” geliştiricilere ihtiyacı yoktur. Bunun yerine sistem normal insan dikkat sürelerini destekler.\n\n### Kural: daha az özel durum, daha az sürpriz\n\nPratik bir test: sürekli “istisna ekliyorsanız” (“ama…”, “istisna olduğunda…”, “sadece şu müşteri için…”) muhtemelen kazara karmaşıklık biriktiriyorsunuz. Davranışta dallanmayı azaltan çözümleri tercih edin—bir tutarlı kural, ilk düşündüğünüzden biraz daha genel olsa bile beş özel durumdan iyidir.\n\n## Yapısal Programlama: Güvenebileceğiniz Net Kontrol Akışı\n\nYapısal programlama, yürütme yolunun takip edilmesini kolaylaştıracak şekilde kod yazmaktır. Düz Türkçeyle, çoğu program üç yapı taşı kullanılarak inşa edilebilir—sıra, seçim ve tekrar—karışık atlamalara güvenmeden.\n\n### Üç yapı taşı (insan dilinde)\n\n- Sıra: adım A'yı yap, sonra B'yi yap, sonra C'yi yap.\n- Seçim: bir koşula göre yol seç (ör. if/else, switch).\n- Tekrar: bir koşul doğru olduğu sürece bir adım kümesini tekrarla (ör. for, while).\n\nBu yapılar kullanıldığında genellikle dosya boyunca yukarıdan aşağıyı okuyarak programın ne yaptığını açıklayabilirsiniz; dosyada “teleport” etmeye gerek kalmaz.\n\n### Öncesi: makarna gibi yürütme yolları\n\nYapısal programlama norm hâline gelmeden önce birçok kod tabanı keyfi atlamalara (klasik goto tarzı) dayanıyordu. Sorun atlamaların her zaman kötü olması değil; kısıtlanmamış atlamaların yürütme yollarını tahmin edilemez hâle getirmesidir. Sonunda “Buraya nasıl geldik?” ve “Bu değişken hangi durumda?” gibi soruları sorarsınız—kod açıkça cevap vermez.\n\n### Neden açıklık gerçek ekipler için önemli\n\nNet kontrol akışı insanların doğru zihinsel modeli kurmasını sağlar. Hata ayıklarken, bir pull requesti incelerken veya zaman baskısı altındayken davranışı değiştirirken bu modele güvenirsiniz.\n\nYapı tutarlı olduğunda, değişiklik daha güvenli olur: bir dalı değiştirirken diğerini istemeden etkilemezsiniz veya bir döngüyü refaktör ederken gizli çıkış yollarını kaçırmazsınız. Okunabilirlik sadece estetik değil—çalışan davranışı güvenle değiştirebilmenin temelidir.\n\n## Akıl Yürütme Araçları: İnvariantlar, Önkoşullar ve Sonkoşullar\n\nDijkstra basit bir fikir ileri sürdü: Kodunuzun neden doğru olduğunu açıklayabiliyorsanız, onu daha az korkuyla değiştirebilirsiniz. Üç küçük akıl yürütme aracı bunu pratik hale getirir—ekibinizi matematikçi yapmadan.\n\n### İnvariantlar: “doğru kalan gerçekler”\n\nBir invariant, özellikle bir döngü içinde, bir kod parçası çalışırken doğru kalan bir gerçektir.\n\nÖrnek: bir sepetindeki fiyatları topluyorsunuz. Faydalı bir invariant: “total şimdiye kadar işlenen tüm öğelerin toplamına eşittir.” Bu her adımda doğru kalırsa, döngü bittiğinde sonuç güvenilirdir.\n\nInvariantlar güçlüdür çünkü dikkatini ne asla bozulmamalı üzerine yoğunlaştırır, sadece bir sonraki adımda ne olması gerektiğine değil.\n\n### Önkoşullar ve sonkoşullar: günlük sözleşmeler\n\nBir önkoşul bir fonksiyon çalışmadan önce doğru olması gereken şeydir. Bir sonkoşul fonksiyon bittikten sonra garanti ettiği şeydir.\n\nGünlük örnekler:\n\n- Önkoşul: “Hesabınızda yeterli bakiye varsa para çekebilirsiniz.”\n- Sonkoşul: “Çekimden sonra bakiye tam olarak o miktar azalır ve asla negatif olmaz.”\n\nKodda bir önkoşul “girdi listesi sıralıdır” olabilir ve sonkoşul “çıktı listesi sıralıdır ve aynı elemanları içerir, artı eklenen öğe” olabilir.\n\n### Bunları yazmanın kodlama ve incelemeleri nasıl değiştirdiği\n\nBunları (gündelik şekilde bile) yazdığınızda, tasarım keskinleşir: bir fonksiyonun ne beklediğine ve ne vaat ettiğine karar verirsiniz ve doğal olarak onu daha küçük ve odaklı yaparsınız.\n\nİncelemelerde tartışmayı stil üzerinden (“Ben bunu farklı yazardım”) doğruluk üzerinden (“Bu invariant korunuyor mu?” “Önkoşulu uyguluyor muyuz yoksa belgeliyor muyuz?”) kaydırır.\n\n### Hafif uygulama: hataların sık olduğu yerlerde yorum yazın\n\nFormal ispatlara gerek yok. En hatalı döngüyü veya en karmaşık durum güncellemesini seçin ve üzerine bir satırlık invariant yorumu ekleyin. Birisi daha sonra kodu düzenlediğinde, bu yorum bir korkuluk gibi davranır: eğer bir değişiklik bu gerçeği bozuluyorsa, kod artık güvenli değildir.\n\n## Test Etme vs Akıl Yürütme: Her Birinin Neyi Garanti Ettiği\n\nTestler ve akıl yürütme aynı hedefe—ise yarar şekilde davranan yazılıma—uygunsa da farklı çalışırlar. Testler örnekler deneyerek sorunları keşfeder. Akıl yürütme mantığı açık hale getirerek bütün kategori hatalarını önler.\n\n### Testlerin çok iyi olduğu noktalar\n\nTestler pratik bir emniyet ağıdır. Regresyonları yakalar, gerçek dünya senaryolarını doğrular ve beklenen davranışı tüm ekipçe çalıştırılabilir şekilde belgelendirir.\n\nAma testler yalnızca hataların varlığını gösterebilir, yokluğunu değil. Hiçbir test paketi her girdiyi, her zamanlama varyasyonunu veya özellikler arası tüm etkileşimleri kapsayamaz. Birçok “makinemde çalışıyor” hatası test edilmemiş kombinasyonlardan gelir: nadir bir girdi, belirli bir işlem sırası veya birkaç adım sonra ortaya çıkan ince bir durum.\n\n### Akıl yürütmenin neleri garanti edebileceği (ve neleri edemeyeceği)\n\nAkıl yürütme kodun özelliklerini ispatlamakla ilgilidir: “bu döngü her zaman sonlanır”, “bu değişken asla negatif olmaz”, “bu fonksiyon asla geçersiz bir nesne döndürmez.” İyi yapıldığında, sınırlarla ve kenar durumlarla ilgili bütün sınıfları dışlar.\n\nSınırlama çaba ve kapsamdır. Tüm ürün için tam formal ispatlar nadiren ekonomiktir. Akıl yürütme, çekirdek algoritmalar, güvenlik kritik akışlar, para/billing mantığı ve eşzamanlılık gibi seçici olarak uygulandığında en iyi sonuç verir.\n\n### Ölçeklenen dengeli yaklaşım\n\nGeniş ölçekte testleri kullanın ve başarının maliyetli olduğu yerlerde daha derin akıl yürütme uygulayın.\n\nİki yaklaşımı birbirine bağlayan pratik bir yol, niyeti çalıştırılabilir hâle getirmektir:

• Assertion'lar iç varsayımlar için (ör. “index aralıkta olsun”).
• Önkoşullar ve sonkoşullar (sözleşmeler) fonksiyon girdileri/çıktıları için.
• İnvariantlar kalıcı gerçekler için (ör. “sepet toplamı öğelerin toplamına eşittir”).

Bu teknikler testlerin yerini almaz—onları sıkılaştırır. Belirsiz beklentileri kontrol edilebilir kurallara çevirir, böylece hatalar yazmayı zorlaştırır ve teşhis etmeyi kolaylaştırır.\n\n## Disiplin: Takımlar “Zekice” Borçtan Nasıl Kaçar\n\n“Zekice” kod anlık olarak kazanım gibi gelir: daha az satır, hoş bir numara, sizi akıllı hissettiren bir tek satır. Sorun şu ki, zekice çözümler zaman veya kişiler arasında ölçeklenmez. Altı ay sonra yazar numarayı unutur. Yeni bir ekip üyesi onu literal okur, gizli varsayımı kaçırır ve davranışı bozan bir değişiklik yapar. Bu “zekice borç”: kısa vadeli hız karşılığında uzun vadeli kafa karışıklığı.\n\n### Disiplin bir ekip hızlandırıcısıdır\n\nDijkstra’nın noktası “sıkıcı kod yazın” demek değildi—disiplinli kısıtların programları akıl yürütmesi daha kolay hale getirdiğiydi. Bir ekipte kısıtlar karar yorgunluğunu da azaltır. Eğer herkes varsayılanları zaten biliyorsa (isimlendirme, fonksiyon yapısı, “tamamlanmış” olma kriteri), her pull requestte temel konuları yeniden tartışmayı bırakırsınız. O zaman o zaman ürüne döner.\n\nDisiplin şu rutin pratiklerde görünür:\n\n- açıklığı yeniliğe tercih eder (“Biri bunu güvenle değiştirebilir mi?”).\n- (format, isimlendirme, hata yönetimi) kod tabanının tek bir ses gibi okunmasını sağlar.\n- bakım olarak görülür, kurtarma görevleri olarak değil—küçük temizlikler sürekli yapılır.\n\n### Koda disiplinin yansıması nasıl görünür\n\nBirkaç somut alışkanlık zekice borcun birikmesini önler:\n\n- tek bir işi yapar, belli girdiler ve çıktılar vardır.\n- niyeti açıklar ( yerine).\n- global değişkenleri ve şaşırtıcı yan etkileri azaltın; bağımlılıkları açıkça iletin.\n- ince sıralama, sihirli değerler veya “triki bilince çalışır” mantığından kaçının.\n\nDisiplin mükemmellik değil—sonraki değişikliği öngörülebilir kılmaktır.\n\n## Modülerlik ve Sınırlar: Değişikliği Yerel Tutmak\n\nModülerlik sadece “kodu dosyalara bölmek” değildir. Kararları net sınırların arkasına izole etmektir, böylece geri kalan sistem iç detayları bilmek zorunda kalmaz. Bir modül karmaşık parçaları—veri yapıları, kenar durumlar, performans numaraları—örtülerken küçük, stabil bir yüzeye sahip olur.\n\n### Modüller patlama yarıçapını nasıl küçültür\n\nBir değişiklik isteği geldiğinde ideal sonuç şudur: bir modül değişir ve diğer her şey dokunulmadan kalır. Bu, “değişikliği yerel tutmak”ın pratik anlamıdır. Sınırlar yanlış bağımlılığı (güncellemenin gizlice üç diğer şeyi bozması) önler.\n\nİyi bir sınır aynı zamanda akıl yürütmeyi kolaylaştırır. Bir modülün neyi garanti ettiğini ifade edebiliyorsanız, her seferinde tüm uygulamayı yeniden okumadan daha büyük program hakkında akıl yürütebilirsiniz.\n\n### Arayüzler birer vaat gibidir (ve paralel çalışmayı nasıl sağlarlar)\n\nArayüz bir vaattir: “Bu girdiler verildiğinde, bu çıktıları üreteceğim ve bu kuralları koruyacağım.” Bu vaat açık olduğunda ekipler paralel çalışabilir: