Ekranda Aynı, İçeride Devrim: Kod Refaktörünün Gizli Estetiği

Kod refaktörü, yazılım dünyasının en tuhaf sanatlarından biridir: Seyirci salona girer, perde açılır, sahne aynı görünür. Düğmeler aynı yerde, ekran aynı renkte, kullanıcı yine aynı işlemi yapar. Fakat kulisin arkasında dekor sökülmüş, kablolar etiketlenmiş, oyuncuların giriş çıkışları yeniden düzenlenmiş, yangın çıkışları açılmıştır. Dışarıdan hiçbir şey değişmemiştir; içeride ise küçük bir uygarlık kurulmuştur.

Bu yüzden refaktör, sadece teknik bir işlem değil, bir ahlak biçimidir. Çünkü hızlıca çalışan ama içten içe çürüyen kod ile karşılaşan geliştirici, iki yoldan birini seçer: Ya halının altına bir hata daha süpürür ya da diz çöküp zemindeki çatlağı onarır. Refaktör yapan kişi, gelecekteki bilinmeyen bir meslektaşına, hatta çoğu zaman kendisinin üç ay sonraki hâline not bırakır: Burada seni bekleyen bir mayın yok, rahat yürü.

Davranış aynı kalır, anlam değişir

Refaktörün temel ilkesi basittir: Dış davranışı değiştirmeden iç yapıyı iyileştirmek. Bu cümle kuru görünür ama yazılım mühendisliğinin Zen bahçesidir. Bir fonksiyon hâlâ aynı sonucu döndürür; fakat artık adının ne yaptığı anlaşılır. Bir sınıf hâlâ aynı sorumluluğu taşır; fakat sırtındaki beş gereksiz çuval indirilmiştir. Bir koşul hâlâ aynı kararı verir; fakat artık ormanda kaybolmuş bir if-else labirenti değildir.

Burada güzellik, kullanıcı arayüzünde değil, niyette ve düzendedir. İyi refaktör edilmiş kod, sessizce nefes alır. Değişiklik talebi geldiğinde panikle camdan atlamaz; sandalyeyi çeker, çayını koyar ve şöyle der: Buyur, nereye evrileceğiz? Kötü kod ise aynı isteği duyunca mağara ayısı gibi hırlar. Çünkü bağımlılıklar birbirine düğümlenmiş, isimler sisli, testler yok, mantık her yere sızmıştır.

Temizlik takıntısı değil, risk yönetimi

Refaktör bazen yanlış anlaşılır. Sanki geliştiricinin estetik kaprisiymiş gibi görülür: Aa, arkadaşımız kodun simetrisini beğenmemiş, biraz süsleyecek. Hayır. Refaktör, süsleme değildir; karmaşıklık borcunun faizini düşürmektir. Teknik borç, kredi kartı gibidir: Bugün hızlı geçersin, yarın faiz seni toplantı odasında yakalar. Bir noktadan sonra yeni özellik eklemek, bataklıkta piyano taşımaya benzer.

Bu nedenle iyi refaktör, ölçülü ve amaçlıdır. Her şeyi yeniden yazma sarhoşluğu refaktör değil, mimari yangındır. Gerçek refaktör küçük adımlarla ilerler: Bir metodu böl, bir adı netleştir, tekrarı kaldır, yan etkiyi izole et, testi ekle, bağımlılığı tersine çevir. Her adımda sistem çalışmaya devam eder. Cerrahın hastayı güzelleştirmek için değil, yaşatmak için kesmesi gibi.

İsim vermek, dünyayı kurmaktır

Programlamada isimlendirme, küçümsenen bir felsefe problemidir. Bir değişkene temp demek, onu sisin içine atmaktır. calculate demek de çoğu zaman yetmez; neyi hesaplıyor, kimin için, hangi bağlamda? İyi isim, zihinsel yükü azaltır. Kod okuyan kişi artık dedektiflik yapmaz; metni izler. Refaktör bu anlamda dilin arkeolojisidir: Koddaki bulanık kavramları kazar, ortaya gerçek niyeti çıkarır.

Bir başka estetik nokta da sınır çizmektir. Her şeyi bilen nesneler, yazılımın küçük diktatörleridir. Her yere erişen yardımcı sınıflar, imparatorluğun casus ağıdır. Refaktör, bu güç yoğunlaşmasını dağıtır. Sorumluluklar ayrılır, modüller kendi mahremiyetini kazanır, veri akışı izlenebilir hâle gelir. İyi mimari, her parçanın hem yalnız kalabildiği hem de doğru anda konuşabildiği bir şehir planıdır.

