Temiz Kod Prensipleri (Clean Code Principles) Bölüm 1

Temiz kod kavramının tanımını yaparak başlayalım. Temiz kod yazılan kodun anlaşılması ve üzerinde yeni geliştirmeler yapılması kolay olan, okuyucu odaklı bir geliştirme biçimidir. Bir projeye başlarken geliştirme hızının genellikle yüksek olduğu hepimizin malumudur. Projeler büyüdükçe hantallaşır ve bu bağlamda hareket kabiliyetini kaybetmeye başlar. Yeniliklere adapte olarak yeni özellikler sunabilmek, çıkabilecek muhtemel sorunları giderebilmek gibi birçok ihtiyaç doğar. Bunun yanı sıra ekiplerin değişmesi ve büyümesiyle birlikte kodların okunaklı ve temiz yazılmış olması birim zaman maliyetinde çok ciddi bir tasarrufa neden olacaktır. Böylece geliştirilebilirlik ve devamlılık özelliği sağlanmış olur.

Temiz kod, basit ve nettir. Temiz kod, iyi yazılmış bir düz yazı gibidir. Grady Booch

Geliştirilen projelerde genellikle kod temizliğinin çok önemli olmadığı düşünülmektedir. Geniş bir çerçeveden baktığınız zaman bu büyük bir yanılgıdır. Bunun arkasında yatan neden genellikle müşterilerin kodun temizliğini değil dönen çıktıyı görüyor olması ve temiz koda dikkat edilmesi durumunda sürenin uzamasıdır. Bu fikirde gözden kaçırılan unsur sistemlerin hiçbir zaman tam olarak bitmemiş olmasıdır. Yazılım projeleri yaşayan bir varlıktır ve sürekli gelişime, değişime açtır. Teknolojinin bu kadar hızlı değiştiği bir dünyada gerek rakiplerinizin gelişimleri, gerek müşteri talepleri sürekli sisteminiz üzerinde yeni geliştirmelerin gereksinimini doğurmaktadır. Temiz yazılmamış bir sistemde yeni geliştirmelerde kaybedeceğiniz zaman, başında kaybedeceğiniz zamana göre oldukça maliyetli olacaktır. Ve şunu gözden kaçırmamalıyız. Yeni bir özellik beklentisi olan müşteri, zaman bakımından sizi daha çok strese sokacak ve geliştirme hızınızın yavaş olması müşteri memnuniyetini de derinden etkileyecektir.

Herhangi bir aptal bilgisayarın anlayabileceği kod yazabilir. İyi programcılar insanların anlayabileceği kod yazar. Martin Fowler — Refactoring

Kendi geliştirmiş olduğumuz projelere uzun zaman sonra baktığımızda, yazılmış olan koda yabancılaştığımız ve ne yaptığımızı anlamak için epeyce zaman harcadığımız olmuştur. Burada temel sebep temiz kod prensiplerine uygun programlama yapılmamış olmasıdır diyebiliriz. Burada karşımıza bir soru çıkıyor. Makalenin bu aşamasına kadar teorik olarak bahsetmiş olduğumuz “temiz kod” kavramına nasıl uyarız?

1. İSİMLENDİRME
   Yazılım alanında değişkenler, sabitler, fonksiyonlar, sınıflar, paketler gibi tüm nesnelerin isimleri vardır. İsimlendirmelerin temiz kod prensiplerine uygun olarak açıklayıcı ve anlaşılır yapılması gerekmektedir. Doğru isimlendirme, yorum satırlarına ve detaylı kod incelemelerine gerek duymadan ilgili kodun anlaşılmasını sağlayacaktır. Tüm nesnelerin isimlendirilirken belirlenmiş bazı kuralları vardır.

