Temiz Kod (Clean Code) Felsefesi: Bugün Yaz, Yarın Okuyabil

O Sancılı Yüzleşme: "Bu Çöpü Hangi Akılsız Yazmış?"

Yazılıma ilk başladığım 2005 yıllarını dün gibi hatırlıyorum. O zamanlar tek derdim ekranda bir şeylerin çalışmasını sağlamaktı. Bir buton tıkladığımda veritabanına kayıt atıyorsa, işlem tamamdı. Kodun nasıl göründüğünün, ne kadar karmaşık olduğunun hiçbir önemi yoktu. Fakat yıllar geçtikçe, projeler büyüdükçe ve o projelerin bakımı kabusa dönüştükçe bir şeylerin yanlış olduğunu fark etmeye başladım.

Hiç unutmam, bundan birkaç yıl önce Pixel Lab® için geliştirdiğimiz eski bir projenin bakımını yapmam gerekiyordu. Müşteri ufak bir özellik eklememi istemişti. "En fazla yarım saatimi alır" diyerek bilgisayarın başına oturdum. Dosyayı bir açtım ki, aman Allah'ım! İç içe geçmiş if blokları, ne idüğü belirsiz $x, $y değişkenleri, yüzlerce satır süren ve ne yaptığı belli olmayan devasa fonksiyonlar... Ekrana bakıp kendi kendime mırıldandım: "Bunu hangi akılsız yazmış böyle? İnsan okuyacak bunu insan!"

Hemen suçluyu bulmak için terminali açıp o meşhur komutu yazdım: git blame. Karşıma çıkan isimle başımdan aşağı kaynar sular döküldü. O "akılsız" bendim. Yaklaşık iki yıl önceki Buğrahan, "Çalışıyorsa dokunma" mantığıyla o spagetti kodu yazıp projeyi canlıya almıştı. O gün o ufak özelliği eklemek yarım saatimi değil, tam bir günümü aldı. Çünkü önce kendi yazdığım, daha doğrusu şifrelediğim o kod yığınını çözmem gerekti.

İşte o gün anladım ki; kod yazmak sadece makineye ne yapacağını söylemek değildir. Asıl mesele, o kodu senden sonra okuyacak olan insana (ki bu kişi büyük ihtimalle 6 ay sonraki uykusuz sen olacaksın) ne yapmaya çalıştığını anlatabilmektir. Ormanda kamp yaparken etrafı nasıl temiz bırakıyorsam, dijital dünyamda da arkamda temiz bir iz bırakmalıydım. Bu aydınlanma, benim Temiz Kod (Clean Code) felsefesiyle gerçek anlamda tanıştığım an oldu.

İsimlendirme Sanatı: "Data" Demek Neden Suçtur?

Açıkçası, yazılım geliştirme sürecinde en çok zorlandığım şey karmaşık algoritmalar kurmak değil, değişkenlere ve fonksiyonlara doğru ismi bulmaktır. Çoğu zaman yeni başlayan arkadaşlarda (ve yalan yok, eski bende de) şu tembelliği görüyorum: Bir veri çekiliyor ve adı hemen $data, $info veya $result yapılıyor. İyi de neyin datası bu? Hangi sonuç?

Ormanda yürüyüşe çıktığımda gördüğüm her ağaca "ağaç" deyip geçmem. Meşe ayrıdır, çam ayrıdır, kayın ayrıdır. Çünkü isim, o şeyin karakterini belirler. Kod yazarken de durum tam olarak böyledir. İyi bir isimlendirme, yazabileceğiniz en iyi dokümantasyondur.

Aşağıdaki örneğe bir bakalım:

// Kötü İsimlendirme
$d = 45; // d ne? Gün mü? Yaş mı?

// İyi İsimlendirme
$elapsedTimeInDays = 45;

İlk satırı okuduğunuzda $d'nin ne olduğunu anlamak için kodun geri kalanını, belki de o dosyanın en başına kadar olan kısmını taramanız gerekir. Oysa $userRegistrationDate veya $isActiveAccount gibi açıklayıcı isimler kullandığınızda, kod adeta sizinle konuşur. Evet, değişken isimleri biraz uzayabilir ama inanın bana, o uzun isimler aylar sonra o kodu okurken size saatler kazandıracaktır. Okunabilir kod yazmanın ilk ve en sarsılmaz kuralı, o anki üşengeçliğinizi yenip doğru ismi bulmaktır.

Fonksiyonları Parçalamak: İsviçre Çakısı Değil, Neşter Olun

Valla ne yalan söyleyeyim, eskiden yazdığım fonksiyonlar destan gibiydi. Bir fonksiyon düşünün; önce veritabanına bağlanıyor, sonra kullanıcı doğruluyor, ardından bir dosya yüklüyor, en sonunda da e-posta atıyor. Her şey tek bir bloğun içinde. Başlangıçta bu çok pratikmiş gibi geliyor ama o fonksiyonda bir hata çıktığında veya sadece e-posta şablonunu değiştirmeniz gerektiğinde, koca bir yapbozun parçalarını dağıtmak zorunda kalıyorsunuz.

Burada devreye, yazılım dünyasının o havalı terimi Single Responsibility (Tek Sorumluluk) prensibi giriyor. Ama ben bunu teknik terimlere boğmadan, kendi hayatımdan bir örnekle anlatmayı seviyorum. Bisikletimle uzun bir rotaya çıkacağım zaman çantamı hazırlarım. Çantamda her malzemenin yeri bellidir. Çadırım ayrıdır, tamir kitim ayrıdır, ilk yardım çantam ayrıdır. İlk yardım çantasıyla bisiklet lastiği tamir etmeye çalışmam. Her şeyin tek ve net bir amacı vardır.

