Beni Şekillendiren Yazılım Denemeleri

 (refactoringenglish.com)
74 puan yazan GN⁺ 2025-10-02 | 3 yorum | WhatsApp'ta paylaş
  • 20 yıl boyunca binlerce yazılım blog yazısı okudum, ancak yalnızca çok az sayıdaki deneme düşünme biçimimi kökten değiştirdi; Joel Spolsky’nin "Joel Test"inden Julia Evans’ın saf JavaScript savunusuna kadar 10 temel deneme tanıtılıyor
  • Joel Spolsky’nin "Joel Test"i, işverenin geliştiricilere saygı duyup duymadığını değerlendirmek için 12 soru sunuyor; kaynak kontrolü, günlük build alma, bug’ları önce düzeltme gibi pratiklerle geliştiricinin zamanına ve odağına öncelik verilip verilmediğini ölçüyor
  • Alexis King’in "Parse, don't validate" yazısı, veri doğrularken onu yeni bir tipe dönüştürme tekniğini tanıtarak tip sisteminin uygulama güvenliği ve güvenilirliğini artırmaya nasıl katkı sağlayabileceğini gösteriyor
  • Fred Brooks’un "No Silver Bullet" yazısı, yazılım işini özsel karmaşıklık ve rastlantısal karmaşıklık olarak ayırıyor ve araçlar ile donanımdaki ilerlemenin 10 kat üretkenlik artışı sağlayamayacağını savunuyor; ancak yapay zeka bu kurama yeni bir değişken ekliyor
  • Julia Evans’ın saf JavaScript denemesi, framework olmadan da yalnızca ES2018 JavaScript’in yeterli olduğu farkındalığını verdi; bunun ardından 2020’den beri hiçbir projeye JavaScript framework’ü ya da build adımı eklenmedi

Joel Spolsky’nin "Joel Test"i (2000)

  • Joel Spolsky gelmiş geçmiş en iyi yazılım blog yazarlarından biri ve denemeleri yazarın yazılıma yaklaşımını derinden etkiledi
  • "Joel Test", bir işverenin yazılım ekibine ne kadar iyi yatırım yaptığını değerlendiren 12 soruluk bir set

  • 12 soru listesi

    • Kaynak kontrolü kullanılıyor mu?
    • Tek adımda build alınabiliyor mu?
    • Her gün build alınıyor mu?
    • Bir bug veritabanı var mı?
    • Yeni kod yazmadan önce bug’lar düzeltiliyor mu?
    • Güncel bir takvim/plân var mı?
    • Spesifikasyon var mı?
    • Programcıların sessiz bir çalışma ortamı var mı?
    • Parayla alınabilecek en iyi araçlar kullanılıyor mu?
    • Testçi var mı?
    • Yeni adaylar mülakatta kod yazıyor mu?
    • Koridor kullanılabilirlik testi yapılıyor mu?

  • Temel mesaj

    • Bazı sorular artık eskimiş olsa da, önemli olan soruların kendisi değil arkasındaki meta nokta
    • Joel’in aslında sorduğu şey şu: Geliştiricilere saygı duyuyor musunuz?
    • Tüm sorular, işverenin ucuz ofis alanı ve kısa vadeli teslim tarihleri yerine geliştiricinin zamanına ve odağına öncelik verip vermediğini ölçüyor
    • Yazı, dot-com patlamasının zirvesinde yayımlandı; yetenekli geliştiriciler değerli bir kaynaktı ama herkes bunun farkında değildi
    • Joel’in blogu programcıları her zaman nadir ve hassas dahiler olarak sunuyor; işverenlerin peşinden koşması ve kıymetini bilmesi gereken kişiler olarak resmediyor
    • Yazar, kariyeri boyunca Joel Test’te yüksek puan alan işverenler aradı ve bu rehberliği sunduğu için Joel’e minnettar

