Korkusuz Programlama Sanatı

Bir adam varmış,

Bilgisayarla büyümüş,

“Senden bi’ cacık olmaz“ demişler, üzülmüş…

TDD denen disiplini geliştirip, tüm haterlarını kalpten götürmüş.

Şaka bir yana yazılım sektöründe bazı insanlar vardır, bir şeyler öğrenmek istiyorsanız, varlığına ihtiyaç duyarsınız. Kimden mi bahsediyoruz? Kent Beck’in poker arkadaşı Ron Jeffries.

The Art of Fearless Programming

2007 yılına gidiyoruz. IEEE Computer Society dergisine bir yazı düşüyor: TDD: The Art of Fearless Programming

Ron Jeffries ve Grigori Melnik, TDD’nin yazılım projeleri üzerinde etkisini gözlemlemek için güzel bir çalışmaya imza atmış.

Bu çalışma, endüstriyel ve akademik olmak üzere iki bölümde ele alınmış. Endüstriyel katılımcılar içerisinde IBM, Microsoft ve Ericsson gibi firmaların çalışanları ve projeleri yer almakta. Akademik kısımdaysa garibim öğrencileri denek olarak kullanmışlar. Hadi çalışmalara birlikte göz atalım.

Tablo 1: Endüstriyel Çalışma Sonuçları

Tablo 1’i proje büyüklüğü, projenin yayında olma süresi, katılımcı sayısı, kullanılan programlama dilleri gibi bilgilerden arındırdığımızda TDD’nin şu etkileri göze çarpıyor:

Verimlilik Üzerindeki Etkiler: Genel eğilim, TDD’nin geliştirme eforunu artırdığına işaret ediyor. Bu, yüksek ihtimal test yazımının ek zaman maliyeti oluşturmasından kaynaklanıyor. Bazı projelerde bu maliyet %5 - 100 arasında olabiliyor. Yine de bu verilerle evrensel bir çıkarım yapmak zor; çünküm bazı çalışmalar nötr etkide olduğunu da söylüyor.
Kalite Üzerindeki Etkiler: Kalite metriklerine bakıldığında, TDD’nin hataların azaltılmasında %5 - 267 arasında olumlu etkiler sağladığı görülüyor. Bu veriler, bizlere projenin ilerleyen aşamalarında bakım maliyetlerinin düşeceği konusunda ipucu veriyor.

Tablo 2: Akademik Çalışma Sonuçları

Tablo 2’ye göz attığımızda TDD’nin şu etkileri göze çarpıyor:

Verimlilik Üzerindeki Etkiler: Bazı çalışmalar TDD uygulamasının verimliliği artırdığını gösterirken, bazılarında ise ek efor gerektiği görülüyor. Örneğin bir çalışmada %27’lik verimlilik artışı gösterilmiş, başka bir çalışmada bu etki nötr olarak değerlendiriliyor. Yüksek ihtimal bu anomaliler, TDD’nin verimlilik üzerindeki etkisinin bağlama, deneyim düzeyine ve projelerin deneysel olup olmamasından kaynaklanıyor.
Kalite Üzerindeki Etkiler: Tablo 2’de kalite üzerine etkiler hepten kafa karışıklığı içeriyor. Bazı projelerde kalitenin arttığı vurgulansa da bazılarında TDD’nin kaliteye bir etkisi olmadığı veya negatif etkisi olduğu yönünde.

TDD’nin avantajlarını toparlayacak olursak:

Üretkenlik artışı: TDD uygulayan ekipler daha hızlı ve verimli çalışıyor. İlk etapta proje maliyetlerini artırıyormuş gibi görünse de özellikle büyük projelerin ilerleyen(bakım) aşamasında kaşıkla verdiğimizi kepçeyle geri alıyoruz.
Daha az hata: TDD ile kod yazan ekiplerin projelerinde daha az hata çıkıyor.
Daha az stres, daha fazla güven: TDD, geliştiricilerin kodlarına güvenmesini sağlıyor. Testlerin erken yazılması, geliştiricilerin değişiklik yaparken kafasında soru işareti olmasını engelliyor ve daha az stresli bir çalışma ortamı sunuyor.
Ekonomik Fayda: ilk maddeyle benzerlik içerse de şöyle toparlayabiliriz; TDD başlangıçta daha fazla zaman ve maliyet gerektiriyor, ancak uzun vadede bu yöntem, daha az hata düzeltme ve bakım maliyeti ile ekonomik kayıpları telafi ediyor.
Kod kalitesi: TDD, geliştiriciyi modüler(test edilebilir) kod yazmaya zorladığı için kodun daha temiz, sürdürülebilir, anlaşılabilir ve bakımının kolay olmasını sağlıyor.

