it-swarm.dev

Kodda en etkili hata ayıklama nasıl yapılır?

Kodda sürünen hatalar en aza indirilebilir, ancak yazıldığı gibi tamamen ortadan kaldırılamaz - programcılar, çoğu insan aynı fikirde değil olsa da insanlardır.

Kodumuzda bir hata tespit ettiğimizde, onu ayıklamak için ne yapabiliriz? Değerli zamanımızı en etkili şekilde kullanmak ve onu bulmaya daha az zaman harcamamızı ve daha fazla zaman kodlamasını sağlamak için nasıl yaklaşmalıyız? Ayrıca, hata ayıklama sırasında nelerden kaçınırız?

Burada hataları önlemekten bahsetmediğimizi unutmayın; hatalar göründüğünde ne yapacağımızdan bahsediyoruz. Bu geniş bir alan, biliyorum ve dil, platform ve araçlara oldukça bağımlı olabilir. Eğer öyleyse, zihniyetler ve genel yöntemler gibi cevapları kapsamaya devam edin.

33
gablin

Hata ayıklamaya yönelik zihniyet ve tutum belki de en önemli kısımdır, çünkü hatayı ne kadar etkili bir şekilde çözeceğinizi ve ondan ne öğreneceğinizi belirler - bir şey varsa.

Pragmatik Programcı ve Kod Tamamlandı temelde aynı yaklaşımı savunuyor: her hata bir fırsattır öğrenmek, neredeyse her zaman kendiniz hakkında (çünkü sadece yeni başlayanlar derleyiciyi/bilgisayarı önce suçlar).

Bu yüzden onu çatlamak ilginç olacak bir gizem olarak ele alın. Ve gizemin sistematik olarak yapılması gerektiğini varsaymak, varsayımlarımızı (kendimize veya başkalarına) ifade etmek ve sonra varsayımlarımızı test etmek, gerekirse teker teker - özellikle hata ayıklayıcılar ve otomatik test çerçeveleri olmak üzere elimizdeki her aracı kullanmak. Gizem çözüldükten sonra, yapmış olabileceğiniz benzer hatalar için tüm kodlarınıza bakarak daha da iyi yapabilirsiniz; ve hatanın tekrar bilinmeyeceğinden emin olmak için otomatik bir test yazın.

Son bir not - Hataları "hatalar" olarak değil "hatalar" olarak adlandırmayı tercih ediyorum - Dijkstra, meslektaşlarını ikinci terimi kullanmaktan kurtardı çünkü dürüst değil, kötü niyetli ve kararsız böcek perilerinin programlarımıza hatalar ekledikleri fikrini destekliyor. t Kendi (özensiz) düşüncemiz nedeniyle orada olmak yerine bakmak: http://www.cs.utexas.edu/users/EWD/transcription/EWD10xx/EWD1036.html

Mesela, artık bir hataya hata diyerek değil, bir hata diyerek dilimizi temizlemeye başlayabiliriz. Çok daha dürüst, çünkü suçu ait olduğu yere dik bir şekilde yerleştiriyor, yani. hata yapan programcı ile. Programcı bakarken kötü niyetli olarak gizlenen hatanın animasyonsal metaforu, hatanın programcının kendi yaratımı olduğunu gizlediği için entelektüel sahtekârlıktır. Bu basit kelime değişikliğinin güzel yanı, bu kadar derin bir etkiye sahip olmasıdır: daha önce, sadece bir hata içeren bir program "neredeyse doğru", daha sonra bir hata içeren bir program sadece "yanlış" (çünkü hata).