Alexis King’in "Parse, don't validate" yazısı (2019)

  • Haskell’in tip sistemini kullanmaya dair bir deneme olsa da, tip sistemleriyle ya da Haskell’le ilgilenmeseniz bile yazılım hakkında düşünme biçimini kökten değiştiriyor
  • Alexis’in tekniği Go, C++, Rust gibi statik tip desteği olan her dilde kullanılabiliyor

  • Temel kavram

    • Veriyi her doğruladığınızda onu yeni bir tipe dönüştürmeniz gerekir
    • Örnek: kullanıcı adını en fazla 20 alfanümerik karakterle sınırlayan bir kural varsa, saf çözüm validateUsername(username string) error fonksiyonudur

  • Sorun

    • Kod varsayılan olarak güvenli değildir
    • Gelen her kullanıcı adını doğrulamak gerektiği için, yanlışlıkla doğrulanmamış bir kullanıcı adını işleyen bir kod yolu oluşturmak kolaydır
    • Kötü niyetli bir kullanıcı bu hatayı fark ederse kullanıcı adı alanına zararlı kod ekleyebilir ya da milyarlarca karakter girerek sunucu kaynaklarını tüketebilir

  • Alexis’in çözümü

    • parseUsername(raw string) (Username, error) fonksiyonunu kullanmak
    • Kod tabanının geri kalanında "username" için string yerine özel Username tipi kullanmak
    • Username üretebilen tek fonksiyon parseUsername olur; bu fonksiyon, Username örneği döndürmeden önce doğrulama kurallarını uygular
    • Elinizde bir Username örneği varsa, bunun geçerli bir kullanıcı adı içerdiği varsayılabilir
    • Güvenilmeyen girdi her zaman string olduğundan, Username bekleyen bir fonksiyona string veremezsiniz

  • Etkisi

    • Bu denemeden önce tip sistemlerinin dil meraklılarını oyalayan eğlenceli bir şey olduğunu düşünüyordum
    • "Parse, don't validate", derleyici özelliklerinin uygulama güvenliği ve güvenilirliğini artırmada ne kadar değerli olduğunu görmemi sağladı

Fred Brooks’un "No Silver Bullet" yazısı (1986)

  • Üniversitede Fred Brooks’un The Mythical Man-Month kitabını okudum
  • Kitap, IBM’in OS/360 projesini yönetme deneyimine dayanan yazılım mühendisliği denemelerinden oluşuyor

  • Özsel karmaşıklık ve rastlantısal karmaşıklık

    • Özsel karmaşıklık: araçlardan ve donanımdan bağımsız olarak mutlaka yapılması gereken işler
      • Örnek: satış çalışanlarının primlerini hesaplayan bir yazılımda prim formülünü tanımlamak ve tüm edge case’leri kapsamak
      • İster 5 milyar dolarlık bir süper bilgisayar ister 1 dolarlık bir mikrodenetleyici olsun, yapılacak iş aynıdır
    • Rastlantısal karmaşıklık: bunun dışındaki her şey
      • Bellek sızıntılarıyla uğraşmak, kodun derlenmesini beklemek, üçüncü taraf kütüphanelerin nasıl kullanılacağını anlamak
      • Araçlar ve donanım kaynakları ne kadar iyiyse, rastlantısal karmaşıklığa harcanan süre o kadar azalır

  • Brooks’un sonucu

    • Araçlar veya donanımdaki ilerlemelerin geliştirici üretkenliğinde 10 kat artış yaratması imkânsızdır
    • Rastlantısal faaliyetlerin tümünü sıfır zamana indirseniz bile, toplam emeğin 10’da 9’undan fazlasını oluşturmuyorlarsa bu ölçekte bir artış mümkün değildir

  • Uygulama örnekleri

    • Kariyerim boyunca insanlar yazılımın içinden programcıları çıkarmaya çalıştı
    • No-code platformları, programcı olmayanlara deneyimli bir web geliştiricinin tüm gücünü vaat ederek gündem oldu
    • Brooks’un denemesi, en yeni buzzword platformlarının geliştiricilerin yerini alamayacağı konusunda bana hep güven verdi
    • Bu platformlar özsel karmaşıklığa değil, rastlantısal karmaşıklığa odaklanır
    • Platform işlev spesifikasyonundan sihirli biçimde çalışan kod üretebilse bile, yine de o spesifikasyonu yazacak birine ihtiyaç vardır

  • Yapay zekanın etkisi

    • Modern yapay zeka, Brooks’un kuramına adeta bir İngiliz anahtarı fırlatıyor
    • Yapay zeka gerçekten de özsel karmaşıklığı azaltıyor
    • Eksik ya da çelişkili spesifikasyonları yapay zekaya verdiğinizde, yapay zeka benzer spesifikasyonlardan ödünç alarak boşlukları dolduruyor
    • Yapay zeka bilinen programlamayı ortadan kaldırsa bile, Brooks’un denemesi eninde sonunda herhangi bir soyutlama seviyesinde özsel karmaşıklığı yönetecek birine hâlâ ihtiyaç olacağı umudunu veriyor

