Kod kalitesini artırmanın yolları

Altuğ Bilgin Altıntaş tarafından yazıldı.   

PDF olarak oku

Yazılan kodun kalitesi ile ortaya çıkan ürünün kalitesi arasında doğrudan bir ilişki olduğunu herkes bilir ve kabul eder fakat kodun nasıl gerçek bir kaliteye ulaşacağını çok fazla kimse ilgilenmez çünkü elbette ticari kaygılar, günü kurtarma telaşları,  kod kalitesinin hep aşağıya çeken unsurlardır.

Kod kalitesini artırmak için benim gözlemlediğim bir kaç noktayı sizlerle paylaşmak istiyorum.

• Birim (Unit) test

Biliyorum çok genel bir öneri ama uygulayan şirket / kişi sayısı çok az.  Birim testleri yazmak spor yapmak gibi. Herkes spor yapmanın faydalı olduğunu bilir ama çok az kişi düzenli spor yapar. Birim testlerinde kaderi de bence aynen böyle. Birim testleri iyidir, peki yazdın mı ? Eee müşteriye yazılımı kurmaya gittim ….. ama haftaya söz yazacağım. Yazılımı müşteriye kurduysan birim testler için iş işten geçmiş demektir.

• Kodu gözler önüne serin

Günde en fazla 20 dakika, şirket içerisindeki yazılımcılar bir araya gelip planlı veya plansız (rastgele)  bir projeyi açıp hızlıca kodu inceleme yöntemidir. Şahsım adına çok faydalı bulduğum bir yöntemdir. İki faydası vardır :

1. şirket içinde kod yazma kültürü oluşturur yani bir standartlaşma getirir. Sınıf isimlerinin nasıl olması gerektiği, yordamlara nasıl isim verilmeli gibi….
2. standartlara uymamayı huy edinen kişiler için uyarı niteliğindedir. Herkesin içerisinde rencide olmayı kim ister değil mi ? Biliyorum hoş değil.

• Sürekli eğitim

Sürekli eğitim sizin ve arkadaşlarınızın ufkunuzu açar, yeni fikirlerin doğmasına sebebiyet verir. Şöyle yapabilirsiniz, örneğin Head first design patterns kitabını alın (ya da sizin  belirleyeceğiz bir kitap) ve bu kitabın içinde bölümleri arkadaşlarınızla paylaşın ve her hafta bir bölümü bir kişi en fazla 30 dakika da anlatsın.  İşte şirket kültürü !  Kodun kalitesi zaman için kesin artacaktır. Basit değil mi ?

• Yolunuzu belirleyin

Şirket içinde herkesin aynı standartlar üzerinde anlaştığına emin olun. Örneğin şirket içinde maven kullanılacaksa artık tüm yazılımcılar bu teknolojiyi yeni projelerinde kullansınlar (hatta zaman varsa eski projeleri de maven’a geçirsinler). Bu standartlaşma yeni gelen kişilerinde hızlıca şirkete uyum sağlamasını sağlayacaktır.

• Şuursuzca kod yazmayın önce biraz durun ve ….

Durun ve.. evet durun ve düşünün bir plan yapın lütfen. Başlayacağınız işin büyük resimdeki yerini tespit edin.  Sizi benim izlediğim bir yönetimi anlatmak isterim. Koda başlamadan başlamadan önce yapacaklarınızı yazın ve bir okubeni (readme) dosyası oluşturun. Bu yöntemi Tom Preston Werner‘dan öğrendim ve çok faydasını gördüm. Okubeni belgesi yazmaya başlayınca gerçekten ne kadar bilmediğiniz noktanın olduğunu fark ediyorsunuz ve koda başlamadan bu noktaları dolduruyorsunuz. Sonuç : Zaman kazancı ve daha az yıpranma. Daha ne olsun !

• En iyi araç ve yöntemleri kullanın ama amacı unutmadan

En iyi araçları kullanın, Intellij, FXCOP, Wicket, .NET, JAVA, PHP, Scala, Jprofiler…. liste uzayabilir. Bu araçların fanatiği olmak sizi çok yanlış yollara sürükleyebilir. Örneğin kodcu.com ‘da biz wordpress kullanıyoruz. Aaa ne ayıp Javacı adam kendi yazmaz mı ? Hayır bu durumda yazmaz çünkü amaç önemli (ayrıca ben fanatik değilim). Bizim amacımız yazılar yazmak ve bunu olabildiğince hızlı yapmaktı. Kaldı ki gün içerisinde kendi işlerimizle de uğraşıyoruz.  Bu yaklaşıma domain driven design deniyor. Yani adamın ihtiyacı bir çakmak ise sen gidip alev makinasıyla adamın ağzını yüzünü yakarsan bu olmaz. İhtiyaç neyse ona göre teknoloji seçmek lazım ve kesinlikle fanatik olmamak lazım.

Değinmediğim başka noktalarda var biliyorum ve şimdilik kapsamı bu çerçevede tutmak istedim.