Testler: İç düzenin aynası

Refaktörün cesareti testlerden gelir. Test yoksa geliştirici karanlıkta mobilya taşıyordur; her an vazoya çarpabilir. Test varsa ışık yanar. Dış davranışın değişmediğini doğrulamak, refaktörün güvenlik kemeridir. Bu yüzden testler sadece hata yakalama aracı değil, tasarımın nabız ölçeridir. Test edilmesi zor kod genellikle fazla bağlı, fazla gizli anlaşmalar yapan, fazla dramatik koddur.

Sonunda refaktörün estetiği şurada belirir: Kimse alkışlamaz. Kullanıcı fark etmez. Ürün yöneticisi bazen ne yaptığını bile anlamaz. Fakat bir gün kritik bir değişiklik gelir ve ekip şaşırtıcı bir sakinlikle ilerler. İşte o an, geçmişte yapılan görünmez temizlik konuşur. Refaktör, geleceğin paniklerini bugünden susturma sanatıdır. Dışarıda aynı bina durur; içeride taşıyıcı kolonlar hizalanmış, merdivenler aydınlatılmış, kapılar artık duvara açılmamaktadır. Yazılımda gerçek güzellik bazen tam da budur: Hiçbir şey olmamış gibi görünür, çünkü içeride her şey olması gerektiği gibidir.

Ölü Kod Mezarlığı: Sistemi Yavaşlatan Hayalet İnançlar

Her yazılım sisteminin bodrum katında bir mezarlık vardır. Orada artık çalışmayan fonksiyonlar, yıllar önce terk edilmiş koşullar, kimsenin çağırmadığı sınıflar ve üstüne not düşülmüş kadim büyüler uyur: sakın silme, bir gün lazım olabilir. Ölü kod tam olarak budur; programın yaşayan akışına katkısı olmayan ama depoda yer kaplayan, zihni meşgul eden, bakım maliyetini artıran eski parçalar. İlginç olan şu: Ölü kod teknik bir mesele gibi görünür, ama çoğu zaman psikolojik bir arızanın izidir. Kod çalışmaz; korku çalışır.

Bir ekip düşünün. Beş yıl önce yazılmış bir ödeme modülünün içinde devasa bir if bloğu duruyor. Artık hiçbir müşteri o yolu kullanmıyor, dokümantasyon onu anmıyor, testler ona uğramıyor. Ama biri silmeyi önerdiğinde odada sessizlik oluşuyor. Çünkü kodun kendisinden çok, onun etrafındaki efsane yaşıyor: Eski CTO bunu yazmıştı. Büyük bir müşteride sorun çıkarmıştı. Bir ara kampanya döneminde hayat kurtarmıştı. İşte yazılımda ölü kod, çoğu zaman eski bir savaşın madalyasıdır; paslanmıştır ama kimse duvardan indirmeye cesaret edemez.

Ölü kod neden tehlikelidir?

Çünkü yazılım yalnızca işlemciye verilen talimatlardan oluşmaz; aynı zamanda geliştiricinin zihninde kurduğu modeldir. Sistemde gereksiz kod ne kadar artarsa, bu model o kadar bulanıklaşır. Yeni gelen geliştirici şunu sorar: Bu fonksiyon hâlâ kullanılıyor mu? Bu parametre niye var? Bu hata yakalama bloğu hangi senaryo için? Cevap yoksa, kod artık bilgi değil gürültüdür. Gürültü de karar vermeyi yavaşlatır. Yavaş karar veren ekip, hızlı bozulan sistem üretir.

Ölü kodun maliyeti yalnızca satır sayısı değildir. Derleme süresini uzatabilir, statik analizleri kirletebilir, güvenlik taramalarında yanlış alarm üretebilir, test kapsamını sahte şekilde yükseltebilir. Daha kötüsü, yeni bir özellik geliştirirken yanlış referans noktası sunar. Geliştirici, yaşayan mimariyi değil, fosilleşmiş bir çözümü taklit eder. Böylece ölü kod çoğalır; mezarlık, şehir planına dönüşür.

Burada en kritik ayrım şudur: Eski kod ölü kod demek değildir. Legacy kod, hâlâ değer üretiyorsa yaşlı ama canlıdır. Ölü kod ise artık sistem davranışının parçası olmayan koddur. Onu kutsal yapan yaşlılığı değil, belirsizliğidir. Belirsizlik arttıkça insanlar silmek yerine dokunmamayı seçer. Dokunmamak güvenli görünür, ama uzun vadede en pahalı stratejilerden biridir.