Joel Spolsky’nin "Choices" yazısı (2000)

  • En sevdiğim Joel Spolsky denemesini yalnızca bir tane seçmek zor olduğu için iki tane seçtim
  • "Choices", kullanıcı arayüzü oluşturmanın ve kullanıcıya yetki vermenin ince maliyeti üzerine

  • Temel mesaj

    • Her seçenek sunduğunuzda kullanıcıdan bir karar vermesini istemiş olursunuz
    • Bu, kullanıcının bir şey hakkında düşünmesi ve karar vermesi gerektiği anlamına gelir
    • Bu mutlaka kötü değildir, ancak genel olarak insanların vermek zorunda olduğu karar sayısını en aza indirmeye çalışmalıyız

  • Windows 98 örneği

    • Joel, Windows 98’de yardım belgelerinde arama yaparken çıkan saçma bir iletişim kutusunu paylaşıyor
    • Joel’i öfkelendiren şeyler şunlar:
      • Kullanıcı yardım almaya çalışırken süreci kesmesi
      • Veritabanı optimizasyonu hakkında bilgiye dayanmayan bir karar vermesini istemesi
      • Windows’un karardan kaçınıp bunu kullanıcıya yıkması

  • Uygulama kapsamı

    • Joel’in denemesi grafik kullanıcı arayüzlerine odaklansa da, yazar bunu komut satırı ya da yazdığı fonksiyonları çağıran başka geliştiriciler dâhil kodun karşısına çıkabildiği her yerde dikkate alıyor
    • Kullanıcı adına faydalı kararlar verip veremeyeceğinizi, ama aynı zamanda önemsedikleri konularda onlara yetki sağlayıp sağlayamayacağınızı düşünün
    • Joel’in denemesi, benim verebileceğim kararları kullanıcıya yıkmamı sayısız kez engelledi

Raymond Chen’in “Application compatibility layers are there for the customer, not for the program” (2010)

  • Raymond Chen, Microsoft Windows ekibinde en uzun süre görev yapmış geliştiricilerden biri
  • Blogunda Windows programlama tarihine dair binlerce faydalı ve eğlenceli hikâye var

  • Müşteri talebi örneği

    • Windows Vista uyumluluk modu hakkında bir müşteri talebi:
      • Windows XP ve Windows Server 2003 için tasarlanan bir program, Windows Vista’da sorun yaşıyor
      • Windows XP uyumluluk moduna ayarlandığında Vista’da düzgün çalışıyor
      • Vista’da çalıştırıldığında otomatik olarak XP uyumluluk modunda çalışması için yükleyicide hangi değişikliklerin gerektiğini soruyor

  • Raymond’un benzetmesi

    • "Ben genelde evcil hayvan dükkânının önündeki kaldırıma çöp atarım ve dükkân her sabah açıldığında biri gelip çöpleri süpürüp çöp kutusuna atar. Ama evcil hayvan dükkânı pazar günleri açık değil, bu yüzden pazar günleri çöp öylece orada kalıyor. Pazar günleri de evcil hayvan dükkânını nasıl açtırabilirim?"

  • Ders

    • Benzetme o kadar komik ki Raymond’un haksız olduğunu ancak şimdi fark ettim
    • Tek bir sürümden sonra Windows’un uygulamaları bozmayacağını bekleyen geliştiricinin günahını tiye alıyor
    • Ayrıntılara katılmasam da Raymond’un yazısı o kadar komik ve keskin ki kusurlarını aşabiliyor
    • Harika bir kullanıcı davranışını etkileme dersi:
      • Kullanıcıyı size yardımcı olacak bir şeyi yapmaya yönlendirmek istiyorsanız, kullanıcı açısından en az dirençli yolu dikkatle düşünmeniz gerekir
      • Kaldırıma çöp atmanın sorunu tamamen çözdüğünü gösterirseniz, bunu yapmaya devam ederler

