En etkili kod hata ayıklama nasıl yapılır? [kapalı]

Kodda sürünen hatalar en aza indirgenebilir, ancak yazıldığı gibi tamamen ortadan kaldırılamaz - programcılar çoğu aynı fikirde olmasa da , sadece insanlardır.

Kodumuzda bir hata tespit ettiğimizde, onu yok etmek için ne yapabiliriz? Değerli zamanımızı en etkin şekilde kullanmak için nasıl yaklaşmalı ve onu bulmaya çalışırken daha az zaman harcayacağımızı ve zaman kodlamasını nasıl yapmalıyız? Ayrıca, hata ayıklama sırasında nelerden kaçınmalıyız?

Burada, hataları önlemekten bahsetmediğimizi unutmayın ; Biz böcek ne yapacağını bahsediyoruz do görünür. Bu geniş bir alan, biliyorum ve dile, platforma ve araçlara çok bağlı olabilir. Eğer öyleyse, zihniyetler ve genel yöntemler gibi cevapları kapsamaya devam edin.

Zihniyet ve hata ayıklamaya karşı tutum belki de en önemli kısımdır, çünkü hatayı ne kadar etkili bir şekilde düzelteceğinizi ve ondan ne öğreneceğinizi belirler - eğer varsa.

Pragmatik Programcı ve Kod gibi yazılım geliştirme üzerine klasikler Tamamen temelde aynı yaklaşımı savunurlar: her hata hemen hemen her zaman kendin hakkında öğrenme fırsatıdır (çünkü yeni başlayanlar ilk önce derleyiciyi / bilgisayarı suçlarlar).

Öyleyse, kırması ilginç olacak bir gizem gibi davran. Ve gizemimizi, varsayımlarımızı (kendimize ya da başkalarına) ifade ederek ve sonra varsayımlarımızı tek tek test ederek, gerektiğinde birer birer - elimizdeki her aleti, özellikle hata ayıklayıcıları ve otomatik test çerçevelerini kullanarak çözmemiz gerekir. Sonra gizem çözüldükten sonra, yapmış olabileceğiniz benzer hatalar için tüm kodunuzu inceleyerek daha da iyisini yapabilirsiniz; ve hatanın bilmeden tekrar yapılmayacağından emin olmak için otomatik bir test yazın.

Son bir not - "hatalar" yerine "hatalar" demeyi tercih ediyorum - Dijkstra meslektaşlarını ikinci terimi kullanmaları için gruplandırdı, çünkü sahtekarlık yapıyordu; t Kendi (özensiz) düşüncelerimiz yüzünden orada olmak yerine, bakmak: http://www.cs.utexas.edu/users/EWD/transentations/EWD10xx/EWD1036.html

Örneğin, artık bir hataya bir hata diyerek değil de bir hata diyerek dilimizi temizlemeye başlayabiliriz. Çok daha dürüsttür çünkü suçlu olduğu yere suçlu koyar, viz. hatayı yapan programcı ile. Programcı bakmazken kötü niyetli bir şekilde gizlice girmiş olan hatanın animasyon metaforu, hatanın programcının kendi yaratması olduğunu gizlediği için entelektüel olarak aldatıcıdır. Kelime haznesindeki bu basit değişimin güzel yanı, böyle derin bir etkiye sahip olmasıdır: daha önce, sadece bir hataya sahip bir program "neredeyse doğru" idi, daha sonra bir hataya sahip bir program sadece "yanlış" dı. hata).

1. Testleri yaz. Test yapmak sadece hataları önlemede harika değildir (benim deneyimime göre, TDD doğru yapılmış, neredeyse tüm önemsiz, aptalca böcekleri ortadan kaldırır), aynı zamanda hata ayıklamada da çok yardımcı olur. Test yapmak, tasarımınızı oldukça modüler olmaya zorlar; bu da sorunun yalıtılmasını ve çoğaltılmasını kolaylaştırır. Ayrıca, çevreyi kontrol edersiniz, böylece daha az sürpriz olur. Dahası, başarısız bir test vakası aldıktan sonra , sizi rahatsız eden davranışın asıl nedenini çivilediğinizden emin olabilirsiniz .

2. Hata ayıklayıcısını nasıl kullanacağınızı öğrenin. printifadeler bir düzeyde makul derecede iyi çalışabilir, ancak çoğu zaman bir hata ayıklayıcı çok yardımcı olur (ve nasıl kullanılacağını bir kez bilirseniz, printifadelerden çok daha rahat olur ).

3. Sorun sadece bir lastik serseri olsa bile, birileri hakkında konuş . Üzerinde çalıştığınız sorunu kelimelerle ifade etmeye zorlamak gerçekten mucizeler yaratıyor.

4. Kendine bir zaman sınırı ver. Örneğin, 45 dakika sonra hiçbir yere gitmediğinizi düşünüyorsanız, bir süre diğer görevlere geçin. Böceğinize geri döndüğünüzde, umarız daha önce göz önünde bulundurmayacağınız diğer olası çözümleri görebileceksiniz.

Bir böceğin çoğaltılmasının da önemli olduğunu düşünüyorum. Hatayı yeniden oluşturan tüm durumlar listelenebilir ve ardından hata düzeltmenizin tüm bu vakaları kapsadığından emin olabilirsiniz.

Bu konuda okuduğum harika bir kitap var. Neden Bilimsel Yöntemi uygulamaktan, bir hatayı çözmek ve bir hata ayıklamaya kadar çeşitli hataları bulmak için çeşitli stratejiler belirleyen Why Programs Fail . Bu kitabın diğer bir ilginç yanı ise 'böcek' teriminden uzaklaşmasıdır. Zeller'in yaklaşımı:

(1) Bir programcı kodda bir hata yaratır. (2) Kusur enfeksiyona neden olur (3) Enfeksiyon yayılır (4) Enfeksiyon başarısızlığa neden olur.

Hata ayıklama becerilerinizi geliştirmek istiyorsanız, bu kitabı şiddetle tavsiye ediyorum.

Kendi kişisel deneyimlerime göre, uygulamamızda çok fazla hata buldum, ancak yönetim yeni özellikleri ortaya çıkarmak için bizi ileriye doğru bastırıyor. Sık sık duydum "Bu hatayı kendimiz bulduk ve müşteri henüz bunu farketmedi, bu yüzden sadece bunu yapana kadar bırak". Hataların giderilmesinde proaktif olana karşı reaktif olmak, zamanın gerçekten düzelmesi gereken zamanlar gibi çok kötü bir fikir olduğunu düşünüyorum, çözülmesi gereken başka sorunlarınız var ve en kısa sürede en kısa sürede kapıdan çıkmak istiyor, bu yüzden yakalanacaksınız. Çok fazla strese yol açabilecek ve tükenebilecek kısır bir döngüde ve nihayetinde kusurlu bir sistem.

İletişim aynı zamanda böcek bulunduğunda başka bir faktördür. Bir e-posta göndermek veya hata izleyicide belgelemek gayet iyi ve iyi, ancak kendi deneyimlerime göre, diğer geliştiriciler benzer bir hata buluyor ve kodu düzeltmek için koyduğunuz çözümü yeniden kullanmak yerine (her şeyi unuttukları gibi) ) kendi sürümlerini eklerler, bu nedenle kodunuzda 5 farklı çözüm vardır ve sonuçta daha şişkin ve kafa karıştırıcı görünür. Bu nedenle, bir hatayı düzeltirken, birkaç kişinin düzeltmeyi gözden geçirdiğinden ve benzer bir şeyi düzelttiklerinde ve bununla başa çıkmak için iyi bir strateji buldukları takdirde size geri bildirimde bulunduğundan emin olun.

Limist, hataların düzeltilmesi konusunda bazı ilginç materyalleri olan Pragmatik Programcı kitabından bahsetti . Önceki paragrafta verdiğim örneği kullanarak şuna bakarım: Kırık bir dul analojisinin kullanıldığı Yazılım Entrophy . Eğer iki tane kırık pencere belirirse, proaktif bir duruş sergilemediğiniz sürece, ekibiniz sabitlemeye karşı kayıtsız kalabilir.

Böcek, hata, sorun, kusur - ne demek istersen onu farketmez. Ben alışkın olduğum şeyden beri soruna sadık kalacağım.

1. Sorunun algısının ne olduğunu anlayın: bir müşteriden 'Bob hala sistemde değil' diline çevirmek Bob için bir kullanıcı kaydı oluşturmaya çalıştığımda, Bob zaten olmasa da yinelenen önemli bir istisna ile başarısız oluyor Orada'
2. Gerçekten bir sorun mu yoksa sadece bir yanlış anlaşılma mı olduğunu anlayın (gerçekten de Bob orada değil, bob denilen kimse yok ve insert çalışmalı).
3. Sorunu yeniden oluşturmak için izleyebileceğiniz en az düzeyde güvenilir adım atmaya çalışın - 'Kullanıcı kaydı' Bruce 'olan bir sistem verildi,' Kullanıcı kaydı 'Bob' eklendiğinde, sonra bir istisna ortaya çıkıyor 'gibi
4. Bu sizin testiniz - mümkünse, tekrar tekrar tekrar çalıştırabileceğiniz otomatik bir test donanımına yerleştirin, bu hata ayıklama sırasında çok değerli olacaktır. Ayrıca, belirli bir sorunun daha sonra tekrar ortaya çıkmamasını sağlamak için test paketinizin bir parçası yapabilirsiniz.
5. Hata ayıklayıcınızı çıkarın ve kesme noktaları koymaya başlayın - testinizi yaparken kod yolunu bulun ve neyin yanlış olduğunu belirleyin. Bunu yaparken, testinizi olabildiğince dar yaparak daraltabilirsiniz - ideal olarak ünite testi.
6. Düzelt - Testinizin geçtiğini doğrulayın.
7. Müşteri tarafından tarif edilen orijinal sorunun da düzeltildiğini doğrulayın (çok önemli - sorunun alt kümesini düzeltmiş olabilirsiniz). Programın diğer yönlerinde gerileme yapmadığınızı doğrulayın.

Kod hakkında çok bilgiliyseniz veya sorun veya çözüme açıksa, bu adımlardan bazılarını atlayabilirsiniz.

Değerli zamanımızı en etkin şekilde kullanmak için nasıl yaklaşmalı ve onu bulmaya çalışırken daha az zaman harcayacağımızı ve zaman kodlamasını nasıl yapmalıyız?

Bununla yeni kod yazmanın, yüksek kalitede bir çalışma programına sahip olmaktan daha değerli olduğunu ima ettiği için bununla ilgileniyorum. Sorunları çözmede mümkün olduğu kadar etkili olmanın yanlış bir tarafı yoktur, ancak bir program sadece ona daha fazla kod ekleyerek daha iyi olamaz.

Diğer cevapların çoğundan hoşlanıyorum, ancak bunlardan herhangi birini yapmadan ÖNCE ne yapacağınızla ilgili bazı ipuçları. Sana zaman kazandırır.

1. Gerçekten bir hata olup olmadığını belirleyin. Hata, HER ZAMAN sistem davranışı ve gereksinimleri arasında bir farktır; Test cihazı beklenen ve gerçek davranışları ifade edebilmelidir. Beklenen davranış için destek sağlayamazsa, herhangi bir şart yoktur ve herhangi bir hata yoktur - sadece birinin görüşü vardır. Geri gönder.

2. Beklenen davranışın yanlış olduğu ihtimalini düşünün. Bu, gereksinimin yanlış yorumlanması nedeniyle olabilir. Ayrıca, gereksinimin kendisindeki bir kusurdan da kaynaklanabilir (detaylı bir gereksinimle iş gereksinimi arasındaki bir delta). Bunları da geri gönderebilirsiniz.

3. Sorunu izole et. Yalnızca deneyim size bunu yapmanın en hızlı yolunu öğretir - bazı insanlar bunu bağırsaklarıyla neredeyse yapabilir. Temel yaklaşımlardan biri, diğer her şeyi sabit tutarken bir şeyi değiştirmektir (sorun diğer ortamlarda? Diğer tarayıcılarda? Farklı bir test bölgesinde? Günün farklı zamanlarında mı ortaya çıkıyor?) Başka bir yaklaşım yığın dökümlerine bakmak veya hata mesajları - bazen sistemin hangi bileşeninin orijinal hatayı attığını biçimlendirip anlatabilirsin (örneğin, eğer Almanca ise, Berlin'de çalıştığın üçüncü partiyi suçlayabilirsin).

4. İşbirliği yapan iki sisteme daralttıysanız, iki sistem arasındaki mesajları trafik izleyicisi veya günlük dosyaları aracılığıyla inceleyin ve hangi sistemin hangi özelliklere uygun olduğunu ve hangilerinin olmadığını belirleyin. Senaryoda ikiden fazla sistem varsa, ikili kontroller yapabilir ve uygulama yığında "aşağı" kadar çalışabilirsiniz.

5. Sorunu izole etmenin bu kadar kritik olmasının nedeni, sorunun kod üzerindeki bir kusurdan kaynaklanmaması olabilir (örneğin, üçüncü taraf sistemleri veya çevre) ve bu tarafın mümkün olan en kısa sürede ele geçirilmesini isteyebilirsiniz. . Bu, hem çalışmanızı sağlamak hem de onları derhal noktaya çıkarmaktır, böylece çözünürlük mümkün olan en kısa sürede elde edilebilir. Sadece bir başkasının web servisiyle ilgili bir sorun olduğunu bulmak için bir konu üzerinde on gün çalışmak istemezsiniz.

6. Gerçekten bir hata olduğunu belirlediyseniz ve gerçekten kontrol ettiğiniz koddaysa, sorunu en son "bilinen iyi" yapıya bakarak ve kaynak kontrol kayıtlarını soruna neden olabilecek değişiklikler için inceleyerek tecrit edebilirsiniz. Bu çok zaman kazandırabilir.

7. Bunu kaynak kontrolünden anlayamıyorsanız, şimdi hata ayıklayıcınızı ekleme ve bunu çözmek için kod boyunca adım atmanın zamanı geldi. Muhtemelen şimdiden problem hakkında oldukça iyi bir fikre sahipsin.

Böceğin nerede olduğunu ve düzeltmeyi düşünebildiğini öğrendikten sonra, düzeltmek için iyi bir prosedür:

1. Sorunu yeniden üreten ve başarısız olan bir birim testi yazın.

2. Birim testini değiştirmeden geçmek (uygulama kodunu değiştirerek) geçmek.

3. Regresyonu önlemek / tespit etmek için ünite testini test dairenizde tutun.

İşte nasıl yaparım:

1. Sorunu bulmak için her seferinde aynı yöntemi kullanın. Bu, hatalara karşı tepki sürenizi iyileştirecektir.
2. En iyi yol muhtemelen kodu okumaktır. Bunun nedeni, tüm bilgilerin kodda mevcut olmasıdır. Sadece doğru pozisyonu bulmak ve tüm detayları anlayabilmek için etkili yollara ihtiyacınız var.
3. hata ayıklama çok yavaş bir yoldur ve yalnızca programcılar henüz bilgisayarın asm komutlarını nasıl yürüttüğünü anlamadığında / arama yığınlarını ve temel şeyleri anlamadığında
4. Programın davranışını akla getirmek için işlev prototiplerini kullanma gibi kanıtlama teknikleri geliştirmeye çalışın. Bu, doğru pozisyonun daha hızlı bulunmasına yardımcı olacaktır.

Kodumuzda bir hata tespit ettiğimizde, onu yok etmek için ne yapabiliriz? Değerli zamanımızı en etkin şekilde kullanmak için nasıl yaklaşmalı ve onu bulmaya çalışırken daha az zaman harcayacağımızı ve zaman kodlamasını nasıl yapmalıyız? Ayrıca, hata ayıklama sırasında nelerden kaçınmalıyız?

Bir üretim ortamında olduğunuzu varsayarak, yapmanız gerekenler:

1. "Hatayı" doğru şekilde tanımlayın ve bunun gerçekleşmesine neden olan olayları tanımlayın.

2. "Hata" nın bir kod hatası mı yoksa özellik hatası mı olduğunu belirleyin. Örneğin, 1 harfli bir ad girmek, bazı sistemler için bir hata olarak kabul edilebilir, ancak diğer sistemler için kabul edilebilir bir davranış olarak kabul edilebilir. Bazen bir kullanıcı bir sorun olduğunu düşündüğü bir hatayı rapor eder, ancak kullanıcının sistemin davranışı konusundaki beklentisi şartların bir parçası değildi.

3. Bir hata olduğunu ve hatanın koddan kaynaklandığını ispatladıysanız, hatayı önlemek için hangi kod parçalarının düzeltilmesi gerektiğini belirleyebilirsiniz. Ayrıca, davranışın mevcut veriler ve gelecekteki sistem operasyonları üzerindeki etkisini de inceleyin (kod ve veriler üzerindeki etki analizi).

4. Bu noktada muhtemelen, hatayı düzeltmek için ne kadar kaynak tüketileceği konusunda bir tahminde bulunabilirsiniz. Hemen düzeltebilir veya yazılımı yakında yayınlayacağınız bir sürüm içinde bir düzeltme zamanlayabilirsiniz. Bu aynı zamanda son kullanıcının düzeltme için para ödemeye razı olup olmadığına da bağlıdır. Hatayı düzeltmek için mevcut farklı seçenekleri de değerlendirmelisiniz. Birden fazla yol olabilir. Duruma en uygun yaklaşımı seçmeniz gerekir.

5. Bu hatanın ortaya çıkmasına neden olan nedenleri analiz edin (gereksinimler, kodlama, test etme, vb.). Durumun tekrarlanmasını önleyecek süreçleri uygula.

6. Bölümü yeterince belgeleyin.

7. Düzeltmeyi bırakın (veya yeni sürümü)