Silmek bir vandalizm değil, bakım disiplinidir

Ölü kodla mücadele romantik cesaretle değil, yöntemle yapılır. Önce kullanım izleri aranır: çağrı grafikleri, loglar, feature flag kayıtları, telemetri, testler, sürüm geçmişi. Kod gerçekten çalışmıyorsa, onu yorum satırına almak çözüm değildir; bu sadece cesedi salona taşımaktır. Versiyon kontrol sistemi zaten hafızadır. Git varsa, mezar taşı olarak yorum satırı bırakmaya gerek yoktur.

İyi bir temizlik süreci küçük ve geri döndürülebilir adımlarla ilerler. Önce şüpheli alan işaretlenir, ardından gözlem süresi tanımlanır. Kullanım yoksa testler güncellenir, bağımlılıklar kaldırılır, kod silinir. Pull request açıklamasında neden silindiği net yazılır. Böylece silme eylemi kişisel bir saldırı değil, izlenebilir bir mühendislik kararı olur. Ölü kodu silmek, geçmişteki geliştiriciyi küçümsemek değildir; onun bir zamanlar çözdüğü problemin artık var olmadığını kabul etmektir.

Bu konu yazılımın dışına da sızar. Kurumların süreçlerinde, ekiplerin alışkanlıklarında, bireylerin düşüncelerinde de ölü kod vardır. Bir zamanlar işe yarayan ama artık sadece refleks olarak sürdürülen kurallar. Kimsenin okumadığı raporlar. Her toplantıda tekrarlanan ama karar üretmeyen cümleler. Eski bir başarının gölgesinde yaşayan inançlar. Yazılım bize acımasız bir ayna tutar: Çalışmayan şeyi sistemde tutarsan, sistem sonunda ona benzemeye başlar.

En sağlıklı kod tabanları, en çok kod yazılanlar değil, gereksiz kodun düzenli olarak eksiltildiği yerlerdir. Çünkü iyi mühendislik eklemek kadar çıkarmayı da bilmektir. Bir satırı silmek bazen yüz satır yazmaktan daha yüksek zekâ ister. Ölü kodun fısıltısı hep aynıdır: Ya lazım olursam? Usta geliştiricinin cevabı ise sakindir: Lazım olursan geçmişten geri çağırırım; bugün yaşamıyorsan, üretimde yerin yok.

Az Kod, Çok Ustalık: Neden Kısa Çözümler Daha Zordur?

Programlamada uzun kod bazen çok çalışıldığının kanıtı gibi görünür. Ekranı satır satır dolduran koşullar, döngüler ve yardımcı fonksiyonlar insana üretkenlik hissi verir. Oysa deneyimli geliştiriciler çoğu zaman tersine bir hedefe yönelir: Aynı işi daha az kodla, daha açık biçimde ve daha az hata olasılığıyla yapmak. Bu, tembellik değil; problemin özünü ayıklama sanatıdır. Kısa kod yazmak, tuşlara daha az basmak değil, düşünceye daha fazla emek vermektir.

Satır sayısı değil, zihinsel yük

Bir programın gerçek maliyeti onu ilk yazarken değil, ikinci kez anlamaya çalışırken ortaya çıkar. Kodun bakımını yapan kişi çoğu zaman onu yazan kişi değildir; hatta çoğu projede bu kişi, birkaç ay sonraki sizsiniz. Her gereksiz değişken, tekrar eden kontrol ve özel durum, okuyucunun zihninde taşınması gereken ek bir yük yaratır. Dil ekonomisi tam burada devreye girer: Kod, makinenin çalıştıracağı talimatların yanında insanların okuyacağı bir metindir. İyi kod, yalnızca doğru sonucu üretmez; niçin doğru olduğunu da görünür kılar.

Örneğin aynı doğrulama mantığını beş farklı yerde kopyalamak ilk anda hızlıdır. Fakat kurallar değiştiğinde beş noktayı hatasız güncellemek gerekir. Bu tekrarları anlamlı bir fonksiyonda toplamak, satır sayısını azaltırken değişimin maliyetini de düşürür. Ustalık, tekrar eden şekilleri fark etmek ve onları doğru soyutlama düzeyinde ifade etmektir. Ne çok genel ne de aşırı özel bir yapı seçmek gerekir. Çünkü her soyutlama, gelecekteki değişiklikler hakkında yapılmış bir bahistir.

Kısalık ile sıkıştırma aynı şey değildir

