Clean Code vs. Yazılım Tasarımı Felsefesi

• Robert “Uncle Bob” Martin ile John Ousterhout arasında 2024 Eylül ile 2025 Şubat arasında yürütülen yazılım tasarımı odaklı bir diyalog
• Her iki isim de yazılım tasarımı üzerine kitaplar yazdı
• Üç ana başlıkta görüş ayrılığı yaşadılar: metot uzunluğu, yorumlar ve Test-Driven Development
• Diyaloğun özü, kodun karmaşıklığını azaltma, okunabilirliği artırma ve testleri uygun biçimde yazma yöntemleri üzerine

Metot uzunluğu

• Uncle Bob (bundan sonra UB), “kısa fonksiyonlar iyidir, mümkünse daha da kısa parçalara ayrılmalıdır” görüşünü vurguluyor
  • Bir metot yalnızca tek bir “iş” (One Thing) yapmalı
  • Ancak bu yaklaşım çok uç noktaya taşınırsa aşırı parçalamaya (over-decomposition) yol açabilir
• John, aşırı küçük metotların bütün akışı anlamayı tersine zorlaştırdığını söylüyor
  • Çok sayıda “sığ” (shallow) metot olduğunda, tek bir işlevi anlamak için ilgili tüm metotlara bakmak gerekebiliyor
  • Metotlar arası karşılıklı bağımlılık (entanglement) artıyor ve bu da kod okuma yükünü büyütüyor
• PrimeGenerator örneği
  • UB’nin orijinal kodu yaklaşık 8 küçük metoda bölünmüştü ve metotlar birbirine dolanmış olduğu için anlaşılması zordu
  • John’un sürümü ise yeterli yorumlarla tek bir metot içinde yazıldı; böylece genel akış tek bakışta görülebiliyor
  • UB de “aşırı parçalama olduğunu” belli ölçüde kabul etti
• Sonuç olarak iki taraf da kodu bölmenin önemli olduğunu kabul ediyor; ancak asıl mesele “çok küçük parçalara ayırmak” ile “çok büyük bırakmak” arasında denge kurmak

Yorumlar

• UB, yorumları “gerekli bir kötülük” (necessary evil) olarak görüyor
  • Yorumların güncel kalmama veya yanlış bilgi içerme riski taşıdığını düşünüyor
  • Niyeti mümkün olduğunca kodla anlatmayı, gerekirse çok uzun isimler kullanmayı tercih ediyor
• John ise yorumların kesinlikle gerekli olduğunu savunuyor
  • Bir arayüzün (metodun) amacı ya da implementasyon niyeti İngilizce olarak açıkça yazılırsa, başka geliştiricilerin gereksiz kod araştırmasına harcadığı zamanı azaltır
  • “En tehlikeli durum, yorum olmadığı için kodu doğrudan yorumlamak zorunda kalmaktır” görüşünde
• PrimeGenerator örneğinde John, “algoritmanın neden böyle çalıştığını” açıklayan yorumlar olmadan kodu anlamanın çok zor olduğunu belirtiyor
• UB, “yorum doğru değilse daha da zararlıdır” derken John, “yanlış yorumdan bile daha zararlı olan şeyin yorumsuzluk olduğunu” düşünüyor
• İkisi de “takıma ve bağlama göre uygun düzeyde yorum yazılması gerektiği” konusunda kısmen uzlaşıyor; ancak genel olarak John, yorumların değerini çok daha yüksek görüyor

John’un PrimeGenerator refactoring’i

• John, başlangıçta 8 metoda bölünmüş kodu tek bir metot ya da 2-3 metotluk bir yapıya dönüştürdü
• Gerekli yerlere zengin yorumlar ekleyerek “neden böyle implement edildiğini” açıkladı
• Yorumlarda temel değişkenlerin (multiples, primes) amacını ve algoritmanın çalışma biçimini birlikte anlatarak kodun daha hızlı anlaşılmasını hedefledi
• UB, bu kodun da tamamen sezgisel olmadığını söyledi
  • Karmaşık algoritmaları açıklamak için yine de zamana ihtiyaç var ve yazarın kendisi de yeniden gözden geçirme sırasında zorluk yaşadı

Bob’un PrimeGenerator2 refactoring’i

• Bu, UB’nin John’un kodunda küçük değişiklikler yaptığı sürüm
• Bazı metotlar ek olarak ayrıştırılarak “sonraki aşama refactoring” uygulandı
  • Döngü bölümünde okunabilirlik artarken, performans geçici olarak düştü
• John, “çok küçük metotlara bölmenin performans sorunlarına yol açabileceğini” vurguladı; UB ise yeniden düzenleyerek performansı iyileştirdi
• Ancak UB’nin “yorumları en aza indirme” tercihi nedeniyle John, hâlâ “daha fazla açıklama eklenirse anlamanın kolaylaşacağı” görüşünü koruyor

Test-Driven Development

