Seri 5 - Debugging Kültürü 1

Developer’lar günün büyük çoğunluğunu kod yazarak geçirmektedirler. Yazılan her kod’un kendine göre esneme potansiyeli bulunmaktadır bu sayede farklı olasılıklar hesap edilerek çözüme ulaşılır. Peki ya data gelmiyorsa ve ya data geliyor fakat artık bazı property’ler kullanılmıyorsa. Bunun için pattern’ler kullanabilir ve sorun oluşmadan önce çözüm sağlamış olursunuz. Peki ya önlem almadıysanız ve yönettiğiniz site anlık binlerce ziyaretçi alıyorsa? Eyvahhh!

Bir an önce Bug-Fix yapmanız ve yeni bir sürümü production ortamına çıkmanız gerekiyor. Bu süre zarfında anlık ziyaretçi düşüşleriniz bir yana şirket profilinizin zedelenmesi de cabası.

Kod yazmadan önce iyi bir planlama ve detaylı test’ler ile oluşabilme ihtimali yüksek olan sorunları önceden çözmüş olursunuz.

Şimdi ise Eyvahh senaryosunu inceleyelim.

.Net developer’lar çoğunlukla Visual Studio platformunu kullanmaktadırlar. Debugging’in yanı sıra bir çok tool’u developer’lara bir kolaylık olarak sunmaktadır. Debugging konusunda da oldukça gelişmiş özelliklere sahiptir.

BreakPoint

Sadece bug-fix yaparken değil aşağı yukarı tüm kod analizlerinde kullanılan bir tool item’dır. BreakPoint tüm yazılım geliştirme platformları için ortak bir isme sahiptir.

Projeyi çalıştırdığınızda Runtime anında BreakPoint koyduğunuz noktaya kadar proje çalışır. Tam o noktaya geldiğinde bekler ve sizden bir işlem komutu bekler. Burada önemli ayrıntı; sizin nasıl data takibi ve ya kod analizi yapacağınızdır.

Projenizi çalıştırdığınızda BreakPoint devreye girerek size değişkenlerde ki datayı göstermektedir. Buradan yola çıkarak öncelikle data sorunu mu var? Mapping yanlış mı yapılıyor gibi çıkarımlar da bulunabilirsiniz.

Conditional BreakPoint

BreakPoint konusunda bazı detayları es geçmek isteyebilirsiniz. Mesela Api’den gelen data boş mu? ve ya Api dolu geliyor da biz Mapping aşamasında mı hataya düşüyoruz gibi soruları hızlı çözümlemek için Koşullu BreakPoint yöntemini kullanabilirsiniz.

BreakPoint size koşul sunmanız için imkan veriyor ve bu koşullara uyumlu bir gelişme olduğunda projeyi orada bekletiyor ve sizden komut vermenizi bekliyor. Bu sayede onlarca BreakPoint’i olan bir projede tek tek dolaşmanıza gerek kalmıyor.

Koşulları bulunduğunuz satırdan önceki işlemler için ve ya bulunduğunuz satırda ki değişken’e önceden veri set edildiyse bunun için de koşul belirtebilirsiniz.

Matches listesinin Count’u benim için bir önem arz ediyor diyelim ve 200'den fazlası için beni uyar ve orada çözüm arayalım. Bu koşul

Koşul çalıştı ve BreakPoint devreye girdi. Artık Bug-Fix yapmak size kalmış :)

BreakPoint’leriniz bir kaç tane olduğunda pek problem değil, ekip arkadaşınızla bunu paylaşabilirsiniz x.cs’de 298. satıra BreakPoint koy koşuluda şu olsun demek kolay. Peki ya proje genelinde 500 BreakPoint’iniz bulunuyorsa? Ekip arkadaşlarınıza bunu nasıl dağıtacaksınız?

Visual Studio bunun için Import/Export yöntemi ile tüm BreakPoint’leri XML bir dosya’da Export etmenizi sağlıyor. Daha sonra bu XML’leri Import ederek Proje geneline XML içerisinde ki işaretlenmiş noktalara tüm detayları ile(Koşullar v.b) dağılıyor.

Hit Count

Gelelim zurna’nın Zzzzzzzzz dediği noktaya :) BreakPoint iyi güzel hoş şey ama benim bir for döngüm var uffff. 500 Bin data işliyor ve ben 289.854. datayı nasıl yakalıcam? Kodun içerisinde count verip döngü’ye her girdiğinde +1 yapıp. Sonra o count’u bir if yardımıyla (count == 289.854) ile koşullandırıp o satıra mı BreakPoint eklicem?

Yok be kardeşim, BreakPoint senin ne düşündüğünü bilmek istiyor. Bana dur de durayım diyor alenen, Bir BreakPoint’i konumlandırdığında Koşul belirtirken Hit Count seçtiğinde vermiş olduğun değer misli (Ben 50 vermişim) sayıyor ve 50. çalışma anında hoooop dur bakalım diyor :)

Senin artık If yazıp Count tutmana gerek kalmıyor.

Autos, Locals, Watch, Immediate Window, Call Stack

Debugging yaparken farketmiş olmalısınız. Sadece Debugging anında ortaya çıkan bazı pencereler var ve proje durduğu anda hoop ortadan kayboluyorlar :) Hadi biraz inceleyelim.

Autos ve Locals

Autos ve Locals arasında çok fark olmasa da bir kaç ayırt edici özellikleri bulunuyor.

Autos, O an bulunduğunuz değişken’in dokunduğu akraba değişkenleri yakalıyor. Locals ise BreakPoint adımına gelene kadar o Action anında değişkenleri ve değerlerini yakalıyor.

Watch

Takip etmek güzel bir şey evet bunu hepimiz biliyoruz. Peki değişkenim de nasıl data’lar var ve ben sorular yazarak ve ya wizard kontrolleri ile data’larım arasında nasıl gezerim. Watch bu sorunuza cevap oluyor :)

Ekran’da ki gibi değikeninizin üzerine gelerek Add Watch dediğiniz de size Watch ekranı değişkeninizin dataları ile wizard halinde geliyor. Burada istediğiniz gibi data’larınızı kontrol edebilirsiniz.

Immediate Window

Benim çok sık kullandığım bir Tool Item’dır. Runtime anında BreakPoint ile kırılım oluşturduktan sonra bu alana gelerek Intellisense ile kod yazabilir, değişkenlerin değerlerini görebilir ve yeniden değer set edebilirsiniz.

Liste içerisinde sorgulama yaparak bir Property değeri elde etmek istediğiniz zaman bunu Immediate Window’da gerçekleştirebilirsiniz. Kısacası istediğiniz kodu burada çalıştırabilirsiniz :)

Call Stack

Heh tamam işte bu en sevdiklerimden biri :) BreakPoint yaptım yapmasına ama bu metodu çağıran 250 yer var hangi birinden geldi bu acaba. Call Stack sizin için bunu takip ediyor.

Debugging konusunu seri olarak düşünüyorum. Tüm konuları detaylı olarak anlatmak gerekiyor. Serimizin bir sonraki yazısında görüşmek üzere..