Kokan Kod – 1. Bölüm

Söz konusu yemek olduğunda, insanlar kötü kokuları yemeğin formda olmadığının ibaresi olarak algılarlar. Aç kalmadıkça kötü koku saçan bir yemeği kimse yemez. Kötü kok yemeğin hangi durumda olduğunu gösteren bir işarettir. İnsanlar kötü kokan bir yemeğin yenmemesi gerektiğini bilirler.

Yazılımda da koku (smell) metaforu yeniden yapılandırılmaya ihtiyaç duyan kodlar için kullanılmaktadır. Kent Beck tarafından ilk kullanılan koku terimi Martin Fowler tarafından yazılan Refoctoring kitabıyla yazılım camiasında yapısal deformasyon içinde olan ve programcılar tarafından anlaşılması zor kod birimleri için kullanılır hale gelmiştir.

Kokan kod ilk etapta program hatalarına işaret etmez. Daha ziyada kokan kod terimi çalışır durumda olmasına rağmen anlaşılması ve geliştirilmesi çok zor kod birimleri için kullanılır. Kokan kod birimlerinde yapılan her yeni ekleme ile hata (bug) ihtimali yükselir. Kokan kod genelde kodun daha derinlerdeki yapısal problemlerini perdeler. Bu problemleri kesletmek için kodun yeniden yapılandırılması zaruridir.

Tasarım şablonlarında (design patterns) olduğu gibi kod kokularına isim vermek, bu konuda ortak bir kelime hazinesi oluşmasını kolaylaştıracaktır. Kod kokusunun oluştuğu durumları şu şekilde sıralayabiliriz:

• Kopyala/yapıştır yöntemiyle oluşmuş kod tekrarları (Duplicated Code)
• Uzun metotlar (Long Method)
• Birçok şeyden sorumlu büyük sınıflar (Large Class)
• Uzun metot parametre listeleri (Too Many Parameters)
• Temel veri tiplerine eğilim (Primitive Obsession)
• İç içe geçmiş karmaşık if/else/for/do/while direktifleri (Cyclomatic Complexity)
• Her şeyi yapmaya çalışan callback metotları (Ubercallback)
• Aynı sınıf bünyesinde farklı değişiklikler yapma zorunluluğu (Divergent Changes)
• Bir sınıf için diğer sınıflar bünyesinde farklı değişiklikler yapma zorunluluğu (Shotgun Surgery)
• Bir metodun kendi sınıfındaki değişkenler yerine başka bir sınıfın değişkenleri ile ilgilenmesi (Feature Envy)
• Switch komutunun kullanılması (Switch Statements)
• Paralel kalıtım hiyerarşileri oluşturulması (Parallel Inheritance Hierarchies)
• Sınıf olmayı hak etmeyen sınıflar (Lazy Class)
• Birgün belki işimize yarar sendromu (Speculative Generality)
• Belli şartlarda kullanılan sınıf değişkenleri (Temporary Field)
• Kendisine gelen metot çağrılarını başka sınıf metotlarına delege eden aracı sınıflar (Middle Man)
• Çok sıkı, fıkı olan sınıflar (Inappropriate Intimacy)
• Aynı şeyi yapan, ama değişik arayüzlere sahip olan sınıflar (Alternative Classes with Different Interfaces)
• İşini yapabilmek için değişikliğe ihtiyaç duyan kütüphane (3rd library) sınıfları (Incomplete Library Class)
• Demeter kuralına ters düşen sınıflar (Message Chains)
• Fonksiyon sahibi olmayan ve sadece veri tutan sınıflar (Data Class)
• Miras aldıkları metot ve değişkenlerin tümüne ihtiyaç duymayan alt sınıflar (Refused Bequest)
• Kötü durumdaki bir kod birimini açıklamak için oluşturulmuş yorumlar (Comments)
• İç dünyasını arayüzünün (interface) parçası olarak dışa açan sınıflar (Indecent Exposure)
• Bir şey ifade etmeyen sınıf, metot ya da değişken isimleri (Uncommunicative Name)
• Uzun sınıf, metot ya da değişken isimleri (Long name)
• Kısa sınıf, metot ya da değişken isimleri (Short name)
• Gereksiz tasarım şablonu (design pattern) kullanımı (Contrived complexity)
• Grup halinde sınıf değişkeni ya da metot parametresi olarak kullanılan nesneler (Data Clumps)

Kod kokuları ilk etapta teknik borçlanmaya işaret ederler. Kod kokularını yok etmek ve teknik borçlanmayı azaltmak için kullanılabilecek yöntemleri bu yazı dizisinde sizlerle paylaşmak istiyorum. Önümüzdeki günlerde listede yer alan her koku türünü inceleyen bir blog yazısı hazırlayacağım. Bu yazı dizisine giriş noktası olarak birinci bölüm niteliğinde olan bu blog yazısını kullanabilirsiniz.

EOF (End Of Fun)
Özcan Acar