Burada önemli bir tuzak vardır: Daha az kod her zaman daha iyi kod değildir. Bir satıra sığdırılmış, iç içe geçmiş koşullarla dolu bir ifade kısa olabilir ama anlaşılır olmayabilir. Akıllıca yazılmış kod ile numara yapan kod arasındaki fark, açıklıkta görülür. Bir fonksiyon üç satırda işi çözüyor diye başarılı sayılmaz; adı davranışını anlatıyor, girdileri öngörülebilir ve yan etkileri sınırlıysa değerlidir. Dil ekonomisinin amacı karakter sayısını düşürmek değil, gereksiz kavramsal hareketleri azaltmaktır.

Bu nedenle iyi programcı, hazır kütüphaneleri tanır ve tekerleği yeniden üretmez. Sıralama, filtreleme, tarih işlemleri ya da güvenli veri doğrulama için olgun araçlar varken yüzlerce satır özel çözüm yazmak çoğu zaman cesaret değil, maliyet üretmektir. Ancak kütüphane kullanmak da körü körüne kısaltma değildir. Aracın karmaşıklığını, sınırlarını, performansını ve hata davranışını anlamak gerekir. Az kodun arkasında çoğu kez çok bilgi vardır.

Silmek, eklemekten daha zor olabilir

Bir özelliği eklemek görünür bir başarıdır; gereksiz bir özelliği, bağımlılığı veya soyutlamayı silmek ise daha sessiz bir zaferdir. Silmek için sistemin hangi parçalarının gerçekten gerekli olduğunu bilmek gerekir. Bu yüzden refaktörizasyon, estetik bir düzenleme değil, bilgi çıkarma işlemidir. Geliştirici kodu sadeleştirirken sistemin değişmezlerini keşfeder: Hangi kurallar vazgeçilmez, hangi dallanmalar geçmişten kalma, hangi veri yapıları aslında aynı kavramı temsil ediyor?

Sonuçta dil ekonomisi, minimalizm modasından çok mühendislik disiplinidir. En iyi çözüm her zaman en kısa olan değildir; en az sürpriz yaratan, en kolay doğrulanan ve değişime en sakin tepki veren çözümdür. Daha az kod yazmak, problemi küçültmek anlamına gelmez. Tam tersine, problemi yeterince derin anlayıp onun gereksiz kabuğunu soymaktır. Usta programcı, karmaşıklığı ekrana yaymak yerine tasarım kararlarında çözmeye çalışır. Makineye az şey söyleyebilmek için önce probleme çok şey sormak gerekir.

Kodun Gösterişi Değil, Zarafeti Kazanır: Neden Daha Az Çoğu Zaman Daha İyidir?

Bir yazılım projesinde karmaşıklık çoğu zaman zekânın kostümü gibi görünür. On iki katmanlı soyutlamalar, her sınıf için ayrı bir arayüz, küçük bir işlem için devasa bir tasarım deseni koleksiyonu… Bunlar ilk bakışta etkileyicidir. Fakat bilişimde etkileyici olmak ile iyi olmak aynı şey değildir. Zarafet ilkesi, çözümün gösterdiği kas gücünden çok, problemi ne kadar doğrudan, anlaşılır ve güvenilir biçimde çözdüğüne bakar. İyi kod, geliştiricinin ne kadar çok şey bildiğini değil; neyi gereksiz yere kullanmadığını da gösterir.

Zarafet: Az Kod Değil, Az Gereksiz Karar

Zarif bir çözüm mutlaka en kısa çözüm değildir. Tek satıra sıkıştırılmış, yalnızca yazarı tarafından çözülebilen bir ifade zarif sayılmaz; o, çoğu zaman şifrelenmiş bir egodur. Zarafet; okunabilirlik, doğru soyutlama, öngörülebilir davranış ve düşük bilişsel yükün birleşimidir. Bir fonksiyonun ne yaptığını anlamak için zihinde beş farklı dosya, üç tasarım deseni ve geçmişte alınmış iki mimari karar taşımak gerekiyorsa, orada bir sorun vardır. Kod bilgisayara değil, gelecekte onu değiştirecek insana da hizmet eder.

Örneğin bir listedeki tekrar eden öğeleri kaldırmak için özel bir sınıf hiyerarşisi, olay dinleyicileri ve yapılandırılabilir stratejiler kurmak mümkündür. Ama ihtiyaç yalnızca benzersiz öğeler elde etmekse, uygun bir veri yapısı kullanmak çoğu kez yeterlidir. Buradaki mesele tembellik değildir; problemin gerçek sınırını görme disiplinidir. Henüz ortaya çıkmamış ihtiyaçlar için mimari inşa etmek, yağmur ihtimaline karşı apartmanın çatısına deniz feneri dikmeye benzer.