Erik Kuefler’in “Don’t Put Logic in Tests” (2014)

  • Yazar her zaman birim testleri sevdi ve test koduyla büyük gurur duydu
  • Bu deneme adeta banyoda karşısına çıkıp kariyeri boyunca korkunç testler yazdığını ifşa ederek onu şoke etti

  • Sorunlu test örneği

    @Test public void shouldNavigateToPhotosPage() {  
  String baseUrl = "http://plus.google.com/";;  
  Navigator nav = new Navigator(baseUrl);  
  nav.goToPhotosPage();  
  assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());  
}

  • Fark edilen sorunlar

    • Denemeyi ilk okuduğunda, "Ben de birim testlerini tam olarak böyle yazıyorum!" diye düşündü
    • Neden http://plus.google.com/ dizesi iki yerde tekrar ediliyor? Production kodundaki gibi tek bir doğru kaynak oluşturmuş
    • Yazar, testlerde tekrarları kaldırmak için helper fonksiyonlar, değişkenler ve döngüler eklemeyi hep yaptı
    • Sorun şu ki bu yaklaşım ince hataları gizliyor: gerçekte http://plus.google.com//u/0/photos için assert ediyor (çift slash)

  • Farkındalık

    • Erik’in denemesi, test koduna production kodu gibi davranmamak gerektiğini gösteriyor
    • Bu ikisinin hedefleri ve kısıtları tamamen farklı
    • İyi test kodu her şeyden önce açık olmalı
    • Test kodunun kendisini test eden ayrı bir test kodu olmadığı için, doğruluğunu doğrulamanın tek yolu incelemektir
    • Testler, hangi davranışı assert ettiğini okuyucuya göz çıkarırcasına açık göstermeli
    • Bu amaç uğruna karmaşıklığı azaltmak için tekrar kabul edilebilir

Julia Evans’ın “A little bit of plain Javascript can do a lot” (2020)

  • Bir yazılım mühendisi olarak web’e utanç verici derecede geç girdi
  • Kariyerinin ilk 10 yılında yalnızca masaüstü uygulamaları ve backend sunucuları için kod yazdı
  • 2017’ye kadar HTML veya JavaScript’i umursamadı

  • Framework’ler hakkındaki yanlış kanı

    • Frontend geliştirmeyi ciddi biçimde öğrenmeye başladığında, JavaScript’in 10 günde yazılmış dağınık bir dil olduğu ve tarayıcıdan tarayıcıya çok farklı davrandığı izlenimine sahipti
    • Web uygulamaları yazmak için JavaScript’in tüm saçmalıklarından ve kusurlarından koruyan modern ve zarif bir şeye ihtiyaç vardı
    • Angular, React, Vue gibi popüler web framework’lerini denedi
    • Vue’yu yeterince öğrendi ama yine de bağımlılık sorunları ve framework tuzakları yüzünden çok zaman harcadı
    • Tüm bu frontend framework’lerinin JavaScript’i düzeltmek için yaptıklarından sonra bile web programlama hâlâ berbattı

  • Julia’nın denemesinin sağladığı farkındalık

    • JavaScript’in düzeltilmesi gerektiğine o kadar emindi ki ona hiç şans vermediğini fark etti
    • TinyPilot prototipi üzerinde çalışıyordu ve web arayüzünü Vue ile kurmayı planlıyordu
    • Julia’nın denemesi, sade JavaScript ile ne kadar ileri gidilebileceğini görmesi için ona ilham verdi
    • Framework, wrapper kütüphanesi, build step ya da Node.js olmadan, yalnızca düz JavaScript (ES2018) kullandı
    • Sürekli framework ya da builder’a geçmeyi gerektirecek bir sorunla karşılaşmayı bekledi ama bu hiç olmadı
    • WebComponents ile ilgili birkaç tuzak vardı ama Vue ve Angular ile yaşadığı acının yanında hiçbir şeydi

  • Framework’süz özgürlük

    • Framework’lerden kurtulmayı sevdi
    • Runtime hatası olduğunda, stack trace küçültülmüş, dönüştürülmüş ve tree-shake edilmiş kodun ateşli kâbusu olmuyor
    • Kendi kodunu yazdığı haliyle debug etmek
    • JavaScript hakkındaki önyargısı yanlıştı
    • Modern JavaScript oldukça iyi ve wrapper kütüphanelerindeki birçok fikri içine almış durumda; artık wrapper’a ihtiyaç yok
    • Tarayıcılar, platformlar ve cihazlar arasında tutarlı davranışı garanti etmek için nihayet kendine çeki düzen verdi
    • 2020’den beri hiçbir yeni projeye JavaScript framework’ü ya da build step eklemedi ve buna hiç dönüp bakmadı
    • Sade JavaScript ile framework faydalarının %90’ını, sıkıntının %5’iyle elde ediyor