• UB, kısa döngülerle önce testi yazıp ardından başarısız testi geçirecek kodu parça parça ekleyen TDD yaklaşımını güçlü biçimde savunuyor
  • Bu yöntemle kodun sürekli test kapsamı altında kaldığını ve karmaşık debugging süreçlerinden kaçınılabileceğini öne sürüyor
  • Sık refactoring ile kodun giderek daha temiz hale geldiğini düşünüyor
• John ise TDD’nin fazlasıyla “taktiksel bir yaklaşıma” kaymasından endişe ediyor
  • “Önce tasarım gelmeli; TDD ise önce kod yazmaya (test için gereken en küçük implementasyona) yönlendiriyor” eleştirisini getiriyor
  • İyi tasarımın daha geniş bir çerçeveyi bir seferde düşünmeyi gerektirdiğini ve ilgili kod için testleri birlikte yazmanın (bundling) daha iyi olabileceğini savunuyor
• UB, “TDD yanlış uygulanırsa sorun çıkabilir” demekle birlikte, doğru uygulandığında test kapsamı ve yeniden tasarım (refactoring) için faydalı olduğunu söylüyor
• John, “özellikle yeni başlayanlar için TDD’nin kodun hızla dağılmasına yol açma riskini artırabileceği” endişesini dile getiriyor
• Sonuçta ikisi de “hem TDD hem de bundling yaklaşımı doğru uygulanırsa harika kodlar üretilebilir” görüşünde birleşiyor; ancak hangisinin daha iyi olduğu konusunda farklı düşünüyorlar

Son söz

• John:
  • “Clean Code”un çok küçük fonksiyonlara bölmeyi ve yorumları bastırmayı fazla vurgulayarak, okurların bunu uç noktalara taşıma riski oluşturduğunu düşünüyor
  • Yeterli yorum olmazsa kodun anlaşılması zorlaşıyor ve sonuçta geliştiriciler daha fazla zaman harcıyor
  • TDD’nin de büyük resmi kaçırmaya neden olabileceğini söylüyor
• UB:
  • “Clean Code”un 2. baskısında bazı düzeltmeler yaptığını ve John’un görüşlerinin bir kısmını dahil ettiğini belirtiyor
  • Farklı deneyim ve bakış açılarına saygı duyarak, sonuçta herkesin temiz ve bakımı kolay kodu hedeflemesi gerektiğini vurguluyor
• Sonuç olarak iki taraf da yazılım tasarımının önemini ve “kodu kolay okunur hale getirmeyi” en yüksek değer olarak görüyor
• Ancak metotları ayırma ölçütü, yorum kullanım biçimi ve test yazım sırası gibi konularda görüş ayrılıkları sürüyor
• Asıl nokta, ekip ortamına ve kod yapısına uygun dengeyi kurmak ve tasarımı sürekli iyileştirmeye çalışmak

[mhj5730]

Clean serisinden birkaç kitabım var ama bence en fazla metabilişsel bir düzeyde referans almak için iyiler. İlke ya da yasa gibi davranınca aşırı yorucu oluyor ve pek de pratik değil. Sürekli SOLID ilkelerinden söz eden Uncle Bob ama... kişisel olarak çok da fazla pratik içerik sunduğunu düşünmüyorum.

[ahwjdekf]

Bence Code Complete ve Clean Code, abartılmış kitaplar sıralamasında ortak birinciliği paylaşıyor.

[carnoxen]

Yazılım Felsefesi'nin çevirisi çıktı mı? Arattım ama bulamadım.

[mageia]

Paradoksal olarak, iyi kodun ne olduğuna dair kitaplardan ziyade, bakımı zor olacak şekilde nasıl kod yazılacağını anlatan ironik bir kitabın daha akılda kalıcı olacağını düşünüyorum.

[aer0700]

Son zamanlarda clean code'dan çok, belirli bir teknoloji yığınına ya da mimariye fanatik biçimde bağlı olup bu teknoloji yığını veya mimari benimsenmezse büyük bir sorun çıkacakmış gibi konuşanlar yüzünden daha fazla tartıştığımızı düşünüyorum. Duruma göre uygulamak gerekir; galiba koşulsuz olarak iyi olan hiçbir şey yok.

[yadameda]

Harika bir tartışma.

[spilist2]

Ben de düşününce, junior'lara John'un philosophy of sw design kitabını öneriyorum ama Clean Code'u pek önermemişim.

[bbulbum]

Ne olursa olsun, yalnızca başlıklara körü körüne uymak yerine bağlamı iyi anlayıp uygulamanın önemli olduğunu düşünüyorum.

[savvykang]

Kodlama odaklı kişisel gelişim kitaplarının, teknolojiye ya da uygulama yöntemlerine dair henüz bir değer yargısı oluşmamış başlangıç seviyesindeki kişiler için faydalı olduğunu, ancak deneyim arttıkça yararının azaldığını düşünüyorum. Çünkü her projeye ve ortama uyan mutlak doğrular yok; ayrıca genel geçer yaklaşımların işlemediği durumlar da var. Diğer genel kişisel gelişim kitaplarındaki tavsiyelerde olduğu gibi, bunlara da belli bir mesafeyle yaklaşarak yalnızca duruma uyan önerileri uygulamak ve tavsiyelerin peşinden körü körüne gitmemek daha doğru görünüyor.