Fonksiyonlarımız da tıpkı bu ekipmanlar gibi olmalı. Bir fonksiyon bir roman gibi uzun uzaıya her şeyi anlatmamalı; tek bir işi mükemmel yapan kısa, net bir cümle gibi olmalı.

// Kötü: Her şeyi yapan fonksiyon
function processUser($request) {
    // 1. Veriyi doğrula
    // 2. Veritabanına kaydet
    // 3. Hoşgeldin maili at
    // 4. Log tut
}

// İyi: Parçalanmış ve odaklanmış fonksiyonlar
function registerUser($request) {
    validateUserRequest($request);
    $user = saveUserToDatabase($request);
    sendWelcomeEmail($user);
    logUserRegistration($user);
}

Bakın, ikinci örnekte kodun ne yaptığı o kadar açık ki, adeta İngilizce bir metin okuyormuş hissiyatı veriyor. Eğer mail gönderimiyle ilgili bir sorun varsa, gidip sadece sendWelcomeEmail fonksiyonuna bakarım. Diğer kod blokları umurumda bile olmaz. İşte bu, karmaşık problemleri alıp temiz ve sade sistemler kurmanın en temel adımıdır.

Yorum Satırları: Ne Yaptığını Değil, Neden Yaptığını Anlat

Gelelim kanayan yaramıza... İşin aslı şu ki; çoğu zaman yorum satırlarını, yazdığımız kötü kodu örtbas etmek için kullanıyoruz. Kod o kadar karmaşık ve okunmaz halde oluyor ki, üstüne // Burada kullanıcının yaşını 18'den büyük mü diye kontrol ediyoruz yazma ihtiyacı hissediyoruz. Eğer kodunuzun ne yaptığını açıklamak için yorum yazmak zorundaysanız, durun ve o kodu nasıl daha anlaşılır hale getirebileceğinizi düşünün.

Kod, ne yapıldığını anlatır. Yorum satırları ise neden yapıldığını anlatmalıdır. Doğal yaşam belgesellerini kurgularken de aynı mantığı güderim. Ekranda bir aslanın koştuğunu zaten görüyorsunuzdur, anlatıcının "Aslan şu an koşuyor" demesine gerek yoktur. Anlatıcı size, aslanın neden o yöne koştuğunu, rüzgarı nasıl arkasına aldığını anlatmalıdır.

Yazılımda da böyledir. Bazen dışarıdan aldığınız bir API'nin tuhaf bir bug'ı olur ve siz mecburen koda "mantıksız" görünen bir yama yaparsınız. İşte o zaman yorum satırı hayat kurtarır.

// KÖTÜ KULLANIM (Gereksiz)
// i değişkenini 1 artırıyoruz
$i++;

// İYİ KULLANIM (Nedeni açıklıyor)
// Stripe API'si tutarları kuruş cinsinden beklediği için toplamı 100 ile çarpıyoruz.
// Aksi takdirde 50 TL yerine 0.50 TL çekimi yapılıyor.
$totalAmount = $cartTotal * 100;

İkinci örnekteki yorum olmasaydı, benden sonra o koda bakan bir geliştirici (veya aylar sonraki ben), "Bu 100 de nereden çıktı, sileyim şunu" deyip bütün ödeme sistemini çökertebilirdi. Yorum satırları, kodun kendisiyle anlatılamayan "iş mantığını" veya "zorunlulukları" geleceğe aktaran küçük not kağıtlarıdır.

Gelecekteki Kendine Bir Kahve Ismarla

Bütün bu isimlendirme kuralları, fonksiyonları küçük parçalara bölme çabası ve sadece gerekli yerlere yorum yazma alışkanlığı... Bunların hiçbiri bilgisayarın kodu daha hızlı çalıştırması için değil. Bilgisayar, tek satırda yazılmış karmaşık bir spagetti kodu da aynı hızda işler. Biz bütün bu Refactoring (kod iyileştirme) süreçlerini insanlar için yapıyoruz.

Temiz kod yazmak, işi yokuşa sürmek veya gereksiz bir mükemmeliyetçilik değildir. Temiz kod, gelecekte o koda bakacak olan ekip arkadaşınıza ve en önemlisi gelecekteki kendinize duyduğunuz bir saygı borcudur.

Bilgisayarı kapatıp ormana, o sessizliğe kaçtığımda kafamın rahat olmasını seviyorum. "Acaba canlıdaki o karmaşık fonksiyon patlar mı?" korkusuyla kamp ateşi başında oturmak istemiyorum. Kodumu temiz, sade ve anlaşılır yazdığımda, dijital dünyamdaki işlerimi gerçekten ofiste bırakabiliyorum.

Eğer yazılıma yeni başlıyorsanız veya yıllardır "çalışıyorsa dokunma" diyerek kod yığınlarının altında eziliyorsanız, size tek bir tavsiyem var: İzcilerin o meşhur kuralını kodlarınıza uygulayın. "Kamp yerini, bulduğundan daha temiz bırak." Bir dosyayı açtığınızda ufak bir isimlendirme hatası mı gördünüz? Düzeltin. Karmaşık bir fonksiyon mu var? İkiye bölün. Bu küçük adımlar zamanla birleşecek ve sizi sadece kod yazan biri olmaktan çıkarıp, sürdürülebilir sistemler inşa eden gerçek bir mühendise dönüştürecektir. Unutmayın; bugün yazdığınız temiz kod, gelecekteki kendinize ısmarladığınız sıcak bir kahve gibidir.