Karmaşıklığın Gizli Faturası

Her ek katman bir maliyet üretir: Daha fazla test senaryosu, daha fazla hata olasılığı, daha uzun hata ayıklama süresi ve daha zor onboarding süreci. Bir sistemin karmaşıklığı yalnızca satır sayısıyla ölçülmez. Bağımlılıkların yönü, durumların sayısı, bileşenler arasındaki görünmez anlaşmalar ve istisnaların birikimi de bu faturaya dahildir. Özellikle dağıtık sistemlerde küçük bir gereksiz soyutlama, ağ gecikmesi, tutarsız veri veya başarısız yeniden deneme gibi gerçek dünya sorunlarıyla birleştiğinde büyük bir belirsizliğe dönüşebilir.

Bu yüzden iyi mühendislik, önce en basit doğru çözümü kurar; sonra ölçer; ancak kanıt varsa karmaşıklaştırır. Performans darboğazı gerçekten nerede? Güvenlik gereksinimi hangi sınırı zorunlu kılıyor? Sistemin hangi parçası değişken? Bu sorular yanıtlanmadan yapılan optimizasyon ve genelleştirme, çoğu zaman teknik borcun kibar adıdır. Donald Knuth’un erken optimizasyon uyarısı hâlâ canlıdır: Ölçmeden hızlandırmaya çalışmak, haritasız biçimde kestirme aramaktır.

Basitlik Bir Başlangıç Değil, Sürekli Bir Seçimdir

Zarafet ilkesi, her şeyi tek dosyaya koymak veya mimariyi reddetmek anlamına gelmez. Büyük sistemler modüllere, açık sınırlara ve dikkatli soyutlamalara ihtiyaç duyar. Ancak iyi soyutlama, karmaşıklığı saklamak için değil, onu yönetmek için vardır. Bir modülün içi karmaşık olabilir; dışarıdan ise mümkün olduğunca yalın bir sözleşme sunmalıdır. Kullanıcının ya da başka bir geliştiricinin anlaması gereken ayrıntı sayısı azaldıkça sistem daha sağlam hale gelir.

Sonuçta bilişimde zarafet, estetik bir süs değil, operasyonel bir erdemdir. Daha basit çözüm daha kolay test edilir, daha rahat anlatılır, daha güvenli değiştirilir ve arızalandığında daha çabuk onarılır. En iyi çözüm, en çok parçaya sahip olan değildir; doğru sayıda parçayla doğru işi yapan çözümdür. Kod yazarken sorulacak en değerli soru şudur: Bu karmaşıklık gerçekten problemi mi çözüyor, yoksa yalnızca problem çözüyor gibi mi görünüyor?

Çalışan Kod Yetmez: Python’da Okunabilirlik Neden Bir Nezaket Meselesidir?

Bir kod parçasının çalışması, onun iyi olduğu anlamına gelmez. Bu cümle ilk bakışta haksız gibi durabilir; sonuçta bilgisayar ekranda beklenen çıktıyı veriyorsa mesele kapanmış sayılmaz mı? Hayır. Çünkü kod yalnızca makineye yazılmaz. Kod, gelecekte onu okuyacak insana da yazılır: ekip arkadaşına, stajyere, açık kaynak katkıcısına ve en önemlisi, altı ay sonra o satırlara boş gözlerle bakacak olan sana.

Python bu konuda özel bir dile sahiptir. Sözdizimi sade, girintiler anlamlı, standart kütüphanesi zengindir. Fakat Python’ın asıl gücü sadece teknik olanaklarında değil, kültüründedir. Python topluluğunun meşhur ilkelerinden biri şudur: okunabilirlik önemlidir. Bu ilke, basit bir stil önerisi değil, yazılım dünyasında ahlaki bir pusuladır. Çünkü okunamayan kod, başkasının zamanını izinsizce harcar.

Makine Anlar, İnsan Acı Çeker

Bilgisayar için değişkenin adının x, tmp, zzz ya da user_session_timeout olması arasında büyük bir duygusal fark yoktur. Bilgisayar kırılmaz, sinirlenmez, kahveye ihtiyaç duymaz. İnsan ise bağlam arar. Niyet arar. Bir fonksiyonun neden orada olduğunu, hangi durumda ne yaptığını, hangi sınırları gözettiğini anlamaya çalışır. Eğer kod bu sorulara cevap vermiyorsa, çalışan bir labirentten ibarettir.

