‘BUG Fix’ kavramı her yazılımcının zaman içerisinde dahil olduğu, bazen lanet okuyup, sövdüğü, bazen içinden hiç çıkamadığı, bazen de problemleri çözüp,iyileştirmenin mutluluğunu yaşadığı bir süreç…Di mi? (:

Ne kadar BUG’sız uygulamalar geliştirmeye çalışsakta, günümüz şartları ve kurtulamadığımız alışkanlıklar yüzünden bu çok mümkün olmuyor. BUG olayını minimuma indirgemek adına TDD tarzı yaklaşımlar ya da unit test’lerin dikkatli yapılması gibi yazılım süreçlerinin farklı dalları için uygulama pratiği eksikliğini eminim herkes yaşıyordur.

Günümüzün getirdiği çeşitli yazılım araçları ya da TDD’ın popüler olması, geliştirme seviyesinde BUG’ları azaltmak için güzel şeyler. Ancak asıl sorun bu tarz nimetlerden bihaber yazılmış, PROD ortamlarında takır takır(?) çalışan uygulamalarda oluşan BUG’lar sanırım.

Belli süredir kullanılan ve belli bir amaça, çat pat hizmet etmiş yazılımlardaki BUG’lar, zaman içerisinde çok daha büyük sorunlara yol açabiliyor. Ne yazık ki bu bir gerçek… En nefret edilen, en korkulan senaryo da sanırım bu…Hele bir de başkasının ya da başkalarının geliştirdiği bir yazılım ise, farklı anlayış ve bakış açıları hakim ise uzak durmayı eminim bir çok kişi tercih edecektir. Bu tercihin doğruluğu ya da yanlışlığını sorgulamıyorum pek, ama BUG’lardan kurtulmak ve yeni BUG’lara yol açmamak adına bu tarz tercihlerde, iyileştirme yapmak, yanlışları görmek, tecrübe kazanmak adına pozitif yaklaşım çok önemli.

Neyse…Uzun bir giriş oldu ama bu yazıda, BUG çözmek ile ilgili bir şeyler yine saçmalıyor olacağım…

Öncelikle hata yapmak çok kötü bir şey değil…Öğrenmek ve tecrübe kazanmak için çok güzel bir yol. Bazı konularda tecrübeliyseniz, karşılaştığınız BUG’lar sizi kızdırabilir… Tecrübesiz biri yazdığı kodun nelere sebep olacağını kestiremeyebilir, tıpkı sizin ilk kod yazmaya başladığınız zamanki gibi. Dolayısıyla BUG çözerken, biraz empati ile yaklaşmak, yapılan hatalardan ders alıp, kulak arkasına atmak öncelikli bir anlayış olmalıdır. Egonuzu bir kenara koyup, soruna odaklanmak daha faydalı olacaktır…Bu ilk kural…Neyse bu kadar sosyal mühendislik yeter 😛

Bir yazılımda oluşan BUG’ları çeşitli kategorilere ayırabiliriz. Ama hepsi özünde iki farklı kategoride ele alınabilir. Sistem ve mantık…

Sistem BUG’ları, yazılımın çalışmasına engel olan, sadece yazılımdan da kaynaklanmayabilecek, kontrolsüz oluşan BUG’lardır. Mavi ekranlara, kilitlenmelere, anlamsız kapanmalara yol açan BUG’ları Sistem BUG’ları şeklinde kategorilendirebiliriz.

Mantıksal BUG‘ları ise sistemin çalışmasında bir sorun teşkil etmeyen ama beklenen ihtiyaçların karşılanamamasına sebep olan BUG’lar şeklinde tanımlayabiliriz. Yazılımın beklenmedik bir davranışı ya da yanlış üretilen bir sonuç bu BUG’ların çıktıları diyebiliriz.

Nasıl çözeriz?

Bu iki kategorideki BUG’ları çözmek farklı yaklaşımları gerektiriyor olsa da, çözmek adına iki kategoride de yapılacak ilk şey BUG’ların oluşma durumlarının tespiti olacaktır. Bunun için ilk şey, BUG’ı tekrar yaratabiliyor seviyesine gelmek olmalıdır. Tekrar yaratıp göremediğiniz bir BUG’ı çözmeye çalışmak çok anlamlı olmayacaktır zaten…

Oluşma durumlarının tespitinden sonra kodunuzu DEBUG etmeye başlayabilirsiniz. Bu noktada, tahmin ettiğiniz ya da LOG yapınızdan gelen ipuçları ile hatanın nerede olduğunu bilebileceğiniz bir durum olabilir. Ama yine de kodu DEBUG ederek, oluşan hatayı tekrar yaratın. Bu nokta, akışı ve asıl sorunun nerede olduğunu görmek adına çok önemli. Bir başka önemli nokta da hata oluştuğu zaman, yerini tespit etmenize rağmen DEBUG işleminizi durdurmamanız. Bu başta da dediğim akışı anlamak adına yine önemli bir adım. Akışı anlamak da BUG’ı düzeltirken yapılacak olan geliştirmenin etki alanını anlamak için çok ama çok önemli.

Bu DEBUG aşamasını peş peşe tekrarlamak, gereken yerlerde, TRACE ya da LOG yapılarından faydalanarak değişken ve metodları kontrol etmek kolaylık sağlayabilir.

Mantıksal BUG’ları çözmek, Sistem BUG’larını çözmekten zaman zaman daha zor olabilir. Mantıksal BUG’ları çözmek için business’ı ve domain’i bilmek gerekli olacaktır. Bu noktada analistlerden yardım almak ve belki tekrar analiz yapmak gerekecektir. Çünkü analiz aşamasındaki iletişim sorunları, yazılımcının ‘Bu BUG değil, böyle tasarlanmış,bundan böyle oluyor’ sözünün sebebi olabiliyor. Yanlış analiz, yanlız tasarım ve geliştirme yazılımcı için BUG olmasa da, kullanıcı için BUG olabilir.

Sistem BUG’larını çözmek, kullanılan geliştirme diline hakimiyet, tecrübe ve yazılım mühendisliği gibi kişisel yetkinliklere bağlı olsa da, yazılımın çalıştığı ortama, entegre bir sistem ise entegrasyon ayaklarına ve kullanıcı davranışlarına göre farklılık gösterebilir. Çözümün gerektirdiği hesaplamaları yapamayan bir ortam üstündeyse yazılımınız, yazılımdaki iyileştirmelerden önce ortamın gözden geçirilmesi çözüm için daha sağlıklı olabilir. Yazılım tarafına müdahale eterek çözmeyi planlıyorsanız da, benzer sorunlar için nasıl yaklaşımlar yapılmış, siz nasıl yaklaşımlar sunabilirsiniz şeklinde küçük bir araştırmadan sonra geliştirme yapmak sağlıklı olacaktır. Hem benzer oluşabilecek hataları öngörebilmek hem de kişisel yetkinliğinizi arttırmak adına faydalı olacaktır.

Bu iki tip BUG’ı çözerken, en önemli şeylerden biri de etki analizini iyi yapmak. Çözüm sağlarken, çözümün etkilerinin neler olabileceğini, BUG’ın başka bir BUG’ile doğru sonuç üretip, düzeltildiği zaman başka BUG’lara yol açabileceğini kestirebilmek çok önemlidir. Bu noktada – ile -‘nin +, + ile -‘nin – yapabileceğini bilmek önemli olacaktır. Ayrıca birden fazla BUG ile uğraşırken, etki analize göre bu BUG’ları öncelendirmek, çözüm adına faydalı olacaktır. BUG için geliştirmiş olduğunuz çözümü, var olan düzgün senaryoları işleterek kontrol edebilirsiniz.

Neyse çok fazla uzatmaya gerek yok…Umarım biraz bazı konularda fikir verir…