Dan McKinley’nin “Choose Boring Technology” (2015)

  • Bu listede yer alması tuhaf bir deneme, çünkü aslında onu hiç okumadı
  • İnsanlar bu denemeye atıf yaptı ve fikri anlayınca o kadar sezgisel geldi ki okuma ihtiyacı hissetmedi

  • Temel fikir

    • Yeni bir proje başlatırken çok konuşulan en son teknolojiyi kullanma cazibesi vardır
    • Google, exabyte ölçeğine kadar büyüyen yeni bir veritabanı duyurdu; Postgres’ten %40 daha hızlı ve maliyeti %20
    • Bu çekici yeni alternatif ortadayken Postgres kullanmak aptallık gibi görünür
    • Gerçekte yeni teknolojilerin hataları ve zayıflıkları vardır ama bunlar henüz görünür değildir
    • Bunlara çarptığınızda ne yapacağınızı bilemezsiniz
    • Postgres’in sorunları vardır ama 30 yıllık saha deneyiminin ardından karşılaşmanız muhtemel her sorun için kanıtlanmış çözümlere sahiptir

  • Yenilik jetonu kavramı

    • Dan bazen yeni teknoloji kullanmak gerektiğini kabul ediyor, ama yalnızca stratejik olarak ve sınırlı sayıda
    • Her işletme harcamak üzere üç adet "yenilik jetonu" alır
    • Gösterişli yeni veritabanını istiyorsanız, jetonlardan birini harcamalısınız
    • Dan’in denemesi Julia’nın denemesiyle doğal biçimde örtüşüyor
    • Frontend framework’lerinde onca zamanı boşa harcamadan önce keşke bunlardan en az birini okusaydım

Terence Eden’ın “I’ve locked myself out of my digital life” (2022)

  • Terence Eden neşeli ve eklektik bir teknoloji blog yazarıdır
  • Her hafta birçok yeni yazı yazıyor, ancak en büyük etkiyi yaratan yazısı "dijital hayatımın dışında kendimi kilitledim" oldu

  • Felaket senaryosu

    • Yıldırım Terence'in evine çarpıp tüm eşyalarını yok ederse ne olacağını simüle ediyor
    • Her şeyin parolasını parola yöneticisinde saklıyor
    • Tüm cihazlar yok olursa parola yöneticisine erişmek imkansız hale geliyor
    • Donanım passkey'leriyle değiştirilememesinin nedeni, onların da evde olmasıydı

  • Farkındalık

    • Yazar, her şeyi yedekli sürücülerde sakladığı ve iki sağlayıcıyla üç kıtada site dışı yedekleri olduğu için verileri konusunda oldukça güvende hissediyordu
    • Terence'in yazısı, tüm cihazları aynı anda ortadan kaldırabilecek pek çok inandırıcı tehdidi düşündürdü: yangın, sel, elektrik dalgalanması, adli soruşturma
    • Tüm veriler zihindeki parolayla şifrelendiğinden, hafıza kaybı, iş göremezlik ve ölüm de listeye ekleniyor

  • Çevrimiçi hizmetlerin sorunu

    • Çevrimiçi hizmetler, kullanıcının bir felaketten kurtulmasına yardımcı olma konusunda zayıf kalıyor
    • Telefonunu kaybetmenin imkansız olduğunu varsayan pek çok hizmet kullanıyoruz; e-posta hesabını ve sahip olunan tüm dijital cihazları saymıyorum bile

  • Etki

    • Terence'in denemesini okuduktan sonra hangi hizmet ve cihazların kritik olduğunu, Terence'in anlattığı senaryoda bunlardan nasıl kurtulabileceğimi daha çok düşünür oldum
    • Bir sonraki dizüstü bilgisayarımı aldığımda onu kütüphanede kurup, evdeki cihazlar olmadan parola yöneticisine ve önemli hesaplara erişimi geri kazanıp kazanamayacağımı test ettim
    • Hâlâ dijital felaket hazırlığı konusunda daha iyi olabilirim, ama Terence'in yazısı cihazlarımı ve verilerimi nasıl güvenceye alacağımı her düşündüğümde zihnimde yankılanıyor
    • Her şey bir anda yok olsaydı ne olurdu?

