Deneme Yanılmanın Bedeli

Yazılım yaparken en büyük zaman kaybının nedeni, kodu değiştirip, derleyip, çalışır hale getirdikten sonra değişikliğin sonucunu test etmektir. Kodu değiştir/derle/çalıştır/dene süreci otuz saniyeden beş dakikaya kadar sürebilir. Günde bunu on sefer yaptığınızda bir saatlik bir zamanı boşa harcamış olursunuz. Bu sebepten dolayıdır ki EJB2 ve benzeri teknolojilerin yerine Spring gibi daha hafif yazılım yapmayı sağlayan çatılar (framework) oluşmuştur.

Çoğu programcı yılmadan kodu değiştir/derle/çalıştır/dene döngüsünde programlamaya devam ediyor. Büyük bir inatla, akıl almaz derecede komplike olan algoritmaları deneme, yanılma usulü ile geliştirmeye ya da değiştirmeye çalışanlar var. Neymiş efendim, bir sonraki döngüde çalışacakmış… Murphy’nin kuralları gereği yapılan değişikliğin beklenen neticeyi getirmeme ihtimali çok yüksek. Ve böylece programcı hiç farkına bile varmadan dönme dolap içinde dönüp, duran bir fare misali hayatını devam ettirir….

Aslında böyle durumlarda beyinde tehlike çanları çalmaya başlayıp, programcının içinde bulunduğu kısır döngüyü aşması için gerekli rutinlerin çalışması gerekir. Mesela bu rutinlerden bir tanesi “hemen kodu test eden bir birim testi yaz” olabilir. Bir birim testi bahsi geçen kod birimini izole edilmiş halde çok hızlı bir şekilde test etmek için kullanılabilir. Yapılan değişikliğin neticesini görmek bir saniye bile sürmeyecektir. Gerekli değişiklikler yapıldıktan sonra ayrıca bonus olarak bir birim testine sahip olunur. Daha sonra yapılması gereken değişiklikler birim testi sayesinde çocuk oyuncağı haline gelir. Zaman ayrılıp, mutlaka böyle bir yatırım yapılmalıdır, aksi taktirde deneme, yanılma tarzı programlamanın bedeli çok daha ağır olacaktır. Sözüm tabi verimliliğim düştü derdinde olmayanlara değil.

“Hemen test yaz” vari bir rutinin devreye girebilmesi için iki şeye ihtiyaç duyulmaktadır:

  • Böyle bir rutine sahip olmak.
  • Rutini zamanı gelince otomatik olarak tetiklemek.

Bu rutini çalıştırabilmek için bu rutine sahip olmak gerekiyor. Böyle bir rutine nasıl sahip olunabileceğine Kod Kata ve Pratik Yapmanın Önemi başlıklı yazımda değinmeye çalıştım. Bu işin sırrı devamlı pratik yapmaktan geçiyor. Pratik sahibi olan bir programcının aklına ilk gelen şey “ya ben neden bir birim testi yazmıyorum da, burada taklalar atıyorum” olur. Basit gibi görünen bu beyin performansını sağlayabilmek için beyni bu yönde eğitmek gerekiyor. Bunun yolu da kod katalarından geçiyor. KodKata.com‘a bir göz atmanızı tavsiye ederim.

Deneme, yanılma tarzı programlama hem insanı yorar, hem usandırır, hem de bir zaman sonra bıkkınlık verir. Ayrıca bu tarz programlamanın yazılım mühendisliği ile yakından, uzaktan ilgisi yoktur. Mühendis olmak demek yol, yordam bilmek demektir, metotlu, yöntemli çalışmak demektir. Çaylak gibi bilgisayar başına geçip, deneme, yanılma tarzı programlama yapan yazılımcıya gülerler. Profesyonel programcı hemen çekmecesinden ihtiyaç duyduğu aracı, yani birim testi yazma yetisi, çıkarır ve sorunu en kısa sürede daha önce etkinliliği milyarlarca defa kanıtlanmış bir yöntemi kullanarak çözer. Yol, yordam bilmek budur. Profesyonel yazılımcıya yakışan budur.

EOF (End Of Fun)
Özcan Acar

Share Button
0.00 avg. rating (0% score) - 0 votes

One Comments

  • Ömer ÖZKAN

    09 Kasım 2012

    Ellerinize sağlık hocam güzel bir yazı daha. Kod kata yapmaya yaklaşık 3 ay önce başlamıştım. 3 ay önceki yazdığım kodlarla şu anki yazdığım kodlar arasında dağlar fark var. Ayrıca katalar sayesinde TDD nin güzelliğini görmekle kalmayıp, kötü kodu artık daha hızlı farkedebiliyorum (kendi seviyemde). Şu anda elimden geldiğince farklı katalar da yapmaya çalışıyorum. 3 ay önce kata yapmaya başladığımda bu kadar etkisi olduğunu tahmin etmiyordum. TDD’nin henüz başındayım ama kendimi kod yazarken eskisine göre çok rahat hissediyorum. Bunu söylemek bana düşer mi bilmyorum ama bence TDD olmazsa olmaz.

Bir Cevap Yazın