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

Editörü açtınız, public class yazarak yeni bir sınıf oluşturdunuz. Bu sınıfa yeni bir metot eklediniz. Başka bir şey yapan yeni bir metot daha eklediniz. Sınıf yavaş yavaş şismeye başladı. Birkaç refactoring yaptınız. Buradan yeni bir sınıf dünyaya gözlerini açtı. Bir sınıf, bir sınıf daha derken sınıf sayısı onlara ulaştı. Her sınıfın metot küfesi iyice ağırlaşmaya başladı. Göz açıp, kapayana kadar birkaç bin satır kod oluştu. Program istediğiniz şekilde çalışıyor sanırım. Yaptığınız işten memnunsunuz, ama içinizden bir ses bir şeylerin doğru gitmediğini söylüyor. Eksik olan ne? Testler!

Yazılımcı neden test yazmaz? Sıralayalım:

• Uygulamayı test etme konseptlerinden bihaberdir.
• Test etmeyi gerekli ve işinin bir parçası olarak görmez.
• Test etmeyi angarya ya da zaman kaybı olarak görür.
• Geliştirdiği uygulamanın test edilemez olduğunu düşünür.
• Test etmek için zamanı yoktur.
• Daha sonra test yazarım diyerek kendini avutur.
• Testlerin yazılımcı olmayan şahıslar tarafından yazılmasını sağlamak için lobi çalışması yapar.
• Testlerin devamlı bakıma ihtiyacı olduğunu ve bu yüzden verimli olmanın önünde engel olduklarını düşünür.

Bir yazılımcının görevi nedir? Sıralayalım:

• Altına tereddüt etmeden ismini yazıp, imzalayacağı, çalışır, hatasız ve kaliteli bir sürüm ortaya koymak.
• ve daha birçok başka şey.

Yazılımcı test yazmadığı zaman ne olur? Sıralayalım:

• Devamlı oluşan hatalarla boğuşur.
• Kodu yeniden yapılandırma cesaretine hiçbir zaman sahip olamaz.
• Yeni müşteri gereksinimlerini kodlamakta zorlanır, çünkü yeniden yapılandırılamayan kodun değiştirilmesi güçtür.
• Sürüm çıkardıktan sonra birkaç gece uyuyamaz.
• Hataları gidermek için fazla mesai yapmak zorunda kalır.
• Uygulamanın her yeni sürümü ile hata sayısı çoğalır, kod kalitesi düşer.
• Yaptığı işten zevk almamaya başlar.
• İşini tam olarak yapmadığını bildiği için vicdan azabı çeker.

Veresiye satan tüccar ile peşin satan tüccarın hikayesini bilirsiniz. Veresiye satanın sonu malumdur. İşi başından sıkı tutmadığı için batma aşamasına gelir. Test yazmayan programcının da durumu aynıdır. Projenin geleceğini veresiye dağıtır.

Siz veresiye mi satıyorsunuz, peşin mi?

EOF (End Of Fun)
Özcan Acar