Bonus: Brad Fitzpatrick'in "parsing user input" yazısı (2009)

  • Teknik olarak bir deneme değil, ama yazılım röportajından bir alıntıyı durmadan düşünüyorum
  • 2009'da Joel Spolsky'nin çok övdüğü incelemenin ardından Coders at Work'ü okudum
  • Başarılı programcılarla yapılmış röportajlardan oluşan bir derleme

  • Brad Fitzpatrick'ten ünlü söz

    • LiveJournal ve Memcached'in kurucusu Brad Fitzpatrick, röportaj yapılan isimlerden biri olarak yer alıyor
    • O sırada 28 yaşındaydı; kitaptaki en genç programcıydı, ayrıca en küfürbaz ve en komik olanıydı
    • Yazılım mühendisliği etiğiyle ilgili bir soruya verdiği girdi doğrulama üzerine ateşli çıkışı:
      • "Herkesten kredi kartı formuna boşluk ya da tire girmeye tutarlı biçimde izin vermelerini rica etmek isterim. Bilgisayarlar bunları ayıklamakta iyidir. Sayılarımı nasıl biçimlendireceğimi bana söylemeyin."

  • Uygulama

    • Bir web formuna telefon numarası yapıştırmaya çalıştığım her seferinde bu alıntıyı hatırlıyorum
    • Parantez veya boşluğa izin verilmediği için söyleniyorum; daha kötüsü, bazen telefon numarasını parantez yüzünden kesip sonra da paranteze izin verilmediğinden şikayet ediyor
    • Yazılımda bir giriş alanı oluşturup beklenmedik karakterleri düşündüğüm her seferinde Brad Fitzpatrick'in "Bilgisayarlar bunları ayıklamakta iyidir" dediğini duyuyorum

İlgili okumalar

3 yorum

 
shakespeares 2025-10-07

Geçmiş olduğu için bugün var.
 
