Hata ayıklama: belirli düzeltmelerin neden işe yaradığına dair ayrıntıları anlama? [kapalı]


12

Hata ayıklama yaparken, bazen bazı değişiklikler yaptığımı fark ediyorum ve bu değişikliklerin neden programdaki bazı hataları düzelttiğinden% 100 emin değilim. Bazı hataların neden oluştuğu ve bazı değişikliklerin neden bu hataları ortadan kaldırdığına dair her ayrıntıyı anlamak gerekli mi? Yoksa geliştiricilerin, bazen, düzeltmenin neden işe yaradığına dair ayrıntıları bilmeden programı çalıştırması yaygın mıdır?


1
Hatayı düzeltmeyi bitirdiğini kimseye nasıl ikna edersin?

related: Bug fixing appproach "Genellikle, hatanın oluşması için gerçek nedeni bulmaya ve sonra düzeltmeye çalışırsınız. Ama bazen biraz araştırma yapmaktan bıktığımda ne yapıyorum internet) sadece diğer seçeneğe göre çok daha az zaman alır mantığı değiştirmek olduğunu ... "
gnat

Yanıtlar:


32

Bazı hataların neden oluştuğu ve bazı değişikliklerin neden bu hataları ortadan kaldırdığı hakkında her ayrıntıyı anlamak önemlidir ve ayrıca, düzeltmenin neden işe yaradığına dair ayrıntıları bilmeden bazen programın çalışmasını sağlamak da yaygındır!

Bir hata ortadan kalkana kadar bir şeyi değiştirme sanatına, neyin sebep olduğunu veya değişikliğin neden düzelttiğini anlamadan, genellikle "vudu programlama" denir ve bu bir iltifat değildir. Soruna neyin sebep olduğunu anlamadıysanız, araştırdığınız belirli bir durum için kısmen düzeltmenin aksine, bir hatayı gerçekten düzelttiğinizden emin olmanızın hiçbir yolu yoktur .

En kötü durumda, hatayı hareket ettirmek dışında hiçbir şey yapmadınız: Uni'de ilk yıl bilgisayar kullanımından, birçok öğrenci C ve işaretçileri ilk kez öğrenirken, işaretçi böcekleri genellikle bir şeyleri değiştirdiklerinde tezahür etmeyi bırakacaklarını hatırlıyorum rasgele, çünkü değişiklikler bellekteki veri yapılarını, işaretçi hatasını farklı bir bellek parçası üzerinde durduracak şekilde yeniden düzenleyecektir. Açıkçası yardımcı olmadığını hiç .

Ancak, programlamanın ticari gerçeklerinin çoğu zaman müşteriye bir hatanın düzeltildiğini tatmin etmek, kendinizi tatmin etmekten daha önemlidir. Neye neden olduğu hakkında hiçbir fikriniz yoksa, sabit bir şey bildirmenizi asla önermem , ancak bazı kodların sorunlu olduğunu görebiliyorsanız ve bunun neden% 100 emin olmadığınız halde yeniden çalıştıysanız Bazen, yavaş ilerlemeniz hakkında çok yüksek sesle çığlık atmadan önce bir sonraki hataya geçmeniz gerekir.


15

Bir müşterinin bir hatayı düzeltmek için çok uzun sürdüğünü düşünüyorsanız, düzeltildiğini iddia ettiğiniz bir hata için ne kadar çılgın olacağını ya da başka bir şeyi daha da kötüleştiren bir şey için ne kadar çılgın olacağını hayal edin. Düzeltmeniz yalnızca bir geçici çözüm veya hafifletme ise, müşteriler genellikle bunu memnuniyetle karşılar, ancak ne olduğu konusunda dürüst olmanız gerekir ve gerçek olarak düzeltmek için ihtiyacınız olduğu kadar günlüğe kaydetmeniz gerekir.

Düzelttiğinizden eminseniz, ancak düzeltmenin neden işe yaradığını bilmiyorsanız, birine sorun. Çoğu mühendis , arkasındaki gizem yüzünden böyle sorular almayı çok seviyorum .


Sadece taşındığından veya gizlenmediğinden emin değilseniz kesinlikle "sabit" olarak iddia etmemeniz gerektiğini kabul ediyorum. Yine de, "ilgili koddaki bir sorun alanını düzelttiğinizi" ve şimdi "hatayı yeniden üretemediğinizi" kabul etmek çok korkunç olmayacaktır - geçmişte takımlarım bunları "v <sürüm numarasında CNR" olarak kaydetmişti > "
PeterL

6

