Hata ayıklamaya nasıl daha az zaman harcanır? [kapalı]

Pareto kuralını takiben, bir programcı zamanının sadece% 20'sini gerçekten faydalı şeyler için harcıyor.

Zamanımın% 80'ini hata ayıklamak için harcıyorum, her şeyin çalışması için küçük şeyleri düzeltiyorum.

Hata ayıklama için daha az zaman harcamanın bir yolu var mı?

Kod Agda veya Coq . Kodunuz derlendiğinde çalışır. Çok sertse, zayıf bir sisteme sahip bir dil seçin, örn. Haskell veya F #.

Ancak yine de çoğu durumda zamanınızın% 20'sini kodlamaya,% 80'ini test ve hata ayıklamaya harcayacaksınız. Bir haftanın% 100'ü, bir saatin% 20'sinden çok daha fazladır. Hata ayıklama, işleri halletmek için ihtiyaç duyduğunuz şeyse, hata ayıklama zaman kaybı değildir ve bu oranı "iyileştirme" ile uğraşmamalısınız.

Birim testi.

Birim testi uygulamaya başladıktan sonra yazdığım kodun daha iyi yapılandırıldığını gördüm. Daha sonra hataları önlemek ve tespit etmek daha kolaydı. Hata ayıklama için daha az zaman, yazı birimi testi ile daha fazla zaman geçirdim.

Ayrıca birim testlere harcanan zamanın hata ayıklamadan daha iyi bir yatırım getirisi olduğunu düşünüyorum. Hata ayıklama oturumundan sonra kodu düzelttim. Aynı hata haftalar sonra ortaya çıkabilir ve tekrar hata ayıklamak zorunda. Bir birim testi yazarsam, hata bir birim testi olarak belgelenir ve daha sonra bir regresyon testi olarak görev yapar. Hata tekrar görünürse, birim testleri bunu bana gösterir.

• Birim testi, böylece kodunuzun ilk başta çalışıp çalışmadığını bilirsiniz.
• En azından bir miktar ön tasarım, böylece ne kodladığınızı biliyorsunuz.
• Kodları gözden geçirin, çünkü iki kafa bir taneden daha iyidir ve dört göz ikiden daha iyidir. Kodunuzu başkasına açıklamaya çalışmanın bile birçok sorun ortaya çıkardığından bahsetmiyorum bile.
• Sürüm kontrolü, böylece hangi değişikliklerin hataya neden olabileceğini hızlı bir şekilde izole edebilirsiniz.
• Yeniden düzenleme, böylece kod korkunç bir anlaşılmaz karmaşa dönüşmez.
• Robert C. Martin'den "Temiz Kod" u okuyun ve size söylediklerini yapın. Sonuçlara hayran kalacaksınız.

Ünite testi, üretim kodunuzdan önce kırılacakları hatalar sunarsanız, iyi yazılmış ünite testleri de tam olarak neyin kırıldığını size söyleyecektir.

Bu size en çok yolu sağlayacaktır, ancak projelerin% 99,999'u için zaman zaman hata ayıklamanız gerekir. Burada bulduğum en iyi şey 4 şey yapmak:

1. Mümkün olan her yerde değişmez tipler kullanın - bir şeyin yanlış bir değeri varsa tam olarak nereye bakacağınızı (nerede inşa edildiğini) bileceksiniz.
2. değişmezleri kodda uygula - bir değerin kesinlikle izin verilmediğini biliyorsanız, bunu kontrol edin ve yöntemlere ve kuruculara giriş noktalarında bir istisna atın. Bunu değişmez türlerle birleştirirseniz, neyin geçerli olup olmadığı hakkında belirli varsayımlar yapmaya da başlayabilirsiniz.
3. yeterli günlük kaydına sahip olduğunuzdan emin olun - bunu erken edinin ve işlerin ne zaman yanlış gittiğiyle ilgili size çok önemli bilgiler verecektir. AOP burada gerçekten iyi çalışıyor. Sonradan düşünülmüş olarak oturum açmak genellikle biraz zordur - proje kurulumunun bir parçası olarak erkenden alın.
4. kod tabanınız yeterince büyük / karmaşıksa, ilkelleri kullanmaktan kaçının - örneğin, yalnızca int kullanmaktansa 'Age' adlı bir türünüz olsun. İlk başta biraz anlamsız görünecek, ancak bir şeyin tüm kullanımlarını anında takip edebilmek büyük bir hata ayıklama kazancıdır.

Benim% 80 hata ayıklama. Basit hataları düzeltiyorum ve tüm işleri yapmaya çalışıyorum.

Birim testleri yazarak başlayın ve mümkün olduğunca yüksek kapsama alanına sahip olmaya çalışın. Birisi TDD'den bahsetti, ama BDD ile giderdim .

Sonunda, büyük olasılıkla karmaşık hataları ayıklamak için% 80 harcarsınız.

Hata ayıklama için nasıl daha az zaman harcanır? Daha az kod yazın.

Cidden, kod yazdığınız sürece, hata ayıklamanız gerekir. Birim testleri vb. Çok yardımcı olur, ancak buna olan ihtiyacı tamamen ortadan kaldıracağınızı düşünmeyin.

Kod yazmaya başlamadan önce neyi ve nedenini anlayın. Ardından tutarlı bir yöntem kullanın. Hangi yöntemi seçtiğiniz, metodolojinin sürekli tekrarlanan kullanımı kadar önemli değildir. Sürekli olarak iyi sonuçlar almak istiyorsanız, sürekli olarak iyi işler yapmanız gerekir ve bu sonuçları elde etmenin ilk adımı "deliliğinize bir yöntem" getirmenizdir. Sorunları belirledikçe, metodolojinizi gerektiği gibi ayarlayabilirsiniz ve zamanla geliştirme sürecinizi iyileştirirsiniz ve umarım daha az hata ve daha yeni, anlamlı gelişim elde edersiniz.

Kodunuzu derlemeden önce dikkatli bir şekilde okuyun. Sözdizimi ve işlevsellik için çok dikkatli bir okuma. Şaşırtıcı derecede bilgilendirici olabilir ve ayrıca bir kod bölümü çok karmaşıksa iyi bir göstergedir.

Yanıtların çoğu, hata ayıklamanız gereken sorunların sayısını azaltmaya odaklanmış gibi görünüyor ve bu değerlidir. Bununla birlikte, hata ayıklama her zaman gerekli olacaktır, bu nedenle hata ayıklamada daha hızlı olmanın yollarına bakmak yararlı olacaktır.

• Sürüm kontrol yazılımınızı nasıl kullanacağınızı öğrenin.

  • Dalları kullanmak, geliştirme alanlarını ayırmanıza yardımcı olur ve hangi geliştirme alanının hataya sahip olduğunu ve hangisinin olmadığını görebilirsiniz.
  • VCS'nizde ikiye bölmeyi nasıl kullanacağınızı öğrenin, Git'te yerleşik olarak bulunur. Eğer ikiye yerleşik olmayan farklı bir VCS kullanıyorsanız git bisect gibi ama VCS'niz için çalışan bir araç arayın (SVN ve diğer VCS'ler için oluşturulması çok zor olmamalıdır). Bu, hataya neden olan kod değişikliğini daraltmanıza yardımcı olur, bu da hata ayıklayıcınızı nereye yönlendireceğinizi bilmenize yardımcı olur. Böcek için testleriniz varsa ve atomik taahhütleri uygularsanız hangi değişikliğin hangi değişikliği içerdiğini bilmek daha yararlı olacaktır.

• Kullandığınız programlama dili ile ilgili anlayışınızı geliştirin.

  • Programlama dili hakkında kitap, blog ve kod okuyun.
  • Bir hatayı her düzelttiğinizde, kodun neden çalışmadığını ve düzeltmenizin neden çalıştığını iyice anladığınızdan emin olun. Zamanla, dillerinde problemlerinden kaçınmanıza ve yeniden ortaya çıkmaları durumunda semptomlarını tespit etmenize yardımcı olacak birçok gotcha öğreneceksiniz.

• Mantıksal olun

  • Birden fazla şeyi aynı anda değiştirmeyin, aksi takdirde davranış değişirse hangi değişikliğin davranış değişikliğine neden olduğunu bilemezsiniz.
  • Varsayımlarınızı doğrulayın.

Birim Testi için yorumlara ekleme ancak kodunuzu desteklemek için ayrılmışsa (örn. MVC) gerçekten iyidir. MVC (veya benzeri) (eski proje) uygulayamıyorsanız, birim testleri kullanıcı arayüzünüz için hiç çalışmaz. Daha sonra bu kodunuzun bu bölümündeki hataları azaltacağı için otomatik UI testi (Microsoft Kodlu UI Testleri, WaitN) ekleyeceğim.

Ayrıca statik analiz araçları (MS dünyası için FxCop / Microsoft Kod Analizi, Resharper, JustCode) çalıştırmanızı şiddetle tavsiye ederim. Bunlar aptal hata ayıklama görevlerini azaltabilen ve daha çok iş mantığında hata ayıklamaya odaklanabilecek her türlü ortak kodlama problemini bulabilir.

