Kod Kalitesi notları

Genel

  • İşinizi iyi yapınız (Motivasyon, Sahiplenme, Odak, Özen)
    • “Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor” – Steve McConnell, Rapid Development
  • Değişiklik isteklerine hazır ol.
    • “if you’re afraid to change something it is clearly poorly designed” – (Martin Fowler)
  • “2 defa ölç, bir defa kes” yaklaşımının takip edilmesi
  • İlgili kişilerin kolaylıkla anlayabileceği kodların yazılması
  • Programların çalışması yeterli değildir. Onlar, aynı zamanda kolay anlaşılabilir ve değiştirilebilir olmalıdır.
  • Kodlama ile ilgili yazılım mühendisliği kavramlarına odaklanın;
    • Tekrar kullanılabilirlik (Reusability)
    • Kolay bakım/Sürdürülebilirlik (Maintainability)
    • Genişleyebilirlik (Extensibility)
    • Test edilebilirlik (Testability)
    • Denge prensipleri (Trade-Off)
      • “Before software can be reusable it first has to be usable.”– Ralph Johnson (Computer scientist, One of the writers of famous Design Patterns Book)
  • Yazılım Kalite özellikleri
    • Doğruluk (Correctness)
    • Güvenilirlik (Reliability)
    • Sağlamlık (Robustness)
    • Performance (Performance)
    • Kullanılabilirlik (Usability)
    • Anlaşılabilirlik (Understandability)
    • Sürdürülebilirlik (Maintainability)
    • Ölçeklenebilirlik (Scalability)
    • Tekrar kullanılabilirlik (Reusability)
    • Taşınabilirlik (Portability)
    • Birlikte çalışabilirlik (Interoperability)
    • Verimlilik (Productivity)
    • Görünürlük (Visibility)

Kodlama standartları

  • Kod standartları klavuzu geliştirmeli ve takip edilmelidir.
  • İsimlendirme birinci sınıf olmalıdır. (Değişkenler, Metotlar, Sınıflar, Paketler, Veritabanı nesneleri)
  • Tek bir seçilmelidir. (Çoğunlukla İngilizce)
  • Verilen ismin, sorumluluğu net olarak açıklamalıdır. (Değişkenler, Metotlar, Sınıflar, Paketler, Veritabanı nesneleri)
    • Tek bir anlam
    • Sadece bir sorumluluk
    • Yeterince uzun olmalı
  • Kısa ve kısaltılmış isimler kullanılmamalıdır. (Yaygın kısaltmalar istisna görülebilir. (IP, DB, OS gibi)

Kod Dokümantasyonu

  • Çok fazla yorum yazmaktan uzak durulmalıdır.
    • Kod tekrar düzenlenmelidir. (Refactoring) Basit olarak, bir kod bloğu metot olarak düzenlenebilir. Kod bloğunu açıklamak yerine, iyi isimlendirilmiş bir metot aynı işi yapacaktır. Kodun tekrar kullanılabilirliği de sağlanmış olur.
    • Görüşler
      • “Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’” – Steve McConnell (author of many software engineering books including “Code Complete”)
      • “When you feel the need to write a comment, first try to refactor the code so that any comment becomes superflouus.” –  Martin Fowler, Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, don Roberts

Kodun tekrar kullanılabilirliği

  • Birbiri ile ilişkili bir grup ifade, bir metot olarak düzenlenebilir. (1. Seviye tekrar kullanılabilirlik)
  • Birbiri ile ilişkili ve bağımlı metotlar, bir sınıf olarak düzenlenebilir. (2. Seviye tekrar kullanılabilirlik)
  • Birbiri ile ilişkili ve bağımlı sınıflar, bir paket olarak düzenlenebilir. (3. Seviye tekrar kullanılabilirlik)
  • Birbiri ile ilişkili ve bağımlı paketler, bir yazılım alt yapı bileşeni (Framework) olarak düzenlenebilir (En yüksek seviye tekrar kullanılabilirlik)
  • Sınıflar arasında bağımlılıkların en aza indirgenmesi (Minimize) ve yakınlığın en yüksek seviyeye çıkarılması (Maximize), tekrar kullanılabilirliği arttırır. Diğer sağladığı avantajlar ise; Sürdürülebilirlik ( Maintainability ) ve test edilebilirlik ( Testability )
    • Yazılım paketleri için de geçerlidir.

Kodlama pratikleri

  • Sistemimiz (Fonksiyonları), yönetilebilir birimlere bölünmelidir. (Metot, Class, Package) (DRY Prensibi)
  • Her bir birimin (Metot, Sınıf, Paket), sorumluluğunu en iyi şekilde yapmasını sağlamalıdır. ( Tek sorumluluk prensibi – Single Responsibility Principle)
  • Karmaşıklık, bir birim içinde (Metot, Class, Package) gizlenmelidir.
  • Kod kopyalama yapılmamalıdır. Onun yerine, gerekli işlem bir birim içine alınmalıdır. (Metot, Sınıf, Paket)
  • Test edilebilir kod yazılmalıdır.
  • Global değişkenler kullanılmamalıdır. Her bir birim kendi verisini yönetmelidir. (Metot, Sınıf)
  • Kod içinde, sabit değişmez değerler (Literal – “Değer” veya Sayı), kullanılmamalıdır. En azından, sabit tip (Contstant) olarak belirlenmeli ve o şekilde kullanılmalıdır.
  • Hataların yönetimi (Exception) ve loglanması birinci sınıf olmalıdır.
  • Yazılım akışının (Trace) loglanması, birinci sınıf olmalıdır.
  • Bir metot içindeki kod satır sayısı 25 – 30 satırı geçmemelidir. (Bir ekrana sığacak şekilde olmalı ve kod incelemesi kolay yapılabilmelidir.)
  • Bir metoda geçirilen parametre sayısı (5-7) bandından az olmalıdır.
%d bloggers like this: