Clean Code’dan Notlar: Bölüm 1 — Temiz Kod Derken?

“Bu kitabı iki sebepten ötürü okuyorsunuz: ilki yazılımcısınız, ikincisi daha iyi bir yazılımcı olmak istiyorsunuz. Güzel, çünkü daha iyi yazılımcılara ihtiyacımız var.” diye başlıyor Clean Code’a, usta yazılımcı Robert C. Martin, ve devam ediyor:

Bu kitap iyi programlamayı anlatıyor. Bir sürü kodlama örneği olacak. Bitirdiğimiz zaman ise iyi kod ve kötü kod arasındaki farkı anlayabileceğiz. Nasıl iyi kod yazabileceğimizi ve kötü yazılmış bir kodu iyi bir koda nasıl dönüştürebileceğimizi öğreneceğiz.

80'lerde bir şirket müthiş ve çok popüler bir uygulama yazdı. Ancak bir zaman sonra yeni sürüm çıkma (release) dönemleri uzamaya başladı. Bir sonraki sürümde hatalar çözülmemiş oluyordu. Yüklenme süresi uzuyor ve çökmeler artıyordu. Büyük bir hüsran ile uygulamayı kaldırdığım günü hatırlıyorum. Zaten bir zaman sonra da şirket tamamen piyasadan çekildi.

20 yıl sonra şirketin ilk çalışanlarından biri ile karşılaştım ve ona ne olduğunu sordum. Cevabı korkularımı doğruladı. Ürünü markete erkenden sürebilmek için çok acele etmiş ve kodda çok büyük bir kargaşaya sebep olmuşlardı. Daha fazla özellik ekledikçe, kod daha da kötü bir hal almış ve o kadar kötü hale gelmişti ki, artık kodu yönetemiyorlardı. Böylece kötü kod şirketin kapanmasına sebep olmuştu.

Hepimiz zaman zaman geri dönüp kodumuzu temize çekeceğimizi söylemişizdir. Ancak o zamanlar LeBlanc’ın şu kuralını bilmiyorduk: “Sonra asla demektir (Later equals never).”

Kod karmaşıklığı arttıkça takımların verimliliği düşer ve sıfıra yaklaşır. Verimlilik düştükçe de yöneticiler yapabildikleri tek şeyi yaparlar; verimliliği artırması umudu ile projeye daha çok insan kaynağı eklerler. (İnsan kaynak mıdır yoksa değer mi?) Takımdaki herkes verimliliği artırmak için büyük baskı altındadır. Öyle ki verimliliği sıfıra daha da yaklaştıracak şekilde kod karmaşası yaratmaya devam ederler.

Peki Koda Ne Oldu?

Ne oldu da iyi kod bu denli bir hızla kötü koda dönüştü? Bunun için bir çok sebep sıralayabiliriz. Gereksinimlerin (requirements) çok fazla değiştiğinden şikayet edebiliriz. Teslim tarihlerinin (deadline) çok sıkı olduğundan da yakınabiliriz. Beceriksiz yöneticilere ya da hoşgörüsüz müşterilere de püskürebiliriz. Ancak hata tamamen bizde. Bizler profesyonel değiliz!

Kabul etmesi zor, hata nasıl bizde olabilir? Diğerleri, onların hiç suçu yok mu? Hayır. Yöneticiler taahhüt vermek için bizden birşeyler duymayı beklerler. Beklemedikleri zaman bile onlara ne düşündüğümüzü söylemekten kaçınmamalıyız. Proje yöneticileri de zamanlama için bizden birşeyler duymayı beklerler. Bu yüzden, proje planlaması ve başarısızlıklar konusunda epey suçluyuz!

“Eğer yapamazsam kovulurum!” diyorsun fakat büyük ihtimalle kovulmayacaksın. Çoğu yönetici istiyormuş gibi yapmasa bile gerçeği ister. Çoğu yönetici iyi kod ister, zamanlama konusunda takıntılı olduklarında bile. Zamanı ve gereksinimleri tutkuyla savunabilirler, ancak bu onların işidir. Senin işin ise aynı tutku ile kodunu savunmaktır.