TDD üzerine kişisel düşüncelerim

Testçi olmama rağmen, yıllar önce geliştiricilerin karşılaştıkları zorlukları anlamak adına TDD disipliniyle basit bir yılan oyunu yapmıştım. Ve zorlandığım noktalar dün gibi aklımda:

Önce hata alan bir test yaz, akabinde az önce hata alan testten geçecek ürün kodu yaz, gerekiyorsa refactor et. Bunlar gerçekten zaman alan şeyler, dolayısıyla ilk etapta proje maliyetlerinin artması doğal bir sonuç gibi geldi.
Modüler ve anlaşılır kodlar yazılmasına katkı sağladığı konusunda da hemfikirim. Daha ürün kodunu yazmadan testi düşünüyorsun, test edilebilir kod demek: low coupling, high cohesion ile yakından ilişkilidir. Akabinde yazdığın testleri güzel isimlendiriyorsan, zaten kodun nasıl çalıştığını açıklayan, yaşayan bir doküman elde etmiş oluyorsun. Bence TDD buna katkı sağlıyor.
Eğer programlamayı TDD disipliniyle öğrenmediyseniz, sonradan adapte olması oldukça zor. Neredeyse düşünme biçiminiz baştan sona değişiyor. Zaten geliştiricinin başında 40 tane bela var. Bir de üstüne TDD disiplini, yetmezmiş gibi deadline baskısı, üstüne biraz da turşu.. Geliştiricilerin bu yönteme yanaşmamasını az çok anlayabiliyorum. Bu konuda deneyimli değilsen sudan çıkmış balığa dönmek mümkün. Daha yavaş iş yaparsın çünkü TDD disiplininde deneyimin yok ve pratik deilsin, bu da projede maliyet artışı anlamına geliyor.

Unutulmuş haslet (Code Review)

Bana mı öyle geliyor yoksa genellikle mi böyle emin değilim. Teste, kod kalitesine ciddi katkı sağlayan code review’ler çalakalem yapılıyor. Pull Request isteği mi geldi? Dümenden 2 dk göz gezdir, onayla gitsin… Oysa düzgün yapılan Code Review en az TDD kadar etkili. Code Review nelere katkı sağlıyor şöyle bi’ bakalım:

Hata tespiti: Başkalarının kodunu incelemek, gözden kaçmış hataların erken aşamada yakalanmasına yardımcı olur.
Kod kalitesinin artması: İyi bir code review, standartlara uygun, okunabilir ve bakımı kolay kod anlamına gelir.
Bilgi paylaşımı: Pull Request sahibiyle birlikte kodu incelemek iki ekip arkadaşının birbirine bilgi ve deneyim aktarmaları için ortam sağlar.
Daha iyi kararlar: Alternatif çözümler değerlendirilebilir, böylelikle iyi kararlar alınır.
Tutarlılığın sağlanması: Ortak kod standartları uygulanarak proje genelinde uyum yakalanır, devamlılık sağlanır.

Orta noktada buluşalım

O kadar gevezelik ettik. Büyük projelerde, test opsiyonel değil zorunluluk olduğu konusunda aynı noktadayız diye düşünüyorum.

Seni anlıyorum, TDD disiplinini uygulamak zor. Peki test yazmayacak mıyız? Tabii ki hayır, kodu yine bildiğimiz gibi yazalım, sonrasında birim testi de yazalım. Code Review süreçlerini de düzgün yaptığımızda geliştiriciler sağ, testçiler selamet.

Ron Jeffries ve Grigori Melnik’e sonsuz teşekkürler.

Bir sonraki yazıda görüşmek üzere.

Araştırma Kaynağı: https://www.computer.org/csdl/magazine/so/2007/03/s3024/13rRUygT7kK