• Değişkenler ve sabitler gibi içerisinde veri barındıran yapılar isimlendirilirken, içerisinde barındırdığı verinin ne olduğu ile ilgili net ve açıklayıcı sıfatlarla isim öbeklerinden oluşan kısa ifadeler kullanılmalıdır. (Örnek : customerName, userData)
• İsimlendirme yapılırken daha sonra okunmasını zorlaştıracak gereksiz kısaltmalardan kaçınılmalı ve telaffuz edilmesi kolay olan isimler kullanılmalıdır.
  ( Kötü Örnekler : d (day), hp (hipotenüs )
• Fonksiyonlar isimlendirilirken ilgili işlevin ne yaptığını net ifade eden fiiller ve fiil öbeklerinden oluşan kısa ifadeler kullanılmalıdır.
  ( Örnek : sendMessage )
• Fonksiyonları isimlendirirken tutarlı olunmalıdır. Örnek olarak veri getirmek için bir yerde get ön eki kullanılıyor ise bir başka yerde fetch kullanılması tutarlı olmayacaktır. Aynı konseptte işler için aynı kelime ön ekleri seçilmelidir.
• İsimlendirme yapılırken aranabilir kelimeler kullanılmalıdır. Örnek olarak kısaltma olarak kullandığınız d(day) değişkenini düşünelim. Doküman içerisinde kullanıldığı yerleri bulabilmek için “d” olarak arattığınızda birçok satırda sonuç bulunacaktır ve aranabilirlik özelliğiniz kaybolacaktır.
• Sınıflar isimlendirilirken isim veya isim kelime öbekleri kullanılmalıdır. Sınıf isimlerinde fiil kullanılmamalıdır.
  ( Doğru Örnek : User, Yanlış Örnek : Manager, Data)

2. FONKSİYONLAR

Fonksiyonlar yazılımın temel taşıdır. Fonksiyonların içeriği ilgili belirlenmiş olan bazı temiz kod prensipleri vardır.

• Fonksiyonlar kısa olmalıdır. En uç senaryoda bile satır sayısı 20’yi aşmamalıdır. Uzayan fonksiyon içerikleri mümkün olduğu kadar parçalanarak fonksiyonlara ayrılmalıdır.
• Her fonksiyonun yalnızca tek bir işlevi olmalıdır. Tek bir işlevi olmayan fonksiyonlar parçalanmalıdır.
• Switch koşulları kullanılan durumlarda case sayısı sürekli artabileceğinden sorunlara yok açar. Bu koşulda fonksiyonların içerisinde kullanmak yerine sınıflar içerisinde polymorphism(çokbiçimlilik) ile kullanılması daha uygun olacaktır.
• Fonksiyonlar en uç durumda bile 2 parametreden fazla almamalıdır. En optimum seçenek hiç parametre almamasıdır.
• Try Catch blokları kullanırken try catch komutları fonksiyonun içerisinde değil fonksiyonun çağırıldığı kapsayıcı bir hata ayıklama fonksiyonu içerisinde kullanılmalıdır.
• Kod tekrarından mutlak surette kaçınılmalıdır.
• Koşul durumları ve döngülerin içeriği genellikle tek satırdan oluşmalı ve bu satırda da ilgili işlemi yapacak fonksiyon çağırılmalıdır.

3. YORUM SATIRLARI

Temiz kod prensiplerine göre kod genellikle kendisini yorum satırlarına ihtiyaç duymadan kendini ifade edebilir ve anlaşılabilir olmalıdır. Ancak burada bazı istisnai durumlar vardır.

• Kodların üzerinde geliştirici bilgilerinin paylaşıldığı yorum satırları kullanılabilir.
• Regex filtreleme yapılan yerlerde ilgili filtrelemenin ne tür bir sonuç beklediğini yorum satırı olarak ifade edebilirsiniz.
• Kodlar içerisinde daha sonra yapılacak olan geliştirmeler ile ilgili TODO yorumları ekleyebilirsiniz.

4. SINIFLAR

Sınıflar yazılım mimarisinin önemli unsurlarından biri olarak yazılım kalitesinde önemli bir yere sahiptir. Sınıflar ile ilgili bazı prensipler aşağıda listelenmiştir.

• Sınıfların içeriği mümkün olduğu kadar kısa olmalıdır.
• Sınıflar SRP(Single Responsibility Principle) prensiplerine uygun kullanılmalıdır. Yani her sınıfın yalnızca bir sorumluluğu olmalıdır.

Örnek
public class Version {
public int getMajorVersionNumber()
public int getMinorVersionNumber()
public int getBuildNumber()
}

• Sınıflar az sayıda iç değişkene sahip olmalıdır. İçerdiği metodlardan her biri değişkenlerden bir veya daha fazlasını işlemelidir. Değişkenler birçok yöntem tarafından kullanılmadığında farklı sınıflara bölünme ihtiyacı doğmuş demektir.
• Yazılım yaşayan bir sistemdir. Sürekli gelişmesi gerekir. Bu bağlamda, yeni yapılacak olan değişikliklerin önceki işlevlerin yanlış veya eksik çalışmasına yol açmaması gerekir. Sınıflar bu değişimde yaşanacak olan riskleri azaltacak şekilde dizayn edilmelidir.

Yazının bu bölümünde Temiz Kod Prensiplerinin ilk 4 maddesi olan İsimlendirme, Fonksiyonlar, Yorum Satırları ve Sınıflar konularının açıklaması yapıldı. İkinci bölümde Hata Yönetimi, Yatay ve Dikey Formatlama, Birim Testleri , Eşzamanlılık ve Kodun Temizliğinin Anlaşılması konuları anlatılacaktır.