Çalıştırın, sonra hızlı olun, sonra güzelleştirin. Çoğu hata erken optimizasyon veya tamamen iyi kod satırlarında yeniden faktoring geliyor. Nesne yönelimi ile devam ederseniz, kendinizi tekrarlamayın, basit tutun ve özellikle yöntemleriniz hala kısıtlamalarda çalışacaksa, değer aralıklarının akıl sağlığını kontrol edin. Daha az hata yapmanıza yardımcı olmaz, ancak hataları daha hızlı tespit etmenize yardımcı olur ve bu nedenle hata ayıklama daha az zaman alır.

Son zamanlarda bu soruna çok fazla düşünce verildi - basit cevap Don Norman'ın Gündelik Şeylerin Tasarımı; Bir ürünü tasarladığınız gibi kod yazın.

Başka bir deyişle, iyi tasarım hatayı en aza indirir. Bu, çoğu zaten yaptığınız birkaç şey anlamına gelir (bunun nedenini tam olarak bilmiyor olsanız da ).

-Ad, sezgisel olarak çalışır. Bu resmen ekonomik olarak bilinir. Yani, bir düğmeye basılması, bir kolun değiştirilmesini, bir kolun çekilmesini vb.

- Kötü kod yazmak zor. Hatalı giriş olup olmadığını kontrol edin ve hataları daha sonra değil daha erken atın, uygun olduğunda macarca uygulamaları kullanın vb. Bunlara kilitleme işlevleri denir.

- Uygun olan yerlerde soyutlama kullanın. Kısa süreli hafıza zayıftır.

-Dokümantasyon açıkça önemlidir, ancak kodun doğru şekilde kullanıldığından en az etkilidir. Kısacası, iyi tasarlanmış ürünler herhangi bir belgeye ihtiyaç duymaz. (Bunu görmenin en belirgin yolu kötü örneklere bakmaktır: yani itmeniz gereken kulplu kapılar.)

Ünite testleri. Bunlar, hataların nerede olduğunu açıkça ortaya koyduğu ve akıl sağlığını sağladığı kadar hataları gerçekten önlemez.

Eminim daha birçok prensip eksiktir, ama asıl nokta, hata tasarımını okuyun.

Hata ayıklamayı azaltmanın en iyi yolu, IMO, kodlama sırasında konsantre olmak ve yavaşlamaktır. Bu sizi yapmış olabileceğiniz hataları görmeye zorlar!

Yukarıda önerilen birim testlerini tamamen desteklesem de, TDD veya BDD, öncelikle problem ve çözüm hakkında düşünmeniz gerektiği için büyük değer taşıyacaktır.

Ama şahsen benim için, sadece sessizce oturmak ve sorun hakkında düşünmek ve ona yaklaşmak ve her yaklaşımla ilgili profesyonel ve eksileri düşünmek için birkaç dakikanızı ayırmak, kod kalitem için harikalar yaratıyor ve dağınıklığımın zihnini temizlemeye yardımcı oluyor.

Bazen bir kağıda hızlı bir karalama yapbozun daha büyük bağlı parçalarını görmenize yardımcı olur.

Önce kafasına daldığımda ve klavyeyi vurduğumda en kötü kodu yazıyorum. Biraz düşünce ve tefekkür bir fark dünyası yaratır.

PS. Demek istediğim 5 belki on dakika.

Bazı iyi cevaplar zaten, başkalarının söylediklerine ek olarak sadece biraz daha yiyecek.

Hatalarınızdan öğrenin. Aynı şeyleri tekrar tekrar yapmaya devam etmeyin.

Programlama sırasında kenar durumlarını kapsadığınızdan emin olun - bunlar sık ​​sık hataların olduğu yerlerdir.

Gereksinime dikkat edin. Çalışıyor olsa da, belirtilen gereksinimi yapmasa bile, bu bir hata.

Altı ay sonra bir şeyler ters gittiğinde istisna günlükleri gerçek bir yardımcı olabilir. İstisnaları kaydetme alışkanlığı edinin.

En iyi iki düşüncem 1) Beklenmedik bir şey yaptığınızda başarısız olacak daha iyi kod yazın 2) Hata ayıklamada daha iyi olun

Kodum

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

Bu kod parçasını yürüttüğümde, yeni özelliklerde kod yazmama veya koşullardan kaçınmama izin veren hata ayıklayıcının durmasına neden olan istisna atılır.

Çağrı yığını, kesme noktaları (koşullarla), anında pencere (bilgi istemi veya repl penceresi olarak da bilinir), 'watch' değişkenleri ve başka herhangi bir şeyle karışıklık ayıklama konusunda daha iyi olmak için.