Hataya kadar bir şeyleri değiştirmek genellikle kötü bir uygulama değildir, ancak maalesef bazı insanlar için bir gerçeklik vardır.

Asla ne yaptığını ya da neden yaptığını anlamadığınız bir kod yazmamanız gerektiğine inanıyorum. Düzeltmek için ayarladığınız hatayı düzeltmiş olsanız bile - başka bir şeyi kırmadığınızdan nasıl emin olabilirsiniz?

Genel olarak, bir sorunu / hatayı düzeltmeden önce - sorunun neden oluştuğunu ve çoğaltılabilip çoğaltılamayacağını belirlemek için temel bir neden değerlendirmesi / analizi yapmalısınız. O zaman kodu okumalı ve kodun hatanın neden olmasına neden olduğunu anlamalısınız. Bir kez bu anlayışa sahip olduktan sonra: sorunun nasıl çözüleceğine ve değişikliklerinizin etkileyeceği diğer alanları belirlemeye başlayabilirsiniz. Birim testleri burada gerçekten yardımcı olabilir!

İnsanların bir sorunu düzeltmek için yaptıkları bir dizi kod değişikliği gördüm (bu harika), ancak ne yazık ki diğer sorunları tanıttı çünkü geliştirici değiştirdiklerinin tam etkisinin farkında değildi. Bu "düzeltmelerin" birçoğu sadece orijinal sorunun altında yatan nedeni gizlemenin yanı sıra karmaşıklık ve daha fazla hata getirmektedir.

Bunu söyledikten sonra, tamamen dernek tarafından kodda bir dizi sorunu çözdüm. Bir şeyi değiştirdiğim / yeniden çalıştığım / yeniden düzenlediğim ve diğer olağanüstü hataları düzelttiğim yer. Ben aslında onları neyin neden bilmiyorum, ancak tehlikeli kod bulundu ve "sabit" - ki bu da bu hataları düzeltmek oldu. İşin bütünlüğünü ve işlevin teknik gereksinimlerini sağlamak için bu tür değişiklikleri birim ve entegrasyon testleriyle ele alıyorum.


4

Yoksa geliştiricilerin, bazen, düzeltmenin neden işe yaradığına dair ayrıntıları bilmeden programı çalıştırması yaygın mıdır?

Bununla ilgili en az üç büyük sorun var:

  1. Bu , kodu anlayabileceğiniz fikrinden vazgeçtiğiniz ve bunun yerine sorunların ortadan kalkacağını umarak parçaları hareket ettirmeye başladığınız kara büyü zihniyetine yol açar . Bu, akşam yemeğinizin ebeveynlerinizin daha fazla sebze yemenizi sağlamayacağı için yeterince yemiş görünmesini umarak, tabağınızda yiyecekleri itmenin programlama eşdeğeridir.

  2. A) Sorunun ne olduğunu ve b) değişikliğinizin sorunu nasıl çözdüğünü anlamadığınız sürece hatanın gerçekten sabit olduğunu veya yalnızca değişikliğiniz tarafından maskeleneceğini bilemezsiniz .

  3. Böcek muhtemelen sabit değildir ve yakın gelecekte sizi tekrar ısıracaktır.


2

İki senaryo görüyorum: başka bir şey üzerinde çalıştınız ve başka bir şey başka bir şeyi bozmadığı sürece hata oluşmayı bıraktı, hemen hemen içeri girmesine izin vermelisiniz - ihtiyaç duyduğunuz / istediklerinizi yaptınız ve öngörülemeyen ve açıklanamayan olumlu bir yan etki.

Diğeri ise bu hata üzerinde çalışıyorsunuz ve rastgele bir değişiklik işlerin işe yaramasını sağladı, bu kabul edilemez. Eski kodun neyi yanlış yaptığına dair bir fikriniz yoksa, muhtemelen yeni kodun neyi yanlış yaptığına dair hiçbir fikriniz yoktur.

İkinci vakayı kontrol etmek için gerçekten iyi bir neden düşünemiyorum - eğer kritik bir hata varsa, o zaman doğru yapmak kritiktir. Kritik olmayan bir hataysa, en azından "düzeltmeniz" ile kritik bir hata getirmediğinizden emin olabilirsiniz.


0

Yoksa geliştiricilerin, bazen, düzeltmenin neden işe yaradığına dair ayrıntıları bilmeden programı çalıştırması yaygın mıdır?

Bence bu günlerde çok yaygın. Bunun nedeni Google ve Stackoverflow. Kodunuzla ilgili bir sorun var, sadece google, çözüm bul, düzelt, bir sonraki soruna geç.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.