Joel on Software

Joel on Software   Joel'den Yazılım Üzerine

 

Diğer Türkçe "Joel on Software" makaleleri

Diğer İngilizce "Joel on Software" makaleleri

Yazara e-posta gönderin (Sadece İngilizce)

 

Sancısız Hata Takibi


Joel Spolsky
Fikret Ulug tarafından çevrilmiştir
Ozgur Aydin Yuksel tarafından düzenlenmiştir
8 Kasım, 2000

TRS-80 Seviye-1 BASIC dili A$ ve B$ olmak üzere sadece iki değişkeni tutabiliyordu. Benzer şekilde, ben de beynimde iki-hata-kapasiteli-yuva ile doğmuştum. Herhangi bir anda, sadece iki hatayı hatırlayabilirm. Eğer benden bir üçüncüsünü hatırlamamı isteseniz, hatalardan biri yere düşüp yatağın altına süpürülecek ve toz böcekleri tarafından yenip yutulacaktır.

Hataların tutulduğu bir veri tabanına sahip olmak iyi bir yazılım ekibinin kalite işaretlerinden biridir. Bu işlemi çok az ekibin yapıyor olması karşısındaki şaşkınlığım hiçbir zaman geçmemiştir. Programcıların sürekli olarak kendilerini inandırdıkları en önemli yanlış inanışlardan birisi, tüm hataları hatırlayabilecekleri veya hataları küçük not kağıtları ile takip edebilecekleridir.

Bir an için kulağınızı verip beni dinlerseniz size sancısız hata takibinin nasıl yapılacağını daha önceki iki makalemin (Sancısız zaman çizelgesi, Sancısız belirtim) ışığında anlatabilirim.

