Clean Code

Projelerin geliştirilme aşamasında sonrası için hayat kurtarması muhtemel olan bazı dizayn prensipleri.

  • Projeleri geliştirirken kullanılan teknolojilerin dosyaları aynı uzantı ismiyle açılan paketlerde tutulması gerekir.
    • Örneğin /js yolu JavaScript dosyalarını içermeli, /css yolu CSS dosyalarını içermeli gibi.
  • Proje içerisinde değişken, fonksiyon, sınıf gibi isimlendirmeler isimlendirmeler içerik hakkında olması gerektiği kadar bilgi vermelidir.
    • Sınıf isimlendirmeleri o sınıftan oluşacak objeler hakkında, method isimlendirmeleri o methodun yaptığı iş hakkında, ne çok kısaltılmış ne de çok detaya girilmiş şekilde, görüldüğünde ne işe yaradığını belirtecek kadar bilgi barındırmalı.
    • Fonksiyon isimlendirmeleri yapacağı işlev hakkında fiil içermeli, sınıf isimlendirmeleri içermemelidir.
  • Koşul içerikleri çok komplike olmamalı, okuyanlar tarafından rahat anlaşılabilmeli.
    • İç içe koşul kontrollerinden kaçınılmalı.
  • Tekrar eden kodlardan kurtulunmalı. Örneğin eğer bir kod parçacığı ikiden fazla tekrar ediyorsa fonksiyon haline getirilmeli.
    • Fonksiyonlar karmaşık olmamalı, tek işlev için tek fonksiyon kullanılmalı.
    • Fonksiyonların parametre sayısı mümkün olan en az sayı olmalıdır.
    • Dilin sağladığı lambda fonksiyonları kullanmak bazen kodu uzun uzun yazmaktan daha anlaşılırdır.
  • Kodun içerisinde çıkabilecek hataları kontrol ederken yapılan handling operasyonlarından loglar düzgün ve anlaşılır şekilde döndürülmeli ki kodun hatası yutulmadan ve büyük problemlere sebep olmadan hata çözülsün.
  • Bir sınıf kendi objesinin özellikleri ve fonksiyonelliği haricinde işlev barındırmamalı ve olabildiğince minimal tutulmalı.
    • Sınıflar sadece bir amaca hizmet etmelidir.
  • İyi yerleştirilmiş yorum satırlarının kodu okuyanlara faydalı olmasının yanında, kodun olabildiğince yorum satırı ihtiyacı ortadan kaldırılmalı. Kodun düzeni ne kadar iyi olursa o kod o kadar az yorum satırı ihtiyacı duyar.
  • Değişkenlerin kullanılacağı yerden çok uzakta tanımlamak kodun okunurluğunu ciddi oranda düşürür.
    • Kodu okuyan insanlar sanki bir makale okuyormuş gibi okuyabilmelidir.
    • Kodun en üst kısmında algoritme ve konsept hakkında kısa bir giriş paragrafı yapılmalı.
  • Encapsulation mümkün olan her yerde uygulanmalı.
    • Modüllerin birbirilerine müdahale etmeleri kısıtlanmalı.
    • Böylelikle gevşekçe bağlı modüller üretilmiş ve kodun anlaşılabilirliği ve geliştirilebilirliği arttırılmış olur.
  • Kod üzerinde yapılan testler hızlı, birbirinden bağımsız, tekrar kullanılabilir, kendini değerlendirebilen ve zamanında yazılmış olma özelliklerine sahip olmalıdır.
  • Bir sistemi basit ve kolayca geliştirilebilir kılan özellikler şunlardır;
    • Tüm testleri başarıyla geçer
    • Kod tekrarı yoktur
    • Geliştiricinin niyeti kolayca anlaşılır
    • Sınıf ve metot sayısı minimaldir
  • Sistemde olabildiğince soyutlama kuralları uygulanmalıdır.
    • Fonksiyonel ortaklığı olmayan sınıflar birbirleriyle iletişim halinde olmamalıdır.
    • Geliştirici doğru design patternlar kullanarak modül bağımlılığını ortadan kaldırmalıdır.
  • Kodun yazılış formatına her zaman dikkat edilmelidir ki okunabilirliği en çok etkileyen faktörlerden biridir.
    • Çalışma ortamının sağladığı formatlama fonksiyonlar bu konuda oldukça faydalıdır.
  • Genel dizayn kuralları,
    • Kodun üst tabakalarında düzenlenebilir veriler tutulmalı
    • Dilin sağladığı şekilde kodun bağımlılığı azaltılmalı. Örneğin interface'ler kullanılarak ortak türler tanımlanmalı. Mantıksal bağımlılıklar doğru çalışan class'ları dahi zamanla zincirleme etkisi sonucu bozabilir.
    • Mümkün olan her yerde dependecy injection yapılmalı, tekrar tanımlamadan kaçınılmalı.
    • Dilin conventional standartları okuyanların daha rahat anlamasına yardımcı olur. Örneğin Java'da fonksiyon isimlendirmelerinin birden fazla kelime içermesi durumunda Camel Case kullanılması, Python'da ise büyük harfe yer verilmeyip birden fazla kelime içermesi durumunda alt tire karakteriyle ayrılması gibi.

15