38
limist
  1. Test yazma. Test sadece hataları önlemede harika değil (benim deneyimime göre, TDD doğru yapılmış neredeyse tüm önemsiz, aptal böcekleri ortadan kaldırıyor), aynı zamanda hata ayıklamada çok yardımcı oluyor. Test, tasarımınızı modüler olmaya zorlar, bu da sorunu izole etmeyi ve çoğaltmayı çok daha kolay hale getirir. Ayrıca, çevreyi kontrol edersiniz, bu yüzden çok daha az sürpriz olacaktır. Dahası, başarısız bir test senaryosu aldığınızda, sizi rahatsız eden davranışın gerçek sebebini çivilediğinizden emin olabilirsiniz.

  2. Hata ayıklayıcıyı nasıl kullanacağınızı öğrenin. print ifadeleri bir düzeyde oldukça iyi çalışabilir, ancak çoğu zaman bir hata ayıklayıcı çok yararlıdır ve kullanın, print ifadelerinden çok daha rahattır).

  3. Sorununuz hakkında birisi hakkında konuşun, sadece bir kauçuk duckie olsa bile. Üzerinde çalıştığınız problemi kelimelerle ifade etmeye zorlamak gerçekten mucizeler yaratır.

  4. Kendinize bir zaman sınırı verin. Örneğin 45 dakika sonra hiçbir yere gitmeyeceğinizi düşünüyorsanız, bir süreliğine diğer görevlere geçin. Hatanıza geri döndüğünüzde, umarım daha önce düşünmediğiniz diğer olası çözümleri görebilirsiniz.

16
Ryszard Szopa

Bu konuda okuduğum mükemmel bir kitap var Neden Programlar Başarısız , bilimsel yöntemi uygulamaktan bir hatayı izole etmek ve çözmek, hata ayıklamaya kadar çeşitli hataları bulmak için çeşitli stratejileri özetliyor. Bu kitabın diğer ilginç kısmı ise 'bug' terimini ortadan kaldırması. Zeller'in yaklaşımı:

(1) Bir programcı kodda bir hata oluşturur. (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 ederim.

Kendi kişisel deneyimime göre, uygulamamızda çok sayıda hata buldum, ancak yönetim yeni özellikler almak için bize baskı yapıyor. Sık sık "Bu hatayı kendimiz bulduk ve müşteri henüz fark etmedi, bu yüzden yapana kadar bırakın". Hataların giderilmesinde proaktifin karşısında reaktif olmanın çok kötü bir fikir olduğunu düşünüyorum, çünkü aslında bir düzeltme yapma zamanı geldiğinde, çözülmesi gereken başka sorunlarınız var ve daha fazla özellik yönetimi ASAP'ın kapıdan çıkmasını istiyor, böylece yakalanıyorsunuz çok fazla strese ve yanmaya yol açabilecek kısır döngüde ve sonuçta kusurlu bir sistem.

İletişim, hatalar bulunduğunda başka bir faktördür. Bir e-posta göndermek veya hata izleyicide belgelemek her şey yolunda ve iyi, ancak kendi deneyimime 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 eklediklerinden, kodunuzda 5 farklı çözüm var ve sonuç olarak daha şişkin ve kafa karıştırıcı görünüyor. Bu nedenle, bir hatayı düzelttiğinizde, birkaç kişinin düzeltmeyi gözden geçirdiğinden ve benzer bir şeyi düzeltmeleri ve bununla başa çıkmak için iyi bir strateji bulmaları durumunda size geri bildirim verdiğinizden emin olun.

limist kitaptan bahsetti, Pragmatik Programcı hataları düzeltmek için bazı ilginç materyallere sahip. Önceki paragrafta verdiğim örneği kullanarak, şuna bakardım: Yazılım Entrofisi , burada kırılmış bir Dul'un benzetmesi kullanılır. Eğer iki çok kırık pencere görünürse, proaktif bir duruş sergilemediğiniz sürece ekibiniz onu düzeltmeye hiç ilgisiz olabilir.

3
Desolate Planet

Diğer cevapların çoğunu beğendim, ancak işte bunlardan herhangi birini yapmadan ÖNCE ne yapacağınıza dair bazı ipuçları. Beaucoup de zaman kazandıracak.

  1. Gerçekten bir hata olup olmadığını belirleyin. Bir hata DAİMA sistem davranışı ve gereksinimler arasındaki farktır; test edenin beklenen ve fiili davranışı ifade edebilmesi gerekir. Beklenen davranış için destek sağlayamazsa, şart yoktur ve hata yoktur - sadece birinin görüşü. Geri gönder.

  2. Beklenen davranışın yanlış olma olasılığını düşünün. Bu, gereksinimin yanlış yorumlanmasından kaynaklanabilir. Ayrıca gereksinimin kendisindeki bir kusurdan da kaynaklanabilir (ayrıntılı bir gereksinim ve iş gereksinimi arasındaki bir delta). Bunları da geri gönderebilirsiniz.

  3. Sorunu izole edin. Sadece deneyim size bunu yapmanın en hızlı yolunu öğretecektir - bazı insanlar bunu neredeyse bağırsaklarıyla yapabilir. Temel bir yaklaşım, diğer tüm şeyleri sabit tutarken bir şeyi değiştirmektir (sorun diğer ortamlarda mı? Diğer tarayıcılarda mı? Farklı bir test bölgesinde mi? Günün farklı saatlerinde mi?) Başka bir yaklaşım yığın dökümlerine bakmak veya hata mesajları - bazen sistemin hangi bileşeninin orijinal hatayı attığını biçimlendirerek anlayabilirsiniz (örneğin, Almanca ise, Berlin'de çalıştığınız üçüncü tarafları suçlayabilirsiniz).

  4. İşbirliği yapan iki sisteme daralttıysanız, trafik izleyicisi veya günlük dosyaları aracılığıyla iki sistem arasındaki iletileri inceleyin ve hangi sistemin teknik özelliklere uygun olduğunu ve hangisinin olmadığını belirleyin. Senaryoda ikiden fazla sistem varsa, ikili denetimler gerçekleştirebilir ve uygulama yığınını "aşağı" ilerletebilirsiniz.

  5. Sorunu izole etmenin bu kadar kritik olmasının nedeni, sorunun kontrolünüzde olan bir kusurdan (örneğin üçüncü taraf sistemleri veya çevre) kaynaklanmaması ve o partiyi mümkün olduğunca çabuk devralmasını istemenizdir. . Bu, hem işinizi kurtarmak hem de onları hemen noktaya getirmektir, böylece çözünürlük mümkün olduğunca kısa bir sürede elde edilebilir. Yalnızca bir başkasının web hizmeti ile ilgili bir sorun olduğunu bulmak için on gün boyunca bir sorun üzerinde çalışmak istemezsiniz.

  6. Gerçekten bir kusur olduğunu belirlediyseniz ve gerçekten kontrol ettiğiniz kodda ise, son "bilinen iyi" yapıyı arayarak ve soruna neden olabilecek değişiklikler için kaynak kontrol günlüklerini inceleyerek sorunu daha da izole edebilirsiniz. Bu çok zaman kazandırabilir.

  7. Kaynak kontrolünden anlayamıyorsanız, şimdi hata ayıklayıcınızı ekleme ve çözmek için koddan geçme zamanı. Şimdiye kadar sorun zaten oldukça iyi bir fikriniz var.

Hatanın nerede olduğunu öğrendikten ve bir düzeltmeyi düşünebildiğinizde, düzeltmek için iyi bir prosedür:

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

  2. Ünite testini değiştirmeden, geçmesini sağlayın (uygulama kodunu değiştirerek).

  3. Regresyonu önlemek/tespit etmek için ünite testini test takımınızda tutun.

3
John Wu

Hata, hata, sorun, kusur - ne demek isterseniz, çok fazla fark yaratmaz. Soruna sadık kalacağım çünkü alıştığım şey bu.

  1. Sorunun algılanmasının ne olduğunu anlayın: Bir müşterinin 'Bob hala sistemde değil' ifadesinden 'Bob'a bir kullanıcı kaydı oluşturmaya çalıştığımda, Bob zaten olmasa da yinelenen bir anahtar istisnasıyla başarısız oluyor Orada'
  2. Gerçekten bir sorun mu yoksa sadece bir yanlış anlama mı olduğunu anlayın (gerçekten, Bob orada değil, bob denen kimse yoktur ve insert işe yaramalıdır).
  3. Sorunu yeniden oluşturmak için izleyebileceğiniz en az güvenilir adımları almaya çalışın - 'Kullanıcı kaydı' Bruce 'olan bir sistem verildiğinde,' Bob 'kullanıcı kaydı eklendiğinde bir istisna oluşur' gibi bir şey
  4. Bu sizin testinizdir - mümkünse, tekrar tekrar çalıştırabileceğiniz otomatik bir test kayışına koyun, hata ayıklama sırasında bu çok değerli olacaktır. Bu sorunun daha sonra tekrar ortaya çıkmamasını sağlamak için test paketinizin bir parçası da yapabilirsiniz.
  5. Hata ayıklayıcınızı çıkarın ve kesme noktaları koymaya başlayın - testinizi çalıştırdığınızda kod yolunu bulun ve neyin yanlış olduğunu belirleyin. Bunu yaparken testinizi olabildiğince daraltarak ideal bir birim test yaparak da hassaslaştırabilirsiniz.
  6. Düzelt - testlerinizin başarılı olduğunu doğrulayın.
  7. Müşteri tarafından açıklanan orijinal sorunun da giderildiğini doğrulayın (çok önemli - sorunun bir alt kümesini düzeltmiş olabilirsiniz). Programın diğer yönlerinde gerileme yapmadığınızı doğrulayın.

Kodu çok iyi biliyorsanız veya sorun veya düzeltme açıksa, bu adımlardan bazılarını atlayabilirsiniz.

Değerli zamanımızı en etkin şekilde kullanmak ve onu bulmaya daha az zaman harcamamızı ve daha fazla zaman kodlamasını sağlamak için nasıl yaklaşmalıyız?

Yeni kod yazmanın yüksek kaliteli bir çalışma programına sahip olmaktan daha değerli olduğunu ima ettiği için bu konuyu ele alıyorum. Sorunları çözmede mümkün olduğunca etkili olmanın yanlış bir yanı yoktur, ancak bir program sadece daha fazla kod ekleyerek daha iyi olamaz.

3
ptyx

Bence bir böceğin çoğaltılması da önemlidir. Hatayı yeniden üreten tüm durumlar listelenebilir ve daha sonra hata düzeltmenizin tüm bu durumları kapsadığından emin olabilirsiniz.

3
aslisabanci

Kodumuzda bir hata tespit ettiğimizde, ayıklamak için ne yapabiliriz? Değerli zamanımızı en etkin şekilde kullanmak ve onu bulmaya daha az zaman harcamamızı ve daha fazla zaman kodlamasını sağlamak için nasıl yaklaşmalıyız? Ayrıca, hata ayıklama sırasında nelerden kaçınırız?

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

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

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

  3. Bir hata olduğunu ve hatanın koddan kaynaklandığını kanıtladı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 işlemleri üzerindeki etkisini inceleyin (kod ve veriler üzerindeki etki analizi).

  4. Bu noktada, muhtemelen hatayı düzeltmek için ne kadar kaynak tüketileceğini tahmin edersiniz. Hemen düzeltebilir veya yazılımın gelecek sürümünde bir düzeltme planlayabilirsiniz. Bu ayrıca son kullanıcının düzeltme için ödeme yapmak isteyip istemediğine de 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 vb.). Durumun tekrarlanmasını önleyecek süreçleri uygulayın.

  6. Bölümü yeterince belgeleyin.

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

1
NoChance

İşte nasıl yaparım:

  1. sorunu bulmak için her seferinde aynı yöntemi kullanın. Bu, hatalara tepki sürenizi artıracaktır.
  2. En iyi yol muhtemelen kodu okumaktır. Bunun nedeni koddaki tüm bilgilerin mevcut olmasıdır. Doğru ayrıntıları ve tüm ayrıntıları anlama yeteneğini bulmak için etkili yollara ihtiyacınız var.
  3. hata ayıklama çok yavaş bir yöntemdir ve yalnızca programcılarınız bilgisayarın asm talimatlarını nasıl yürüttüğünü/çağrı yığınlarını ve temel şeyleri anlayamadığını henüz anlamadıysa gereklidir.
  4. Programın davranışları hakkında akıl yürütmek için fonksiyon prototiplerini kullanmak gibi ispat teknikleri geliştirmeye çalışın. Bu, doğru pozisyonu daha hızlı bulmanıza yardımcı olacaktır
1
tp1