GN⁺ 2025-10-02
Hacker News görüşleri

  • "I've locked myself out of my digital life" yazısını okuduktan sonra, sahip olduğum ama ifade etmekte zorlandığım kaygıyı çok iyi anlattığını hissettim
    Analog dünyada kim olduğumu insanlara anlatarak kimliğimi doğrulatıp hesabıma erişebilirim, ama dijital dünyanın acımasız algoritmaları karşısında kimlik bilgilerim yoksa ne kadar yalvarsam da faydası olmaz
    Hatta parola yöneticisi hizmetimi sağlayan şirketin bile parolalarıma erişim yetkisi yok
    İkna edilecek kimse bile yok; yalnızca kod kanun haline geliyor
    Her süreçte yüz yüze aşamaları kaldırmayı savunmadan önce herkesin bu sorunu anlaması gerektiğini düşünüyorum
    Yazıda nadir bir durum gibi gelebilir ama doğal afet veya hırsızlık gibi durumlarda da gayet yaşanabilecek bir şey
    İlgili yazı: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/

    • Bu tür aşırı otomasyonu veya yüz yüze temasın azaltılmasını gerçekten savunan çok kişi olduğunu sanmıyorum
      Ayrıca bu sorun yalnızca yapay zekaya özgü değil; kural tabanlı yazılımlar için de geçerli
      Avrupa Birliği'nde (AB), herhangi bir karara karşı mutlaka bir insana itiraz etme hakkı yasa ile güvence altında

  • Grug Brained Developer hep aklımda kalan bir yazı oldu ama listede yoktu
    Aslında zaten katıldığım şeyleri söylediği için, düşüncemi dönüştürmesinden çok akılda kalmış olabilir
    Referans: https://grugbrain.dev/

    • Bunların içinde özellikle karmaşıklık şeytanını sonunda düzeltilmiş kristalin içine hapsetmenin en iyi his olduğu kısmını gerçekten çok sevdim

    • İngilizceyi ikinci dil olarak kullanan iki dilli biriyim; bu yüzden grug brain tarzı yazıları okumak ve anlamak epey zor geliyor
      grug kelimesinin ne anlama geldiğini de bilmiyorum
      Yine de blogu keyifle okumaya devam ediyorum

  • Fred Brooks'un "No Silver Bullet" hakkındaki sonucuna katılmıyorum
    Son dönemde yapay zekanın Brooks'un tezini çürütecek kadar özsel karmaşıklığı azalttığı iddiasına katılmıyorum
    Yapay zeka eksik ya da çelişkili spesifikasyonları benzer örneklerden yararlanarak otomatik doldurabilir, ama özsel karmaşıklık hâlâ yapay zeka tarafından yeterince giderilemiyor ve bence gelecekte de giderilemeyecek
    Bununla ilgili ayrıntılı analizim burada: https://smartmic.bearblog.dev/no-ai-silver-bullet/

    • Okuduğun ve yazımı paylaştığın için teşekkürler
      Açıklamanda da belirttiğin gibi, LLM'lerin özsel karmaşıklığı tamamen ortadan kaldıramayacağı konusunda hemfikirim
      Ama LLM'lerin özsel karmaşıklığı belli ölçüde azaltabildiğini düşünüyorum
      Somut bir örnek olarak, Claude 4.1 Opus'tan bilgisayar üretimi çizimler için alan özelinde bir dil tanımlamasını istedim
      Ben yalnızca gereksinimleri verdim ve ayrıntıları muğlak bıraktım ama LLM benim için spesifikasyonu yazdı
      Böyle durumlarda LLM'nin özsel karmaşıklığı azalttığından emin olabiliyorum
      Elbette bunu kendim de yüksek kalitede baştan tanımlayabilirdim, ama LLM'nin çıkardığı sonuç yeterince iyiyse kaliteyi artırmak için ekstra çaba harcamak için daha az neden kalıyor
      Ben normalde kodlamayı daha iyi yaptığımı ve daha çok sevdiğimi düşündüğüm için LLM'lere pek ihtiyaç duymuyordum, ama kullanınca gördüm ki zamanımı ve enerjimi harcamama gerek olmayan kısımlarda LLM özsel karmaşıklığın önemli bir bölümünü üstlenebiliyor
      Örnek: https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1

    • Yapay zekanın azalttığı karmaşıklık sonuçta yalnızca kodu yazan kişinin bilişsel yükü
      Brooks'un sözünü ettiği kaçınılmaz olmayan karmaşıklık (nonessential complexity) kodun kendisinde büyük ölçüde kalmaya devam ediyor
      Sonuç olarak bu yük kodu okuyan kişiye aktarılıyor
      Bu, dış iskeletli bir kıyafet giyip ağır bir şeyi rafa kaldırdıktan sonra ekip arkadaşına dönüp onu güzelce boyamasını söylemek gibi

  • "Parse, don't validate" makalesi bence bir klasik
    Ama "Don't put logic in tests" cümlesine katılmakta zorlandım
    Örnekte sorun, string yerine URI tipinin kullanılmamasından kaynaklanıyor; ben ise test kodunun da dağıtımın başarılı ya da başarısız olmasını etkilediği için üretim kodu sayılması gerektiğini düşünüyorum
    Yine de bu tür tartışmaları bizzat inceleyip kendin için uygulanabilir olup olmadığını düşünmeye kesinlikle değer

    • Bana da "Parse, don't validate"ın çok bilinmiyor olması ilginç geliyor
      Çevremde çoğunlukla Go, Python ve C++ kullanan insanlar var; sanırım yalnızca fonksiyonel dil tarafında ünlü
      "Don't put logic in tests" örneğine yönelik eleştirel bakışın haklı olduğunu düşünüyorum
      Örnek biraz daha iyi bir örnekle değiştirilebilir ama asıl önemli nokta, basit string birleştirmenin bile testlere karmaşıklık ekleyip hataların gözden kaçmasına yol açabilmesi

    • Kişisel olarak testlere çok fazla mantık koymama felsefesini çekici buluyorum
      Test kodundaki hatalar yüzünden birden çok kez false positive yaşadım, bu yüzden bu konuda bir güvensizlik oluştu
      testler için test yazma ihtiyacı hissetmemek gerektiğini düşünüyorum
      Pratikte bu durum nadir, ama son zamanlarda LLM'lerin yazdığı berbat test kodları yaygınlaştığı için bu felsefeden bağımsız olarak sorun büyüyor

  • Nancy Leveson'un Therac-25 kazalarıyla ilgili araştırma ve inceleme materyallerini tavsiye ederim

  • Bu alanda benim en sevdiğim yazı, Neil W. Rickert'in "The Parable of the Two Programmers" yazısı
    Programcının hayatını ve karşılaştığı zorlukları kısa ve öz biçimde özetleyen bir hikâye
    https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html

    • Neil'i, yıllar boyunca comp.ai.philosophy Usenet haber grubunda sık sık etkileşimde bulunduğum için iyi tanıyorum
      Yazının tonu ve içeriği gerçekten tam ona özgü bir tarz taşıyor

    • Bu yazı gerçekten harika

  • Benim için dönüm noktası olan yazı buydu
    https://stevemcconnell.com/articles/software-quality-at-top-speed/

    McConnell burada çok da tanınan biri değil

    • Paylaştığın için teşekkürler!
      Bu yazıyı ilk kez okuyorum; ben kariyerimin başlarında Code Complete'i okumuş ve çok etkilenmiştim
      Kitaplığımda hep durdu ama sadece birkaç kez yeniden göz atarken bile bu gerçekten harika, tekrar mutlaka okumalıyım diye düşündüm
      Bir süredir McConnell hakkında bir şey duymuyordum; Kent Beck, Martin Fowler, Ward Cunningham gibi çağdaşları 2000'lerden sonra popülerlikleri azalsa da yazmayı sürdürürken, McConnell'ın sessiz kalması dikkatimi çekmişti
      Meğer yazılımı bırakıp finansal danışman olmuş; bunu öğrenmek hafiften sarsıcıydı
      https://raindogllc.com/steve-mcconnell-investment-advisor/

  • Tam anlamıyla klasik bir yazılım denemesi sayılmayabilir ama Gilad Bracha'nın "Ban on Imports" blog yazısı modül sistemlerine bakışımı tamamen değiştirdi
    import/export'un aslında global state ile aynı şey olduğunu ve bu yüzden global state'in tüm sorunlarını beraberinde getirdiğini vurguluyor
    O zamandan beri dependency injection kavramına çok daha fazla değer veriyorum
    https://gbracha.blogspot.com/2009/06/ban-on-imports.html

  • Bunu katı biçimde bir yazılım denemesi olarak sınıflandırmak zor olabilir ama Patrick McKenzie'nin "Don't Call Yourself A Programmer, And Other Career Advice" yazısı gerçek bir hazine
    https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

  • Programlama dillerine çok ilgi duyan biri olarak, "slumming with basic programmers" yazısı aklımda çok yer etti
    https://prog21.dadgum.com/21.html
 
secret3056 2025-10-02

Kullanıcı girdisi ayrıştırma konusuna gerçekten katılıyorum.
Alternatif telefon numarası giriş özelliğini geliştiren pek çok kodlayıcı, bir string üzerinde replace() fonksiyonunu iki kez çağırmaktan bu kadar korkacakları nasıl bir ortamda çalışıyor acaba?