Herşeyden önce gerçek bir veri tabanına ihtiyacınız var. 2 kişiden oluşan bir ekibin uzun bir hafta sonunda yazdığı kodlar için veri tabanı olarak metin dosyası kullanımı yeterli olabilir. Bundan daha büyük ölçekli herhangi bir çalışmada gerçek bir hata takip veri tabanına ihtiyacınız olacaktır. Satın alabileceğiniz  sayısız hata takip veri tabanı var. (Bariz bir tanıtım: Fog Creek Yazılım'da geliştirdiğimiz FogBUGZ olarak adlandırılan, web tabanlı, kullanımı kolay, ve güçlü bir programız var.)

Şimdi gösterim amacıyla, ortaya çıkması ile birisinin bu hata üzerindeki sır perdesini aralaması arasında geçen süreyi takip edelim. Meşhur 1203 numaralı hatayı takip edeceğiz. Hata veri tabanı bize aşağıdaki bilgileri sunmaktadır.

 

ID: 1203
Proje: Arı kovucu 2.0
Alan: FTP İstemci
Başlık: Dosya yükleme esnasında FTP sunucusu göçüyor İlgili kişi KAPALI
Durum: KAPALI(ÇÖZÜLDÜ – DÜZELTİLDİ)
Öncelik:  2 – Mutlaka düzeltilmeli
Kimin için: 2.0 Alpha
Sürüm: Oluşturum 2019
Bilgisayar: Jill’in iMac’ı, Mac OS 9.0, 128M RAM, 1024x768 milyon renk
Tanım:                    

01-11-2000 çok çok iyi testçi Jill tarafından ortaya çıkarıldı.

* Arı kovucuyu başlat
* İçinde sadece “a” harfi içeren isimsiz bir doküman yarat
* Araç çubuğundaki FTP düğmesini tıkla
* Sunucuna ftp yapmaya çalış

HATA: Gözle; ftp sunucusu artık yanıt vermiyor. Aslında ps –augx komutu artık çalışmadığını gösteriyor ve /. dizininde hafıza dökümü var.

BEKLENEN: çökme yok

01-11-2000 çok çok iyi testçi Jill tarafından geliştirme ekibinin başı Willie’ye yönlendirildi

02-11-2000(dün) ÇÖZÜLDÜ – geliştirme ekibi başı Willie tarafından DÜZELTİLMEYECEK

Kod bizim değil bu sadece linux tarafından gelen bir proftpd.

02-11-2000(dün) Yeniden devreye alındı (çok çok iyi testçi Jill tarafından geliştirme ekibinin başı Willie’ye yönlendirildi)

Bu doğru görünmüyor. Normal bir ftp istemci ile bağlandığımda hiçbir zaman proftpd çökmedi. Bizim kodumuz her seferinde çöküyor. Ftp sunucuları durduk yere “çökmezler”.

03-11-2000(Bugün) Geliştirme ekibinin başı Willie tarafından programcı Mikey’e yönlendirildi

Mikey bu probleme bakabilirmisin? Belki senin istemci kodun biryerde yanlış yapıyor olabilir.

03-11-2000(Bugün) ÇÖZÜLDÜ -  Programcı Mikey tarafından DÜZELTİLDİ

Sanıyorum parola yerine kullanıcı adı falan gönderiyorum...

03-11-2000 (Bugün)  Yeniden yürürlüğe kondu (çok çok iyi testçi Jill tarafından geliştirme ekibinin başı Willie’ye yönlendirildi)

Oluşturum 2021’de hala aynı hata oluşuyor

03-11-2000(Bugün) Programcı Mikey tarafından yazıldı

Hayret, Bu çok ilginç. Hemen bir debug edeyim.

03-11-2000(Bugün) Programcı Mikey tarafından yazıldı

Sanıyorum MikeyStrCpy() rutininden kaynaklanıyor...

03-11-2000(Bugün) ÇÖZÜLDÜ. Programcı Mikey tarafından DÜZELTİLDİ

Ahhhh!

ÇÖZDÜM!

03-11-2000(Bugün) çok çok iyi testçi Jill tarafından kapatıldı

Oluşturma 2022’de çözülmüş görünüyor, bu sorunu kapatıyorum.

 

Neler olduğunu özetlersek.

Programcı Mikey en yeni Macintosh bilgisayarı üzerindeki yeni FTP istemci özelliği üzerinde değişiklikler yapmaktadır. Arada bir yerde, kendini iyi hissettiği için, kendi dizgi-kopyalama fonksiyonunu yazar. Bu sayede sinir bozucu yeniden kullanım polisine haddini bildirecektir. Ha ha ha!

Eğer kodunu yeniden kullanmazsan kötü şeyler olabilir Mikey. Ve işte bugün olan kötü şey, Mikey’in kopyalanan dizginin sonuna boş karakter koymayı unutması idi. Ancak çoğu zaman dizgi önceden sıfırlanmış belleğe kopyalandığı için problemi hiçbir zaman farkedemedi.

Aynı haftanın sonunda, çok çok iyi testçi Jill, kaşlarını çatmış vaziyette kodu elden geçirirken (her nedense iyi testçilerin bir çoğunun ismi Jill veya Gillian’dır) ansızın ilginç bir şey oldu: test ettiği ftp sunucusu çöktü. Evet, biliyorum bu bir linux makinesi ve linux makineleri asla çökmez. Jill sunucuya dokunmamıştı bile, sadece Mikey’in Mac kodu ile dosyaları FTP yapıyordu.

Jill çok çok iyi bir testçi olduğu için yaptığı işleri dikkatli bir şekilde adım adım kaydediyordu (örneğin onun klavyede yazarken başını hangi açıda döndürdüğü bilgisi laboratuvar defterinde yer alır). Jill bilgisayarı yeniden başlatır, temiz makine ile adımları tekrar eder – tanrım – aynı hata tekrar oluştu! Linux ftp sunuusu tekrar çöktü! Aynı gün ikinci kez oluyor gördün mü sevgili Linus.

Jill gözlerini kısarak hatayı oluşturan adımlara gözatar. Toplam 20 adım civarındadır. Bazı adımlar hata ile ilgisiz görünmektedir. Biraz deneme yaptıktan sonra, jill her seferinde aynı problemi oluşturacak dört adımı belirler. Şimdi hatayı dosyalamak için hazırdır.

Jill yeni hatayı hata takip veri tabanına girer. Şimdi, hata girişinin yapılması işlemi biraz disiplin gerektirir: hata raporlarının iyisi de vardır kötüsü de.

Her İyi Hata Raporunun Üç Parçası

Ve Tanrı konustu, dedi ki “önce kutsal iğneyi yerinden çıkartacak, sonra da 3'e kadar sayacaksın, ne fazla ne eksik. üç saydığın numara olacak. Dördü saymayacaksın, ne de ikiyi sayacaksin, ikiyi ancak üçe ulaşmak amacıyla sayacaksın. Beş asla var olmayacak. Üçe vardığında, üçüncü numara olduğundan, Antitoch'un kutsal el bombasını günahkarlara doğru atacakasın ki, benim gözlerimin önünde yaramazlık edenler, onu içlerine çekecekler.”

-- Monty Python and the Holy Grail

İyi bir hata raporu için gerekli kuralı hatırlamak oldukça kolaydır. Her iyi hata raporunun sadece üç şeye ihtiyacı vardır.

  1. Hatayı yeniden oluşturmak için gerekli adımlar
  2. Görülmesi gereken, ve
  3. Görülmesi gereken yerine ne görüldüğü

Kolay görünüyor değil mi? Belki de değil. Programcı olarak, insanlar bana parçalardan biri veya diğeri eksik hata raporları gönderirler.

Eğer bana hatayı nasıl oluşturacağımı bildirmezseniz, sizin neden söz ettiğinizi muhtemelen anlayamam. “Program çöktü ve masa üstünde kakaya benzer kokan bir cisim bıraktı.” Çok iyi tatlım. Ne yapmaya çalıştığın hakkında bir şey söylemezsen ben hiç birşey yapamam. Yeniden oluşturma adımlarını belirlemenin çok güç olduğu iki durum olduğunu biliyorum. Bazan hatırlamıyor olabilirsiniz veya “uygulama alanından” size gelen bir hatayı iletiyor olabilirsiniz. Yeniden üretim adımlarının olmamasının normal olduğu diğer bir durum hatanın bazan oluştuğu durumdur. Bu durumlarda da hatanın çok sık oluşmadığını belirterek oluşturma adımlarını sağlayabilirsiniz. Bu gibi durumlarda hatayı bulmak gerçekten çok zordur fakat deneyebiliriz.

Eğer ne görmemiz gerektiğini belirtmezseniz, bunun neden hata olduğunu anlamayabilirim. Ekrana gelen resimde kan var. Ne yapalım? Kodlarken parmağımı kesmiştim. Ne bekliyordunuz? Evet, belirtimde kan olmadığını söyleyebilirsiniz! Şimdi bunu neden hata olarak gördüğünüzü anlıyorum.

Üçüncü kısım. Görülmesi gereken yerine ne gördünüz. Eğer bana bunu söylemezseniz, hatanın ne olduğunu anlayamam. Bu kısım açıklama gerektirmiyor.

Hikayemize Dönelim

Jill hatayı kaydeder. İyi bir hata takip sisteminde hata bu projenin yöneticisine otomatik olarak atanır. Bu noktada ikinci kavram gündeme gelir: her hata, kapatılıncaya kadar, her zaman sadece bir tek kişiye atanmalıdır. Hata sıcak patates gibidir: size atandığı zaman, çözüm için sorumlusunuzdur, çözülemiyorsa bir başkasına atanmalıdır.

Ekip lideri Willie hataya bakar, bunun ftp sunucusu ile ilgili bir problem olduğunu tahmin eder ve “çözülemeyecek” olarak işaretler. Çünkü ftp sunucusunu onlar yazmamıştır.

Hata çözümlendiğinde hatayı açan kişiye geri döner. Bu çok önemli bir noktadır. Programcı öyle istedi diye rafa kaldırılmaz. Altın kural hatayı sadece açan kişinin kapatabileceğidir. Programcı hatayı çözebilir. Bu “hey, sanıyorum tamam” anlamına gelir. Hatayı kapatmak ve kayıtlardan düşmek için onu açan kişinin gerçekten çözüldüğünü onaylaması veya bir nedenle çözülemeyeceği konusunda uzlaşma sağlanması gerekir.

Jill hatanın çözümü sorumluluğunun kendisine ait olduğunu belirten bir elektronik mektup alır. Mektuba bakar ve Geliştirme liderinin yorumlarını okur. Birşeyler ters gitmektedir. İnsanlar ftp sunucunu yıllardır kullanmakta ve hiçbir çökme olmamaktadır. Sadece Mikey’in kodu kullanıldığında çökmektedir. Jill durumu açıklayan bir not ile hatayı yeniden açar ve hata tekrar Willey’e döner. Bu key Willey hatayı çözmesi için Mikey’e atar.

Mikey hata üzerinde çalışır. Uzun uzun sıkı bir şekilde üzerinde düşünür ve hatayı tamamen yanlış bir şekilde değerlendirir. Başka bir hatayı düzeltir veJill’in açtığı hatayı çözüldü olarak bildirir.

Hata tekrar Jill’e döner. Bu kez ÇÖZÜLDÜ-DÜZELTİLDİ olarak işaretlenmiştir. Jill son oluşturma ile hatayı oluşturan adımları tekrar çalıştırır, ve tanrım, linux sunucusu çöker. Hatayı tekrar gündeme getirir ve bu kez direk olarak Mikey’e atar.

Mikey’in kafası karışmıştır, ama sonunda hatanın kaynağını bulur.(Şimdi ne olduğunu biliyor musunuz? Bunu okuyucuya alıştırma olarak bırakıyorum, elinizde yeterli ipucu var!) Hatayı düzeltir, test eder ve – Evraka! Yeniden oluşturma adımları çalıştırıldığında ftp sunucusu çökmez. Bir kez daha çözer ve DÜZELTİR. Jill de oluşturma adımlarını dener, hatanın oluşmadığını görür ve hatayı kapatır.

Hata Takibi için On Önemli İpucu

1.        İyi bir testçi hatanın yeniden oluşturma adımlarını en aza indirir; bu hatayı bulmaya çalışan programcı için çok önemli bir yardımdır.

2.        Hatayı kapatabilecek tek kişinin hatayı açan kişi olduğunu unutmayın. Herhangi bir başkası çözebilir, fakat sadece hatayı ilk gören kişi hatanın düzeltilmiş olduğuna karar verebilir.

3.        Hatayı çözmenin birçok yolu vardır. FogBUGZ hatayı düzeltildi, düzeltilmeyecek, ertelendi, yeniden üretilemiyor, çift, veya tasarım hatası olarak çözümler.

4.        Yeniden üretilemiyor, hatanın kimse tarafından yeniden yaratılamadığı anlamına gelir. Programcılar hata raporunda yeniden oluşturma adımları olmadığında bu seçeneği kullanır.

5.        Sürümlerin dikkatli takip edilmesi gerekir. Oluşturulan her yazılımın bir oluşturma numarası olmalıdır. Bu sayede testçinin henüz hatayı çözmemiş oluşturma üzerinde boşuna çalışması önlenir.

6.        Eğer programcı iseniz ve testçiler hata veri tabanı kullanmıyorsa, veri tabanı dışında bir yerden hata raporu kabul etmeyin. Eğer testçiler elektronik posta ile hata raporu gönderiyorsa, postayı “lütfen bunu hata veri tabanına girin, elektronik postaları takip edemem” notu ile iade edin.

7.        Eğer testçi iseniz ve programcılar hata veri tabanını kullanmıyorsa, onlara hataları bildirmeyin hatayı veri tabanına ekleyin ve veri tabanının hatayı onlara postalamasını sağlayın.

8.        Eğer programcı iseniz ve meslektaşlarınızdan sadece bir kısmı hata veri tabanını kullanıyorsa, onlara veri tabanından hata atamaya başlayın, sonunda alışırlar

9.        Eğer yönetici iseniz ve büyük paralar harcayarak oluşturduğunuz hata veri tabanını kimse kullanmıyorsa hataları kullanan kişilere yeni özellikler atamaya başlayın. Hata veri tabanı aynı zamanda mükemmel bir “henüz uygulanmamış özellik” veri tabanıdır.

10.     Hata veri tabanına yeni alanlar ekleme isteğinize gem vurun. Hemen hemen her ay birisi veri tabanına yeni alan eklemeyi gerektirecek müthiş bir fikir ile gelir. Birçok zekice fikirler gelebilir. Örneğin, hatanın bulunduğu dosyanın takip edilmesi, hatanın yeniden oluşturulma yüzdesinin takibi, hatanın kaç kere oluştuğunun takip edilmesi, hata oluştuğu makinede hangi DLL’in hangi sürümünün kurulmuş olduğunun takip edilmesi gibi. Bu fikirlere teslim olmamak gerekir. Eğer teslim olursanız, hata giriş ekranınız doldurmanız gereken yüzlerce alan ile dolar ve kimse hata raporlamak istemez. Hata veri tabanının çalışması için, herkesin ona ihtiyacı olmalı ve hataların resmi olarak girilmesi çok uzun işlemler gerektiriyorsa insanlar hata veri tabanını pas geçerler.

Tek başınıza veya bir ekip içinde olsun, eğer kod geliştiriyorsanız, bilinen tüm hataların içinde yer aldığı organize bir veri tabanı yoksa düşük kalitede kod üretiyorsunuz demektir. İyi yazılım ekiplerinde, sadece hata veri tabanı kullanılmakla kalınmaz aynı zamanda programcılar veri tabanını kendi yapılması gerekenler listelerini oluşturmak için kullanırlar.



Bu makalenin orijinali İngilizce olarak Painless Bug Tracking başlığıyla yayımlanmıştır. 

Joel Spolski, New York şehrinde küçük bir yazılım şirketi olan Fog Creek Software'in kurucusudur. Yale Üniversitesi'nden mezun olmuş, ve programcı ve yönetici olarak Microsoft, Viacom ve Juno'da çalışmıştır.


Bu sayfaların içeriği tek bir kişinin görüşlerini yansıtır.
Her hakkı mahfuzdur. Bu sitenin bütün içeriğinin telif hakkı Joel Spolski'ye aittir. Copyright ©1999-2005

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky