Debug Nedir? Hata Ayıklama Sürecini Adım Adım Öğrenin

Bug, hata ve beklenmeyen sonuç arasındaki fark

Bug, yazılımın beklenen davranışını bozmasına yol açan kusur veya hatadır. Debugging ise yazılım davranışındaki kusurun nedenini araştırma, uygun yerde düzeltme yapma ve düzeltmeyi doğrulama sürecidir. Bu nedenle bug bir sorunun kendisini, debug ise sorunu çözmek için yürütülen çalışmayı ifade eder.

Bir programın hata vermesi her zaman ekranda açık bir hata mesajı gösterdiği anlamına gelmez. Program çökebilir, yanlış sonuç üretebilir, belirli bir girdide donabilir veya normal görünen bir sonuç üretmesine rağmen arka planda hatalı veri kaydedebilir. Örneğin 5 ve 3 değerlerinin 8 yerine 53 olarak görüntülenmesi, uygulamanın iki değeri sayısal toplama yerine metinleri yan yana ekleme biçiminde işlemesiyle açıklanabilir.

Debug sırasında ilk karşılaştırma şu iki bilgi arasında yapılır: Beklenen davranış nedir ve gerçekleşen davranış nedir? Bu ayrım yapılmadan doğrudan kod değiştirmek, gerçek nedeni gizleyebilir. Ayrıca tek bir gözlem, hatanın kaynağını kanıtlamaz. Aynı davranışın hangi girdilerde ve hangi işlem sırasından sonra ortaya çıktığını belirlemek gerekir.

Hatanın kapsamı da kaydedilmelidir. Sorun her çalıştırmada mı oluşuyor, yalnızca belirli bir değerle mi ortaya çıkıyor, yoksa belirli bir kullanıcı işlemi sonrasında mı görülüyor? Bu sorular, incelemenin tüm programa dağılmasını önler ve olası kod bölümünü daraltır.

Hata yeniden üretilemese de nasıl analiz edilir?

Hatanın yeniden üretilmesi analizi kolaylaştırır ve düzeltmenin doğrulanmasını mümkün kılar; ancak yeniden üretilemeyen hatalar da mevcut gözlem ve kayıtlar üzerinden incelenebilir. Günlükler, iz kayıtları, hata raporları ve sistem durumu gibi bilgiler; hatanın hangi koşullarda ortaya çıkmış olabileceğini anlamaya yardımcı olur. Yeniden üretme, hatayı ortaya çıkaran girdilerin, işlem sırasının ve koşulların tekrar uygulanmasıdır. Örneğin bir hesap makinesi uygulamasındaki sorun için verilenler 5 ve 3, işlem toplama, beklenen sonuç 8 ve gerçekleşen sonuç 53 olarak yazılabilir.

İzlenebilecek sıra şöyledir:

1. Hatanın görüldüğü işlemi açık biçimde tanımla.
2. Kullanılan girdileri ve işlem sırasını kaydet.
3. Mümkünse aynı adımları tekrar çalıştır ve sonucun değişip değişmediğini gözle.
4. Mümkünse daha küçük bir örnekle dene.
5. Hata oluştuğunda programın hangi aşamada bulunduğunu belirle.

Hata tekrar üretilemiyorsa bunun anlamı hatanın yok olduğu değildir. Girdi, zamanlama, veri durumu veya işlem sırası gibi bir koşul eksik kalmış olabilir. Bu durumda günlükler, iz kayıtları, hata raporları ve sistem durumu incelenmeli; rastgele kod satırları değiştirmek yerine gözlenen koşulların tamamı yeniden değerlendirilmelidir.

Beklenen ve gerçekleşen sonuçların birlikte yazılması da önemlidir. 'Çalışmıyor' ifadesi debug için yetersizdir; '5 ve 3 girildiğinde beklenen 8 yerine 53 döndü' ifadesi ise test edilebilir bir hata tanımıdır. Böyle bir tanım, düzeltme sonrasında kontrol edilecek ölçütü de doğrudan verir.

Debugger ile program akışını ve değişkenleri izleme

Debugger, programı çalıştırırken belirli noktalarda durdurmaya, adım adım ilerletmeye ve değişkenlerle yürütme durumunu incelemeye yarayan hata ayıklama aracıdır. Bu araç, yalnızca sonucun yanlış olduğunu görmekten daha fazlasını sağlar: yanlış sonuca hangi işlem sırasında ulaşıldığını göstermeye yardımcı olur. Ancak debugger altında çalışma, zamanlamayı ve çevre koşullarını değiştirebileceğinden her hata aynı şekilde gözlenmeyebilir.

İnceleme için kodun şüpheli bölümüne bir duraklama noktası, yani breakpoint konulabilir. Program bu noktaya geldiğinde çalışma durur. Ardından kod satır satır ilerletilir ve her adımda şu sorular sorulur: Değişken beklenen türde mi, değeri doğru mu, koşul beklenen dala mı yöneliyor, fonksiyona aktarılan veri değişmiş mi?

Örneğin kullanıcıdan alınan '5' ve '3' değerleri ekranda sayı gibi görünse de program içinde metin olarak tutulabilir. Debugger ile değişkenlerin değerleri ve türleri incelendiğinde, işlemden önce bu ayrım görülebilir. İki metin yan yana eklenirse '5' ve '3' birleşerek '53' olur; sayısal toplama yapılabilmesi için değerlerin sayıya dönüştürülmesi gerekir. Düzeltmenin uygulanacağı yer, kullanıcı arayüzü, veri alma bölümü veya toplama işlemi olabilir; bunun hangisi olduğu debugger incelemesiyle belirlenmelidir.

Akış incelemesinde yalnızca hatanın görüldüğü satıra bakılmaz. Verinin o satıra hangi fonksiyondan geldiği ve işlemden sonra nereye aktarıldığı da kontrol edilir. Böylece görünen belirti ile gerçek neden birbirine karıştırılmaz.

Çözümlü Örnekler: yanlış veri türü ve işlem akışı

Örnek 1 — Metinlerin sayı yerine birleştirilmesi

Verilenler:

• Kullanıcı girdisi: '5' ve '3'
• Yapılmak istenen işlem: toplama
• Beklenen sonuç: 8
• Gerçekleşen sonuç: 53

Çözüm adımları:

1. Hata tanımı yazılır: Aynı işlem tekrarlandığında 8 yerine 53 elde edilmektedir.
2. Sorun daraltılır: Sonuç, toplama işlemini yapan kod bölümünde incelenir.
3. Debugger ile işlem öncesi değişkenler gözlemlenir. Değerlerin sayısal veri yerine metin olarak işlendiği fark edilir.
4. Metin değerler sayıya dönüştürülmeden toplama işlemine sokulduğu için iki değer arka arkaya eklenmektedir.
5. Girdiler sayısal değerlere dönüştürülür ve işlem yeniden çalıştırılır.
6. Aynı test tekrarlanır: 5 ve 3 girdileriyle sonuç 8 olmalıdır.

Sonuç: Hatanın kaynağı toplama kuralının kendisi değil, toplama işlemine giren değerlerin veri türüdür. Bu örnekte debug, yanlış sonucu düzeltmekten önce verinin program içinde nasıl temsil edildiğini ortaya çıkarmıştır.

Örnek 2 — Hatanın belirli bir işlem sırasına bağlı olması

Verilenler:

• Bir uygulama, belirli bir düğmeye basıldığında kapanıyor.
• Uygulama diğer işlemlerde çalışmaya devam ediyor.
• Hata her açılışta değil, belirli işlem adımlarından sonra görülüyor.

Çözüm adımları:

1. Kapanmaya yol açan işlem sırası yazılır; yalnızca 'düğmeye basıldı' bilgisiyle yetinilmez.
2. Aynı sıra tekrar uygulanarak hata yeniden üretilir.
3. Düğmenin bağlı olduğu kod bölümüne breakpoint konur.
4. Program adım adım ilerletilir; düğme işleminden önceki ve sonraki değişken değerleri karşılaştırılır.
5. Hatanın oluştuğu kod adımı belirlenir ve o adıma gelen verinin beklenen biçimde olup olmadığı kontrol edilir.
6. Uygun düzeltme yapıldıktan sonra hem hatayı oluşturan işlem sırası hem de uygulamanın diğer işlemleri yeniden denenir.

Sonuç: Bir uygulamanın kapanması, tek başına hangi satırın hatalı olduğunu göstermez. Yeniden üretme ve akış izleme, sorunun düğmede mi, düğmenin çağırdığı işlemde mi yoksa o işleme aktarılan veride mi olduğunu ayırmaya yarar.

Düzeltme yapıldıktan sonra neden yeniden test gerekir?

Bir kod satırını değiştirmek, hatanın giderildiğini tek başına kanıtlamaz. Önce aynı hata senaryosu yeniden çalıştırılmalı ve beklenen sonuçla karşılaştırılmalıdır. 5 ve 3 girdileri için beklenen değer 8 ise düzeltme sonrasında bu sonuç gözlenmelidir.

Bunun yanında, düzeltmenin başka bir bölümü bozmadığı da kontrol edilmelidir. Bir değişiklik, hatalı girdiyi düzeltirken farklı girdilerde yeni bir soruna yol açabilir. Bu nedenle test yalnızca ilk örnekle sınırlanmamalıdır. Hatanın ortaya çıktığı koşul tekrar denenmeli, ardından ilgili işlemin normal kullanım senaryoları da kontrol edilmelidir.

Bu yaklaşım iki farklı soruyu ayırır: 'İlk bug düzeldi mi?' ve 'Düzeltme başka bir bug oluşturdu mu?' İlk soruya verilen olumlu cevap, ikinci sorunun da olumlu olduğu anlamına gelmez. Özellikle bir fonksiyonun kullandığı veri biçimi değiştirildiyse, o fonksiyona bağlı diğer işlemler de incelenmelidir.

Düzeltme sonrası aynı test adımlarının yeniden uygulanması, hata ayıklama sürecini ölçülebilir hâle getirir. Hatanın ne zaman giderildiği; tahminle değil, gözlenen sonuçla belirlenir. Bu nedenle debug döngüsü şu biçimde özetlenebilir: hatayı gözle, mümkünse yeniden üret, nedenini incele, uygun düzeltmeyi yap, aynı senaryoyu test et ve ilgili davranışları yeniden kontrol et.

Sık yapılan hatalar ve karıştırılan kavramlar

Hata mesajını neden sanmak: Hata mesajı çoğu zaman sorunun görüldüğü noktayı işaret eder; hataya yol açan asıl veri veya işlem daha önce oluşmuş olabilir. Mesaj incelenmeli, fakat yalnızca ona bakılarak kesin neden ilan edilmemelidir.

Beklenen sonucu tanımlamadan kod değiştirmek: 'Çalışmadı' ifadesi ölçülebilir değildir. Beklenen ve gerçekleşen değerler yazılmadan yapılan değişikliklerin işe yarayıp yaramadığı anlaşılamaz.

Tek bir girdiye güvenmek: 5 + 3 örneği düzeltildikten sonra yalnızca bu örneği çalıştırmak yeterli olmayabilir. Sorunun bağlı olduğu veri alma ve işlem akışı da kontrol edilmelidir.

Bug ile debug'ı aynı sanmak: Bug yazılım kusurudur; debug bu kusuru araştırma ve düzeltme sürecidir. Debugger ise bu süreçte kullanılan araçlardan biridir. Bu üç kavram birbirinin yerine kullanılmamalıdır.

Kaynak kodu ile çalışan programı karıştırmak: Kaynak kodu, programın nasıl çalışacağını tanımlayan yazılı talimatlardır. Debug sırasında genellikle bu talimatların belirli bölümleri incelenir; ancak kullanıcıya görünen hata, yalnızca ekrandaki bölümde bulunmayabilir.

Sürüm ve güncellemeyi debug sanmak: Debug, hatayı bulma ve düzeltme çalışmasıdır. Düzeltmenin kullanıcılara ulaştırılması ise bir sürüm veya güncelleme sürecinin parçası olabilir. Bu iki aşama ilişkili olsa da aynı kavram değildir.

Mutlak sonuç çıkarmak: Bir hatanın bir kez görülmesi, aynı hatanın her koşulda oluştuğunu göstermez. Hatanın geçerli olduğu girdiler, işlem sırası ve çalışma koşulları ayrıca belirtilmelidir.