Temiz kod yazabilmek, temizlik (cleanliness) duygusuyla uygulanmış sayısız küçük teknik yöntemlerin disiplinli bir şekilde kullanımını gerektirir. Bazılarımız bu duyguya doğuştan sahiptirler. Bazılarımız ise elde edebilmek için savaşmak zorundadırlar. Bu duygu sadece iyi ya da kötü kodu ayırt etmemizi sağlamaz, aynı zamanda kötü kodu temiz koda (clean code) dönüştürebileceğimiz stratejiyi de bize gösterir. Bu duygudan yoksun bir yazılımcı karmaşık bir modüle baktığında karmaşıklığı tanır ancak onunla ne yapacağı hakkında en ufak bir fikri yoktur. Bu duyguya sahip bir yazılımcı ise bu karmaşık koda bakar ve seçenekleri görür.

Temiz Kod Nedir?

Yapılmış birçok tanımı var. Ben de çok iyi bilinen bazı yazılımcılara ne düşündüklerini sordum:

Bjarne Stroustrup (C++’ın mucidi): Kodumun şık ve temiz olmasını seviyorum. Kodda mantık, hataların saklanmasını zorlayacak kadar düz; bağımlılıklar (dependency) bakımı kolaylaştıracak kadar minimal olmalı. Tüm istisnai durumlar (exceptions) ele alınmalı, performans optimale yakın olmalı.

Grady Booch (Object Oriented Analysis and Design with Applications kitabının yazarı): Temiz kod basit ve açıktır. Temiz kod, iyi yazılmış bir düzyazı gibidir. Temiz kod, asla tasarımcının niyetini gizlemez, daha çok berrak soyutlamalarla ve düz kontrol satırlarıyla doludur.

Dave Thomas (OTI Labs’ın kurucusu): Temiz kod, onu geliştiren yazılımcı dışında başka geliştiriciler tarafından da okunabilir ve iyileştirilebilir. Birim ve kabul testleri vardır. Anlamlı isimlendirmeleri vardır. Bir şeyin yapılması için tek bir yol vardır. Çok az bağlılığı vardır ve temiz bir API sağlar.

Michael Feathers (Working Effectively with Legacy Code kitabının yazarı): Temiz kod için bildiğim birçok özelliği sıralayabilirim; ancak bir tanesi diğer tüm özellikleri kapsıyor. Temiz kod her zaman ona değer veren biri tarafından yazılmış gibi görünür.

Peki Robert C. Martin olarak ben ne düşünüyorum? Bu kitap size tam da bunu anlatacak; bir değişken, sınıf ya da metod adının temiz olabilmesi için ne düşündüğümü yazacağım. Elbette bu kitaptaki önermelerin çoğu tartışmaya açık. Büyük ihtimalle bazılarına katılmayacaksınız, bazılarına şiddetle karşı çıkacaksınız. Sorun değil. Sadece şunu bilmelisiniz ki, bu yöntemleri onlarca yıllık tecrübeler sonucunda, birçok deneme ve yanılmamalarla öğrendim.

İlk cümlesinden itibaren yeni bakış açıları edinmemi sağlayan bu kitabı okurken aldığım notları sizlerle paylaşmasam edemezdim:

“Bu kitabı iki sebepten ötürü okuyorum: ilki yazılımcıyım, ikincisi daha iyi bir yazılımcı olmak istiyorum. Siz de buraya kadar okuduğunuza göre benimle aynı saftasınız. Güzel, çünkü hepimizin daha iyi takım arkadaşlarına ihtiyacı var.”

Sonraki bölüm: Bölüm 2 — Anlamlı İsimlendirmelerle Takım Arkadaşlarınıza Küçük Sürprizler Yapın

<:-)