Geliştirdiğiniz Yazılımın Ateşi Var, Grip ya da İdrar Yolu Enfeksiyonu Olmuş

addressbook

Varsay­alım ki, geliştirdiğiniz uygu­la­manın bir say­fasında tele­fon def­teri var. Zaman geçtikçe uygu­la­madaki istek­ler artıyor ve bir gün gelip diy­or­lar ki: “Rus pazarına giriy­oruz, tele­fon def­terindeki kayıt­lar artık Rusça da ola­cak”. Siz Rusça desteği veriy­or­sunuz (ya da zaten UTF-8’di, bir bug vardı ve düzelt­tiniz). Ardın­dan Rusça destekli tele­fon def­terini test ortamına deploy ettiniz ve şikayetler gelm­eye başladı: “Tele­fon def­ter­imiz gözük­müyor”. Siz hatayı bul­dunuz ve sorunu çözdünüz; artık hem tele­fon def­teri doğru bir şek­ilde gözüküyor hem de Rusça kayıt­lar eklenebiliyor. Artık teyit edildiğine göre bu özel­lik canlı sisteme geçebilir.

Aradan 3 ay geçti, bu sefer şöyle bir istek geldi: “Müş­ter­i­ler­imiz tele­fon def­ter­ine aynı anda toplu bir şek­ilde 10.000 kayıt ata­biliyor, bu sayının 500.000’e çık­ması gerekiyor”. İhtiyaçlar değişti, siz de kodu göz­den geçir­di­niz; belki de kul­landığınız kütüphaneleri değiştir­di­niz ve artık bir kerede aktarıla­bilen kayıt sayısı 500.000 oldu. Yine test edilmesi için test ortamına koy­dunuz, yine bir şek­ilde bir hata oluştu ve tele­fon defter­leri gözük­mem­eye başladı. Test ekibinden size iletilen mesaj şu: “3 ay önce çözülen tele­fon def­terinin gelmemesi prob­lemi tekrar mey­dana geliyor, neden önce­den çözülmüş olan bu prob­lem sürekli karşımıza çıkıyor”. Siz biliy­or­sunuz ki, ortaya çıkan hata 3 ay önceki ile aynı değil. Sorunu çözüy­or­sunuz, tekrar test ediliyor, onay­lanıyor ve canlı sis­teme aktarılıyor.

Biz de yazılım geliştirme süreç­ler­im­izin test aşa­masında buna ben­zer şikayetler alıy­oruz: “Bu sorun çözülmüştü, neden tekrar geldi”. Ben biliy­o­rum ki, bu sorun 3 ay önceki ile aynı değil, tama­men farklı bir sebepten kay­naklanıyor. Ama sonuçta test ekib­inin Adres Def­teri ile ilgili yeni özel­lik­leri göre­bile­cek­leri tek ekran, Adres Def­teri ekranı. Bu ekranın ana işlevi, Adres Def­teri'ndeki kişi­leri göster­mek olduğu için iste­nen her­hangi bir özel­liğin %90 ihti­malle adres def­terini etk­ileye­ceği malum.

Ben konuyu anlat­mak için basit bir ifade yön­temi arıy­or­dum ki bul­dum. Artık bu şek­ilde şikayetlerle gelen­lere konuyu daha iyi anla­maları için şunu söylüy­o­rum: “Sen uygu­lamının ateşi olduğunu söylüy­or­sun; ‘geçen sefer ateşini gider­miş­tiniz, neden tekrar ateşi çıktı’ diye soruy­or­sun. Oysa ateş, hastalığın sebebi değil, bir göster­gesi. Geçen sefer geliştirdiğimiz uygu­lama grip olmuştu, onu iyileştirdik ve haliyle ateşi düştü. Şimdi ise idrar yolu enfek­siy­onu olmuş ve biz de şu anda idrar yolu enfek­siy­onunu gider­m­eye çalışıy­oruz”.

Kaynak: Necati Demir


“Geliştirdiğiniz Yazılımın Ateşi Var, Grip ya da İdrar Yolu Enfeksiyonu Olmuş” için bir cevap

  1. Yazı için teşekkürler. Elinize sağlık.

    Behavior Driven Development tarzında uygulama geliştiriise, eski özellikler de otomatik olarak test edileceği için bu tür ateşi olan noktalar müşteri tarafından değil yazılım ekibi tarafından önceden bulunacaktır. Bu tür hatalar kök sebebi moduler kod yazılmaması olabilir. Yani Ali yazar Veli bozar sendromundan kurtulamak için encapsulation gibi temel prensipleri kod içerisinde uygulamamız gerektiğini düşünüyorum.

    Teşekkürler.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

This site uses Akismet to reduce spam. Learn how your comment data is processed.