Okunabilirlik, kodun niyetini görünür kılma sanatıdır. Bir fonksiyon tek bir iş yapıyorsa, adı yaptığı işi söylüyorsa, karmaşık koşullar anlamlı parçalara ayrılmışsa, yorumlar gereksizi tekrar etmek yerine kararların nedenini açıklıyorsa, orada teknik beceriden daha fazlası vardır. Orada bir insan diğer insana şöyle der: Seni düşündüm.

Bu yüzden okunabilir kod bir nezaket biçimidir. Kapıyı çarpmadan kapatmak, toplantıya zamanında gelmek, ortak mutfağı temiz bırakmak gibidir. Kod tabanları da ortak yaşam alanlarıdır. Dağınık bırakılan her fonksiyon, gelecekte birinin zihinsel masasına dökülen kırıntıdır.

PEP 8 Bir Görgü Kuralı Kitabıdır

Python’da PEP 8 çoğu zaman biçimsel bir standart gibi anlaşılır: satır uzunluğu, boşluklar, isimlendirme, girintiler. Oysa daha derin bakınca PEP 8 bir topluluk sözleşmesidir. Hepimiz aynı dili konuşalım ki birbirimizi daha az yanlış anlayalım der. Kod biçimlendiriciler, linter araçları ve tip ipuçları bu sözleşmeyi destekleyen medeni kurumlar gibidir.

Elbette okunabilirlik yalnızca güzel hizalanmış satırlar değildir. Bazen fazla akıllı olmak okunabilirliğin düşmanıdır. Tek satırda yazılmış büyülü bir liste üreteci, beş farklı koşulu ve iki yan etkiyi içine sıkıştırıyorsa, belki de programcı zekasını değil sabırsızlığını sergiliyordur. Kod golfü eğlencelidir; üretim kodunda ise çoğu zaman toplumsal bir suç mahalline dönüşür.

İyi Python kodu kendini açıklamaya çalışır. Örneğin kullanıcıları filtreleyen bir fonksiyon düşünelim. İçinde karmaşık bir if yığını yerine is_active_user, has_valid_subscription, can_receive_email gibi küçük, anlamlı yardımcı fonksiyonlar varsa, okuyucu kodu çözmez; kodla konuşur. Bu fark önemlidir. Çözülen şey şifredir. Okunan şey metindir.

Etik, Bakım Maliyetinde Saklıdır

Yazılım projelerinde maliyetin büyük kısmı ilk yazımda değil, bakımda ortaya çıkar. Bugün hızlıca geçiştirilen bir isimlendirme, yarın hatalı bir düzeltmeye; belirsiz bir fonksiyon, gelecek ay yanlış kullanılan bir API’ye dönüşebilir. Okunamazlık yalnızca estetik bir kusur değildir; hata üretir, güvenliği zayıflatır, ekipleri yavaşlatır, yeni katılanları dışarıda bırakır.

Bu noktada etik başlar. Çünkü etik, çoğu zaman görünmeyen sonuçları hesaba katma yeteneğidir. Ben şimdi bu kodu nasıl yazarsam, benden sonra gelenin hayatı kolaylaşır? Hangi soyutlama gerçekten gerekli, hangisi egomu parlatan sis makinesi? Nerede yorum yazmalıyım, nerede daha iyi bir isim yeterli? Bu sorular teknik olduğu kadar karakterle de ilgilidir.

Python bize şunu fısıldar: Basitlik tembellik değildir. Açıklık yüzeysellik değildir. Hatta çoğu zaman en zor beceri, karmaşık olanı sade biçimde ifade etmektir. Okunabilir kod yazmak, düşüncenin arıtılmasıdır. Dağınık kod çoğu zaman dağınık zihnin izidir; temiz kod ise disipline edilmiş dikkatin.

Sonuçta yazılım, yalnızca algoritmaların değil ilişkilerin de alanıdır. Her commit küçük bir mektuptur. Her fonksiyon bir sonraki okuyucuya bırakılmış nottur. Python’da okunabilirlik ahlakı tam da burada doğar: Kodum çalışıyor demek yetmez; kodum anlaşılabilir, sürdürülebilir ve başkasının zihnine saygılı olmalı. Çünkü iyi programcı yalnızca makineyi ikna eden kişi değildir. İyi programcı, insanı da yormadan gerçeğe götüren kişidir.