Kod Yazmak Değil, Kodla Düşünmek: Kodlamanın Görünmeyen Yüzü
Kod Yazmak Değil, Kodla Düşünmek: Kodlamanın Görünmeyen Yüzü
Kod yazmak çoğu zaman teknik bir beceri olarak anlatılır. Öğrenilen sözdizimleri, kullanılan diller ve araçlar bu anlatının merkezindedir. Oysa kodun asıl ağırlığı, çalışmasında değil; onu yazan zihnin nasıl çalıştığında gizlidir. Aynı sonucu üreten iki farklı kod parçası, aynı düşünceyi taşımaz.
Buna iyi bir örnek olarak, WordPress’inana sayfasında yıllardır yer alan şu ifadedir: “Code is poetry.” Bu cümle, kodlamaya dair güçlü bir bakış açısını işaret eder. Kodun yalnızca işlevsel bir araç olmadığını, anlam taşıyan bir ifade biçimi olduğunu söyler. Şiir nasıl yalnızca kelimelerin yan yana gelmesi değilse, kod da yalnızca komutların dizilimi değildir.
Kod yazarken verilen her karar, geliştiricinin düşünme biçimini yansıtır. Bir yapının sade tutulması, bir fonksiyonun bölünmesi ya da karmaşık bir çözümden bilinçli olarak kaçınılması teknik tercihlerden önce zihinsel duruşla ilgilidir. Okunabilirlik, sürdürülebilirlik ve tutarlılık; öğrenilen kurallardan çok, kazanılan farkındalıkla ortaya çıkar.
Bu nedenle kodlama, yalnızca “nasıl yapılır” sorusuna verilen cevaplarla öğrenilmez. Asıl mesele, “neden böyle yapıldı” sorusunu sorabilmektir. Kodla düşünen biri için her satır, çalışması gereken bir yapıdan önce, anlamlı bir tercih olarak şekillenir. Bu bakış açısı, dili ve platformu aşan ortak bir zemindir.
Kodun Teknik Olmayan Tarafı
Kod yazarken en sık yapılan yanılgılardan biri, sorunun yalnızca çözüme ulaşmakla bittiğini sanmaktır. Bir özellik çalışıyorsa, bir hata ortadan kalktıysa, mesele kapanmış gibi görülür. Oysa kodun gerçek sınavı, ilk çalıştığı an değil; üzerinden zaman geçtiğinde, başka biri baktığında ya da aynı kodu yazan kişi aylar sonra geri döndüğünde başlar.
Bir örnek üzerinden gidelim. WordPress ana sayfasında öne çıkarılan “Code is poetry” ifadesi, rastgele seçilmiş bir cümle değildir. WordPress, milyonlarca insanın temas ettiği bir sistemdir ve bu sistemin çekirdeğinde yazılan kodun büyük kısmı son kullanıcı tarafından hiç görülmez. Buna rağmen, geliştiriciler okunabilirliğe, isimlendirmeye ve sadeliğe özel bir önem verir. Çünkü o kodu bir gün mutlaka bir başkası okuyacaktır. Şiir benzetmesi tam olarak burada anlam kazanır: Okuyan kişiye yük olan değil, onu taşıyan bir yapı.
Teknik olmayan taraf burada devreye girer. Bir fonksiyonun adını seçerken yapılan tercih, yalnızca teknik bir karar değildir. “getData” ile “getUserProfileData” arasındaki fark, sistemin çalışmasını değiştirmeyebilir ama zihinsel yükü değiştirir. İlki belirsizlik üretir, ikincisi niyetini açık eder. Kodun kendisi çalışır, fakat düşünce daha şeffaf hâle gelir.
Benzer bir durum karmaşıklıkta da görülür. Çoğu geliştirici, zekâsını göstermek istercesine karmaşık çözümler üretme eğilimindedir. Oysa karmaşık bir problemi basit bir yapıyla çözebilmek, teknik bilgiden çok düşünsel bir olgunluk gerektirir. Daha az satır yazmak değil, daha az zihinsel efor gerektiren bir yapı kurmak asıl beceridir. Bu, çoğu zaman tekrar tekrar yanılarak fark edilir.
Kodun teknik olmayan yönü, aynı zamanda etik bir alan da açar. Bir kod parçasının sadece bugün çalışması değil, yarın bir hata verdiğinde nasıl anlaşılacağı da önemlidir. Hata mesajlarının açık yazılması, geçici çözümlerin kalıcı hâle getirilmemesi, “şimdilik böyle kalsın” denilen yerlerin işaretlenmesi, geliştiricinin kendisiyle kurduğu ilişkinin göstergesidir. Burada merkezde makine değil, insan vardır.
Bu durum, eklenti veya tema geliştirme süreçlerinde görülür. Aynı işlevi yerine getiren iki farklı eklenti düşünelim. Biri hızlıca yazılmış, belgelenmemiş ve yalnızca yazan kişinin anlayabileceği bir yapıya sahiptir. Diğeri ise daha yavaş ilerlemiş, yorumlarla desteklenmiş ve başkasının müdahalesine açık hâle getirilmiştir. İkisi de teknik olarak “doğru” olabilir. Ancak ikinci yaklaşım, kodu kişisel bir alan olmaktan çıkarır ve ortak bir dile dönüştürür.
Kodla düşünmek, aynı zamanda vazgeçmeyi bilmektir. Her özelliği eklememek, her ihtimale karşı kod yazmamak, gereksiz soyutlamalardan uzak durmak da bilinçli tercihlerdir. Bu noktada geliştirici, kendisini değil; sistemi ve onu kullanacak insanları merkeze alır. Kod, bir güç gösterisi olmaktan çıkar ve işlevini sessizce yerine getiren bir yapıya dönüşür.
Bu bakış açısı dile, sürüme ya da araca bağlı değildir. Farklı teknolojilerle çalışan geliştiricileri ortak bir zeminde buluşturan şey, kodu yalnızca yazılan bir şey değil, düşünülen bir şey olarak görmeleridir. Kodun teknik olmayan tarafı, tam olarak bu zihinsel disiplinde şekillenir.
Kod, Niyet ve Sorumluluk
Kod yazmak, çoğu zaman bireysel bir eylem gibi algılanır. Bilgisayarın başında tek başına geçirilen saatler, bu algıyı güçlendirir. Oysa yazılan her satır, er ya da geç başkalarıyla temas eder. Bazen bir ekip arkadaşıyla, bazen hiç tanımadığımız bir geliştiriciyle, bazen de aylar sonra kendi geçmiş hâlimizle. Bu nedenle kod, yalnızca teknik bir üretim değil; niyet ve sorumluluk taşıyan bir ifadedir.
Niyet, kodun görünmeyen ama hissedilen yönüdür. Bir çözümün aceleyle mi yoksa bilinçle mi yazıldığı, çoğu zaman kodun kendisinden anlaşılır. Anlamsız kısaltmalar, belirsiz değişken adları, neden var olduğu anlaşılmayan yapılar, geliştiricinin o anki yaklaşımını ele verir. Buna karşılık, açık isimlendirme ve tutarlı yapı, “ben burada ne yaptığımı biliyorum” diyen sessiz bir duruştur.
Bir durum düşünelim. WordPress tabanlı bir projede, ana sayfada gösterilecek içerik sayısını belirleyen küçük bir ayar ekleniyor olsun. Bu ayarın doğrudan kodun içine sabitlenmesi teknik olarak mümkündür ve kısa vadede sorunsuz çalışır. Ancak aynı ayarın daha sonra değiştirilebilir olacağı düşünülerek yapılandırma üzerinden ele alınması, geliştiricinin geleceği hesaba kattığını gösterir. Buradaki fark teknik zorluk değil, bakış açısıdır.
Sorumluluk ise kodun zamanla kurduğu ilişkiyle ilgilidir. Kod yalnızca yazıldığı an için değil, bakım süreci için de vardır. Bir hata çıktığında, o hatanın izini sürebilmek; bir özellik eklendiğinde mevcut yapıyı bozmadan ilerleyebilmek, yazılan kodun ne kadar özenli olduğunu ortaya koyar. Bu noktada sorumluluk, “çalışıyor” demekle sınırlı kalmaz.
Kodla düşünmek, başkasının zamanına saygı duymayı da içerir. Okunabilir bir yapı kurmak, gereksiz karmaşıklıktan kaçınmak ve yapılan tercihleri anlaşılır kılmak, teknik gereklilikten çok etik bir tavırdır. Çünkü kötü yazılmış bir kod, sadece sistemi değil; onu okumak zorunda kalan insanı da yorar. İyi yazılmış bir kod ise sessizce işini yapar ve arkasında yük bırakmaz.
Bu sorumluluk anlayışı, ekip çalışmasında daha da belirgin hâle gelir. Ortak bir projede herkesin kendi tarzını dayatması, zamanla uyumsuz bir yapıya yol açar. Buna karşılık, belirli ilkeler etrafında şekillenen bir kod tabanı, bireysel farkları aşan bir bütünlük sağlar. Burada amaç tek tip kod yazmak değil, ortak bir dil oluşturabilmektir.
Kodun niyetle yazılması, geliştiricinin kendisiyle kurduğu ilişkiyi de yansıtır. “Nasıl olsa kimse görmeyecek” düşüncesiyle bırakılan geçici çözümler, çoğu zaman en görünür hatalara dönüşür. Buna karşılık, küçük bir detayın bile bilinçle ele alınması, kodu bir emek ürünü hâline getirir. Kod, bu noktada yalnızca işlevini yerine getiren bir araç değil; geliştiricinin sorumluluk anlayışının sessiz tanığı olur.
Kodla Düşünmenin İnceliği
Kodla düşünmek, çoğu zaman fark edilmeden gelişen bir beceridir. Bir noktadan sonra geliştirici, problemi doğrudan çözecek kodu yazmadan önce, zihninde tartmaya başlar. Bu tartma süreci teknik bir hesaplama değildir; daha çok sezgisel bir elemedir. Hangi yol daha sade, hangi yapı daha dayanıklı, hangi çözüm daha az iz bırakır gibi sorular, klavyeye dokunulmadan önce şekillenir.
Bu incelik, özellikle tekrar eden işlerde belirginleşir. Aynı yapıyı defalarca yazan biri, zamanla yalnızca çalışan kodu değil, doğru yerde duran kodu arar. Örneğin WordPress tarafında bir tema geliştirirken, belirli bir işlevi farklı sayfalarda tekrar etmek mümkündür. Kısa vadede bu yol daha hızlı görünür. Ancak bir süre sonra aynı değişikliği beş farklı yerde yapmak zorunda kalmak, geliştiriciyi düşünmeye zorlar. Kodla düşünen biri, bu noktada çözümü kopyalamakta değil, soyutlamakta bulur. Burada amaç karmaşık bir yapı kurmak değil, tekrarın yükünü azaltmaktır.
İncelik, her zaman daha fazla katman eklemek anlamına gelmez. Aksine, çoğu zaman katmanları azaltmakla ilgilidir. Gereksiz bir soyutlama, sistemi daha esnek hâle getirmek yerine daha kırılgan kılabilir. Bu nedenle kodla düşünmek, “yapılabilir mi” sorusundan çok “yapılmalı mı” sorusunu sormayı gerektirir. Bu soru teknik dokümantasyonlarda yer almaz; deneyimle kazanılır.
Bir örnek daha düşünelim. Bir eklentide kullanıcıdan gelen veriyi işleyen bir yapı olsun. Teknik olarak veriyi doğrudan alıp işlemek mümkündür. Ancak araya bir kontrol katmanı eklemek, verinin ne olduğu kadar ne olmadığını da tanımlamak anlamına gelir. Bu yaklaşım, yalnızca güvenlikle ilgili değildir; aynı zamanda zihinsel bir netlik sağlar. Kod, neyi kabul ettiğini ve neyi dışarıda bıraktığını açıkça ifade eder. Bu da geliştiricinin kendi sınırlarını bilmesiyle ilgilidir.
Kodla düşünmenin bir diğer yönü de sabırdır. Her problemi anında çözmeye çalışmak, çoğu zaman aceleci kararlar doğurur. Bazen kod yazmamak, yazmaktan daha doğru bir tercihtir. Bir sorunun biraz beklemesi, farklı bir gözle tekrar ele alınması, daha sade bir çözümün ortaya çıkmasını sağlar. Bu, üretkenliğe aykırı gibi görünse de uzun vadede daha sağlam yapılar üretir.
Bu incelik, hatalarla da ilişkilidir. Kodla düşünen biri için hata, yalnızca düzeltilmesi gereken bir sorun değildir. Hata, sistemin nerede zorlandığını gösteren bir işarettir. Aynı hatanın tekrar tekrar ortaya çıkması, yüzeydeki bir problemi değil, alttaki düşünce eksikliğini işaret eder. Bu noktada geliştirici, yamalarla ilerlemek yerine köke inmeyi tercih eder.
Kodun inceliği, çoğu zaman sessizdir. Göze çarpmaz, övgü toplamaz, hızla fark edilmez. Ancak zamanla kendini belli eder. Daha az kırılan yapılar, daha rahat okunan dosyalar ve daha az açıklama gerektiren çözümler, bu inceliğin doğal sonucudur. Kodla düşünen biri için asıl başarı, kodun kendini anlatabilmesidir.
Kodla Düşünmek Neyi Değiştirir?
Kodla düşünmek, yazılan satırların sayısını ya da kullanılan teknolojileri değiştirmek zorunda değildir. Asıl değişen, geliştiricinin koda yaklaşma biçimidir. Kod artık yalnızca çalışması gereken bir yapı değil; niyeti olan, zamanla ilişki kuran ve başkalarıyla temas edecek bir üretim hâline gelir.
Bu bakış açısı, geliştiriciyi daha “akıllı” çözümler üretmeye zorlamaz. Aksine, daha sakin, daha ölçülü ve daha farkında tercihler yapmaya yönlendirir. Hangi özelliğin gerçekten gerekli olduğu, hangi soyutlamanın yük getirdiği, hangi kararın ileride sorun çıkarabileceği gibi sorular, kod yazımının doğal bir parçası hâline gelir.
Kodla düşünen biri için başarı, karmaşık yapılar kurmakla değil; karmaşıklığı kontrol altında tutabilmekle ilgilidir. Okunabilirlik, tutarlılık ve sürdürülebilirlik bu noktada teknik hedefler olmaktan çıkar, geliştiricinin sorumluluk anlayışını yansıtan göstergelere dönüşür.
Sonuçta kod, yalnızca bugünün ihtiyacına cevap veren bir araç değildir. Zamanla okunacak, değiştirilecek ve yeniden anlamlandırılacaktır. Bu yüzden kodla düşünmek, gelecekteki okuyucuya —başkası ya da kendi geçmişimiz— bırakılan sessiz bir not gibidir. Ne kadar az açıklamaya ihtiyaç duyuyorsa, o kadar doğru yazılmış demektir.
Kodun görünmeyen yüzü tam olarak burada ortaya çıkar. Yazılan satırlarda değil, yazılırken verilen kararlarda. Kod çalışabilir; ama düşünce yerindeyse, asıl değerini o zaman bulur.