[nicewook]

John’un söylediklerine biraz daha fazla katılıyorum.
Bence asıl mesele, iki kişinin söylediklerini dogma gibi koşulsuzca takip etmek değil; neden böyle söylediklerini anlayıp ilerlemek.

[leojineoo]

Temiz kodun amaç değil, bir araç olduğunu unutmamak gerekir.

[ilikeall]

Yine de önemli olan, her şeyi kararında yapmak.

[elddytbt]

Faydalı 👍🏻

[GN⁺]

Hacker News görüşleri

• Bazı insanlar belirli konularda fazlasıyla dogmatik olabiliyor. Bunları neden kutsal metin gibi benimsediklerini anlayamıyorum

  • 80 karakter satır sınırı aşıldığında her seferinde öfkelenen insanlarla uğraşmak zorunda kaldım
  • Bu eğilim sadece programlama stili, pattern'ler ve deyimlerde değil; teknoloji yığını ve çözüm mimarisinde de daha da belirgin
  • Bir kitaptan ya da blogdan okuduklarını olduğu gibi alıntılayan insanlarla konuşmak son derece sinir bozucu
  • Özellikle NoSQL ve microservices çılgınlığında çok yoğundu; PAAS/SAAS ve containerization'da da hâlâ hissediliyor
  • Temel işlevleri yerine getiren bir uygulama ya da lambda, dönüşüm işi yalnızca bakım yükünü artırıyor ve bir değer üretmiyor
  • Bir kitabı ya da blogu yazan kişiyle aramdaki tek fark, onların yazmış olması. Görüşlerinin gerçek olmadığını her zaman akılda tutmak gerekir

• Uncle Bob'un önerilerini körü körüne izleyen bir projeyi deneyimlediğinizde, bunun değerinin ne kadar düşük olduğunu anlayabiliyorsunuz

  • Yazılım mühendisliğini iyileştirmeye yönelik bazı metinler üretmiş olsa da, bunlar korkunç tavsiyelerle dolu
  • Başarısı, rehber arayan junior geliştiricilerin bitmek bilmeyen ihtiyacı sayesinde mümkün oldu
  • Çok fazla dolaylılık içeren kod, üzerinde çalışması zor bir hâle geliyor

• Clean Code, iyi bir yazılım mühendisinin araç kutusundaki araçlardan sadece biridir

• Bazı insanlar, fonksiyon yalnızca yeniden kullanılacak ya da mantıksal olarak anlamlı olduğunda ayırmak yerine, birbirine yakın satırları gruplayıp buna sadece "refactoring" diyor

  • Üniversitedeyken Clean Code'u okuduğumda, Uncle Bob'un genel havasını hissetmiştim
  • Bu, sanki fonksiyonların X satır olması gerektiği fikrinden kaynaklanıyor gibi
  • Modern IDE'lerin inline özelliklerine minnettarım; kodu anlamak için yeniden yapılandırıyorum

• Yorumların önemine dair anılmayan önemli bir kullanım durumu var

  • USB aygıt sürücüsü yazılımı yazarken, aygıtı yanlış bir duruma sokmak çok kolay
  • Her workaround uyguladığımda, bunu belgelemek için yorum ekliyorum
  • Yorumlar olmadan başka birinin kodun niyetini anlaması zor

• "A Philosophy of Software Design" kitabını güçlü biçimde tavsiye ederim

  • Buradaki kilit nokta, soyutlamanın kalitesini karmaşıklık oranına göre ölçmek
  • Programlama tavsiyesi veren başka kitaplar okuduktan sonra kodum daha iyi hâle gelmedi

• Bu, Clean Code hareketinden önce yazılım sektöründeki gerçek sorunlara verilmiş bir tepkiydi

  • Clean Code daha iyi bir yöne gitti, ancak aşırıya kaçacak şekilde düzeltildi
  • İnsanların yeniden devasa metotlara ve derin iç içe koşullara geri dönüp dönmeyeceğini bilmiyorum

• Bob'un yorumlarla ilgili görüşleri tuhaf

  • Yanlış yorumlara dair paranoya saçma
  • Anlaşılması zor kod yüzünden çok zaman kaybettim
  • Garip diyagramlar üretmek yerine algoritmayı kısaca açıklamak ya da bir bağlantı vermek çok daha kolay olurdu

• Uncle Bob'un kitabı, zamanla aşılan bir şey

  • Clean Code'un rehberini izlerken "aşırı parçalama"yı öğrendim
  • Küçük fonksiyonlar sonunda hiçbir şey yapmamaya başlıyor
  • İyi kod yazmak istiyorsanız, iyi kod okuyun ve kendinize uygun bir zevk geliştirin

• Clean Code adından duyulan memnuniyetsizlik var

  • Kodun temizliğini nesnel olarak ölçmek mümkün değil
  • "Temiz kod" yazmanın doğal olarak iyi bir şey olduğu yönündeki bilinçdışı unsur sorun yaratıyor
  • "Uncle Bob" yaklaşımının temeli en başından beri çürüktü