- David J. Agans’ın Debugging kitabı, bir hata keşfedildikten sonra nedenini bulup düzeltmeye yönelik hata ayıklama temellerini ele alır; yalnızca başlangıç ve orta seviye geliştiricilere değil, deneyimli geliştiricilere de tekrar tekrar dönüp bakabilecekleri ilkeler sunar
- Kitap 9 kuraldan oluşur ve sistemi anlama, hatayı yeniden üretme, gözlem, böl ve yönet, değişiklik kontrolü, denetim izi, varsayımları kontrol etme, dış bakış açısı ve düzeltmeyi doğrulamayı pratik örneklerle ilişkilendirir
- Eski teknolojiler veya bilgisayar dışı örnekler de yer alsa da, öz belirli bir araç değil sorunu daraltmaya yönelik düşünme biçimi olduğu için donanım ve yazılım hata ayıklamasının geneline uygulanabilir
- Aralıklı sorunlar gibi ele alınması zor hatalarda Make it Fail tavsiyesi özellikle yararlıdır; ancak Heisenbug terimini doğrudan ele almaması bir eksiklik olarak kalır
- GDB kullanımı veya test yazma yöntemlerini açıklayan kitapların aksine hata ayıklamanın büyük resmine odaklandığından, araç kullanımı ve regresyon testleri ayrı kaynaklarla tamamlanmalıdır
Kitabın hedeflediği sorun
- David J. Agans’ın Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems kitabı, bir hata tespit edildikten sonra nedenini bulup gerçekten düzeltme sürecini ele alır
- Belirli bir teknoloji veya araçtan çok, yazılım ve bilgisayar donanımı geliştiricileri için gerekli hata ayıklama ilkelerini derler
- Özellikle başlangıç ve orta seviye geliştiriciler için uygundur; deneyimli geliştiriciler için de acil durumlarda gözden kaçırması kolay temel becerileri yeniden hatırlatma işlevi görür
- Deneyimle öğrenilen hata ayıklamayı ilkeler ve örneklerle yoğunlaştırarak aktarması güçlü yanıdır
9 hata ayıklama kuralı
-
Sistemi anlayın
- Kılavuzu okuyun, genel yapıyı kavrayın; temel ilkeleri ve ayrıntılı işleyişi anlayın
- Kullandığınız aracın neyi gösterdiğini ve neyi gizlediğini de birlikte kontrol edin
-
Hata vermesini sağlayın
- Sorunu yeniden çalıştırın, baştan başlayın ve hata koşullarını doğrudan tetikleyin
- Hatayı taklit etmek yerine gerçek hatayı ortaya çıkarın; aralıklı hatalara yol açan kontrolsüz koşulları bulun
- Her şeyi kaydedin, istatistiklere aşırı güvenmeyin ve nadir olayların gerçekten gerçekleşebileceğini kabul edin
- Hata ayıklama araçlarını bir kenara atmayın; sorunu görünür kılmak için kullanın
-
Düşünmeyi bırakın ve bakın
- Tahminlerle karmaşık onarımlara başlamadan önce gözlemlenebilir veriyi elde edin
- Hataları ve ayrıntıları inceleyin; iç ölçüm noktaları oluşturun veya dış ölçüm ekleyin
- Derine inmeyi ihmal etmeyin; ancak gözlemin kendisinin davranışı değiştirebileceği Heisenberg etkisine dikkat edin
- Tahminleri sonuç olarak değil, yalnızca arama alanını daraltan bir araç olarak kullanın
-
Böl ve yönet
- Ardışık yaklaşımla (successive approximation) arama alanını daraltın ve hatanın hangi tarafta olduğunu belirleyin
- Göze çarpan test desenleri kullanın ve kötü durumdan başlayarak nedeni daraltın
- İnceleme konusunu basitleştirmek için önceden bilinen hataları ve gürültüyü önce ortadan kaldırın
-
Bir seferde yalnızca bir şeyi değiştirin
- Temel etkeni ayırın ve düzeltmeden önce neyin yanlış olduğunu anlayın
- Testleri de tek tek değiştirin ve normal vakalarla karşılaştırın
- En son çalıştığı zamandan bu yana neyin değiştiğini kontrol edin
-
Denetim izini koruyun
- Neyi, hangi sırayla yaptığınızı ve sonucun ne olduğunu denetim izi olarak kaydedin
- Önemsiz görünen ayrıntılar da neden olabileceğinden olayları birbirine bağlayarak kaydedin
- Tasarım sürecinin denetim izi de testlerde yardımcı olur; mutlaka not alın
-
Fişi kontrol edin
- Doğal kabul ettiğiniz varsayımlardan şüphe edin ve en baştan yeniden kontrol edin
- Sorunu bulmak için kullandığınız aracın kendisini de test kapsamına alın
-
Yeni bir bakış açısı edinin
- Tek başınıza tıkandığınızda başka bir kişi veya farklı bir anlatım biçimi üzerinden yeni içgörüler edinin
- Sorunu bir mankene anlatmak bile düşüncelerinizi toparlayabilir
- Uzmanlıktan yararlanın, deneyimli kişileri dinleyin; gururdan çok belirtileri paylaşmayı ve yardım istemeyi önceleyin
-
Düzeltmediyseniz düzelmiş değildir
- Değişiklikten sonra gerçekten düzelip düzelmediğini kontrol edin ve yaptığınız değişikliğin gerçek nedeni ortadan kaldırdığını doğrulayın
- Sorunlar kendiliğinden kaybolmaz; hem nedeni hem de süreci düzeltmek gerekir
Örneklerin ilkeleri canlandırma biçimi
- Yalnızca kural listesine bakınca kuru görünebilir; ancak ayrıntılı açıklamalar ve vaka anlatıları ilkeleri gerçek durumlara taşır
- Birçok örnek teknik ayrıntılara kadar indiği için bazı okurlar için yorucu olabilir
- Eski teknolojileri ele alan örnekler de vardır; ancak öz belirli teknoloji değil ilke olduğu için bu büyük bir sorun değildir
- Tüm örnekler bilişimle ilgili değildir; ev tesisatıyla ilgili eğlenceli bir örnek de bulunur
- Bilgisayar donanımı ve yazılımı hakkında hiç bilginiz yoksa birçok örneği takip etmek zor olabilir
- Kural açıklamalarının ardından birden fazla kuralın birlikte uygulandığı anlatılar, okurlar için kolay alıştırmalar, yardım masası ipuçları ve kapanış sözleri gelir
Özellikle öne çıkan noktalar ve sınırlar
- “Düşünmeyi bırakın ve bakın” ilkesi özellikle önemlidir
- Çünkü birçok kişi, bir hipotezi kanıtlayacak veya çürütecek verileri toplamadan önce tahminle sorunu düzeltmeye çalışır
- “Düzeltmediyseniz düzelmiş değildir” de güçlü biçimde akılda kalan bir ilkedir
- Yalnızca değişikliğin yapılıp yapılmadığını değil, nedenin ne olduğunu ve neden düzeldiğini de doğrulamak gerekir
- “Hatayı tetikleyin, hatayı taklit etmeyin” tartışması kitabın diğer bölümleri kadar açık değildir; ancak anlaşılmaya değer bir noktadır
- Aralıklı sorunlar genellikle ele alınması en zor sorunlardır ve kitap Make it Fail bölümünde bunları ele almak için doğrudan tavsiyeler sunar
- Heisenberg’den söz eder, ancak yazılım geliştirmede yaygın bir terim olan Heisenbug konusunu ele almaz
- Heisenbug, gözlemlenmeye veya izole edilmeye çalışıldığında kaybolan ya da davranışı değişen hata anlamına gelir
Diğer kaynaklardan farkı
- Bu kitap, hata ayıklamanın temel ilkelerini merkeze almasıyla araç kılavuzlarından veya test kitaplarından ayrılır
- Richard Stallman ve diğerlerinin Debugging with GDB: The GNU Source-Level Debugger kitabı çoğunlukla belirli bir teknolojiyi veya araç komutlarını açıklar
- Norman Matloff’un Guide to Faster, Less Frustrating Debugging kaynağı gibi genel tavsiyeler içeren materyaller de vardır; ancak kapsamı Agans’ın kitabı kadar geniş değildir
- Boris Beizer’in Software Testing Techniques gibi test kitapları, hataları bulmaya yönelik test yazmaya odaklanır; bulunan hataları düzeltme yöntemlerini görece daha az ele alır
- Hata bulunduktan sonra o hataya ilişkin test regresyon test paketine eklenmelidir; ancak testler ve regresyon testleri bu kitabın kapsamı dışındadır
Tamamlayıcı kaynaklar ve eksikler
- Kitabın eşlikçi web sitesi debuggingrules.com, ilgili bilgi bağlantıları ve indirip yazdırılabilen 9 kural posteri içerir
- Kuralları anlamak için önemli olan alt kuralların tam listesinin kitapta veya web sitesinde tek bir sayfada toplanmamış olması bir eksikliktir
- Sembolik hata ayıklayıcılar, dijital lojik probları, gdb üzerinde ddd gibi yaygın araçlar ve sorun türleri hakkında daha somut tavsiye ve örnekler olsaydı daha yararlı olurdu
- Aynı kuralları bilişim dışındaki genel problem çözmeye genişleten ayrı bir kitaba da ihtiyaç var gibi görünüyor; ancak bu kitabın örnekleri bilgisayar dışı okurlar için fazla tekniktir
- Temel ilkeler dışarıdan bakınca bariz görünse de yeni başlayanların bunları öğrenmesi, deneyimli kişilerin de tekrar tekrar hatırlaması gerekir; bu kitap bu öğrenme ve hatırlatma için uygundur
1 yorum
Hacker News yorumları
Şu anda elinizdeki bozuk koda “düzeltmeler” ekleyerek onu çalışır hâle getirmeye çalışmanın en zararlı cazibe olduğunu düşünüyorum.
Bozuk kodu düzeltmek zordur; çünkü değiştirilebilecek yer sayısı çok fazladır, çalışan kodu bozmak ise çok daha kolaydır.
Bir Noel ışıkları dizisinin tamamı yanmıyorsa ampulleri tek tek değiştirme yöntemi, bozuk ampul birden fazlaysa başarısız olur.
Bunun yerine asgari çalışan örnekten başlayıp azar azar ekleme yaparak hatanın çıktığı noktayı bulmak gerekir; pratikte çoğu zaman en baştan başlamak zaman kazandırır.
Prodüksiyonda yakalanması zor bir problemde, ekipten bazıları sorunlu rutini baştan yazmıştı; diğerleri hata ayıklarken yeniden yazılmış sürüm önce dağıtıma çıktı.
En az bir kez, “düzeltilmiş” bir sorun için sınırsız zaman harcayamayacağımızdan asıl hatayı hiç bulamadık.
0 numaralı kural panik yapmamaktır.
Teslim tarihleri ve kızgın müşteriler net düşünmeyi engeller; bu yüzden güvenilir ve iyi bir yönetici, mühendisleri bu baskıdan korumalı ki problem çözmeye odaklanabilsinler.
İyi bir yönetici bizi başka bir görüşmeye aldı ve “Onların söylediklerini yok sayıp odaklanın, ben hallederim” dedi; ondan sonra o yöneticiye saygım ciddi biçimde arttı.
Doğru yapmaya zamanınız yoksa, iki kez yapmaya zamanınız olduğunu neden düşünüyorsunuz?
Bununla, mühendislerin asıl işlerine odaklanabilmesi için yukarıdan düşen şeyleri engelleme rolünü kastederdi.
Çalışan sürüme geri dönüp kriz seviyesinde baskı olmadan hata ayıklayabiliyorsanız bu çok daha iyidir.
4 numaralı “böl ve fethet” için
git bisectçok yardımcı olur.Bir tane sağlam commit ve onun ardından gelen onlarca-yüzlerce commit içinde bir kötü commit varsa, birkaç adımda sorunlu commit’i veya kodu daraltabilirsiniz.
Kullanım örneği https://nickjanetakis.com/blog/using-git-bisect-to-help-find... adresinde var.
Canlı danışmanlık sırasında, yabancı olduğum büyük bir kod tabanında bu yöntemle alanı hızla daralttım; aksi hâlde bozulmuş olabilecek kapsam çok genişti.
git bisectyüzünden “gerçek” dala giren her commit’in tek başına derlenmesi, o dönemde bilinen testleri geçmesi ve bildiğimiz kadarıyla dağıtıma uygun olması disiplinini koruyoruz.Bunu, her tuş vuruşunu saklama ya da son “Fixes.” commit’ini bile bırakma ilkesinden daha önemli görüyorum. Çünkü bu tür ilkeler ikili aramayı işe yaramaz hâle getiriyor.
Sık kullanmıyoruz ama en büyük ve en gizemli hatalarda bir kez bile tam isabet ederse, günlerce sürecek ipuçlarını tek seferde verdiği için fazlasıyla değerli.
git bisectin arkasındaki genel ilkeyi anlatmıştı.Yöntem, bozuk sistemle çalışan sistemi karşılaştırmak ve farkları sistematik olarak ortadan kaldırarak kusuru bulmaktır.
Yazılım veya donanım dışında da uygulanabilir; eskiden iki aynı jet ski varken birini tamir ederken diğeriyle karşılaştırabilmek çok işe yarıyordu.
git bisectin kendisinden çok, daha genel ikili arama ilkesidir.Yalnızca commit aralıkları için değil, sistem uzayını bölmek için de kullanılabilir.
Örneğin 10 adımlı bir iş akışı bozulduysa 5. adımın sağlam olup olmadığını kontrol edebilir ya da bunun donanım sorunu olup olmadığını daraltabilirsiniz.
Sorunun nedeni, şu anda ikili arama yaptığınız depodaki kod commit’i olmayabileceğinde bu özellikle önemlidir.
bisectharika ama bu kitabın felsefesi ve düşünme biçimi olan “kurallar” ile pratik tavsiye olan “araçlar”ı ayırmak gerekir.“Hangi aracı kullansam?” diye başlayan biri, “Bu eskiden çalışmıyor muydu?” diye başlayan birine göre dezavantajlıdır.
Dünya araçlarla dolu; tüm araçları kafanızda tutmaya çalışırsanız delirirsiniz, bu yüzden önce felsefeyi benimsemek daha iyidir.
git bisect runhakkında yazdığım yazıyı ekliyorum. Gerçekten şaşırtıcı küçük bir araç.https://andrewrepp.com/git_bisect_run
Doğru dosyayı, doğru makinede değiştirdiğinizden emin olmalısınız.
Günümüzde, doğru dosyada olup olmadığımı ve duruma göre doğru satırda olup olmadığımı doğrulamak için her zaman geçici olarak ölümcül hata üreten bir satır ekliyorum.
Değişikliğimin gerçekten etkisi olup olmadığını doğrulamak için.
Ek kurallar da var
“Hepsi benim hatam”: Derleyici hatası ya da donanım arızası da olabilir ama bunlar çok nadirdir; her şeyden önce kendi kod değişikliğimden şüphelenmeliyim
“Bir bug bulursan ailesini ve arkadaşlarını da bul”: Aynı türden şeyin başka nerelerde ortaya çıkmış olabileceğini düşünüp kontrol etmelisin
“Önce kullanıcı için, ikinci olarak bakım programcısı için, en son da bilgisayar için optimize et”
Özeti https://blog.codinghorror.com/the-first-rule-of-programming-... adresinde var
Genelde hata üreten kodu daha basit bir duruma indirgerken kendi mantığımdaki bug’ı bulurum
Bir iki kez gerçekten geliştiriciye bildirilmeye değer bir sonuç kaldı; çoğunlukla kullanıcı sayısı birkaç yüzü geçmeyen, pek fazla testi olmayan kütüphanelerdi
Sonunda imkânsız gibi görünen bir kod hatası değil, CPU sorunu olduğunu anlayınca çok rahatladım
Yine de neden-sonuç zincirini birkaç kez daha binary search ile daraltıp emin olmak en iyisi
“Sistemi anla: kılavuzu oku, her şeyi derinlemesine oku, temelleri bil, yol haritasını bil, araçları anla, ayrıntılara bak” tavsiyesi biraz tuhaf geliyor
Kodda bug varsa, önce kullandığın kütüphanenin 700 sayfalık kılavuzunun tamamını oku, ilgili 7 kitabı oku, ancak bir iki ay sonra bug’a bak demekmiş gibi görünüyor
Bu tavsiyeye gerçekten uyan tek bir programcı bile var mı merak ediyorum
Atwood ve Spolsky’nin Stack Overflow’u kurması 2008’di; insanların kitapları “Camel book” gibi adlarla bildiği ve bilgiyi öyle edindiği dönemlerdi
0. https://stackoverflow.blog/2021/12/14/podcast-400-an-oral-hi...
“Her şeyi derinlemesine oku” illa “kullandığın kütüphanenin 700 sayfalık kılavuzunun tamamını önce oku” demek değil
git bisectile ilgili bir sorun varsa, birkaç Stack Overflow parçasını yapıştırmak yerine https://git-scm.com/docs/git-bisect üzerinden konuyu biraz daha derin anlayabilirsinAma aylarca çalışmanın sonucunun tek bir bug’ı kabaca düzeltmek olduğunu düşünmek hata
Amaç, o türden bug’ların mümkün olduğunca hepsini gerçekten düzeltmek ve en baştan hiç yazılmamalarını sağlamak
Alternatif, bilmediğin bir sisteme paraşütle inip anlamadan orayı burayı kurcalamak, testler yeşile dönünce PR açıp daha fazla bozmadığını ummak; bunu rutin olarak yapmak kâbusa yakın
Ayrıca, kullandığın kütüphanenin kılavuzu 700 sayfaysa muhtemelen yanlış kütüphaneyi kullanıyorsundur
Düzeltmeden önce CI’ın başarısız olduğunu, düzeltmeden sonra geçtiğini doğrulamak gerekir
Özellikle 5 yıldan eski commit’ler olduğu ve bir bileşen/kütüphane olduğu için IE’ye yönelik epey tuhaf hack bulunduğundan
Bazı testleri yazmak uzun sürer ya da karmaşıktır ve bakım da gerektirir; test paketinin tüm sınır koşullarını kontrol edemeyeceğini de kabul etmek gerekir
Bu, production’a kadar giden bug’ın tekrar ortaya çıkabileceği anlamına gelebilir; ama basit bir hataysa, yüzlerce başka olası hatadan daha yüksek tekrar etme olasılığına sahip olmayabilir
Sonuçta duruma bağlıdır ve test yazmak bedava değildir
Derindeki nedenin yeniden aktive olup aynı sorunun tekrarladığını ya da benim düzelttiğimi kimse bilmediği için herkesin bug hâlâ varmış gibi workaround kullanmaya devam ettiğini sayısız kez gördüm
“Düzelttim!” noktasına geldikten sonra bile kısa bir kayıt ve kök neden analizi bırakmak başkalarına yardımcı olur
Testler uzun süre biriktikten sonra CI ne kadar hızlı çalıştırılabilir ve bunları uzun vadede tutmak hâlâ anlamlı mı
Bu düşünce tarzını çocuklara, kendinize ya da başkalarına kazandırmak istiyorsanız, en azından şunları öneririm
The Martian by Andy Weir https://en.wikipedia.org/wiki/The_Martian_(Weir_novel)
https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_...
https://en.wikipedia.org/wiki/The_Three-Body_Problem_(novel)
To Engineer Is Human - The Role of Failure in Successful Design By Henry Petroski
https://pressbooks.bccampus.ca/engineeringinsociety/front-ma...
https://en.wikipedia.org/wiki/Surely_You%27re_Joking,_Mr._Fe...!
Özellikle “gumption traps” kavramı güzel
Değer katılığı tuzağına düştüyseniz zaten yavaşlamak kaçınılmazdır; bu yüzden bilinçli olarak yavaşlamalı, geçtiğiniz yerlere yeniden bakmalı ve önemli sandığınız şeylerin gerçekten önemli olup olmadığını kontrol etmelisiniz
Makineye bir süre sadece bakmanın da yanlış olmadığı; oltaya bakar gibi izlerseniz küçük bir gerçeğin temkinli biçimde ilginizi çekip çekmediğini sorduğu bir anın geleceği yönündeki pasaj, neredeyse bir yaşam rehberi gibidir
Olayların sert mantık sıçramalarıyla öylece gerçekleştiğini ve aslında çok ince bir bilimsel kelime oyununu örten bir fanteziye daha yakın olduğunu düşünüyorum
Birkaç yıl önce benzer bir yazı yazmıştım. Burada bahsedilen asıl kitabı o sırada okumamıştım
https://explog.in/notes/debugging.html
Julia Evans’ın hata ayıklama zine’i de çok iyi: https://wizardzines.com/zines/debugging-guide/
Başarılı bir hata ayıklamadan sonra bile iş bitmiş sayılmaz
“Three Questions About Each Bug You Find” <http://www.multicians.org/thvv/threeq.html> yazısının özü üç soru:
Bu hata başka yerlerde de var mı, bu bug’ın arkasında saklanan bir sonraki bug nedir, bu tür bug’ları önlemek için ne yapılmalı