Gerçek programcılar hata ayıklayıcılar kullanıyor mu? [kapalı]

Deneyimli programcılar aslında hiç hata ayıklayıcı kullanırlar ve eğer öyleyse hangi koşullar altında. Bu sorunun cevabında "ay" önce söylediğim halde muhtemelen "yıl" demek istedim - Gerçekten bir hata ayıklayıcı kullanmıyorum. Sorumlu özel sorum şu durumlarda, deneyimli bir programcı olarak hangi hata ayıklayıcıyı kullanırsınız?

Bir hata ayıklayıcı kullanmamanın deneyimsizliğin bir işareti olduğunu söyleyebilirim. Kod satır satır ilerlemek yürütme akışını izlemek için en iyi yoldur.

Hata ayıklayıcıyı sık sık kullanıyorum çünkü büyük bir sistem üzerinde çalışıyorum ve bu yüzden berbatım. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

Kodunuz ne kadar kısa ve sık sık okunuyor olursa olsun, her zaman hatalara sahip olma olasılığı vardır. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Hata yapmak insan ve bir programın doğru olduğunu asla kanıtlayamaz, o zaman neden bu zor işte kendimize yardımcı olmak için hata ayıklayıcı / otomatik test gibi araçları kullanmıyorsunuz?

Kod yeterince kısaysa, basit testler yapılır. Ayrıca, kısa ve hatanın doğasını biliyorsanız, kodu okumak yeterli olabilir. Bununla birlikte, kod tabanı büyük olduğunda, birlikte karıştırılan birkaç dil ve artı 3 kat içerir, o zaman birçok düzeyde iyi test kapsamına ve çok iyi bir hata ayıklayıcıya sahip olmanız gerekir - aksi takdirde çok fazla zaman kaybedersiniz.

Peki, ne zaman hata ayıklayıcıya ihtiyacım yok?

En akıllı kodlayıcı değilim, en tecrübeli değilim, ama yine de bazen hata ayıklayıcıyı kullanmam gerekmiyor. İşte o zaman:

• Kod benim veya iyi yazılmış AND
• Okunabilir bir dilde yazılmış VE
• Genel proje küçük.

Ne zaman bir hata ayıklayıcıya çok güveniyorum?

• Kısa Cevap: sık sık .
• Bir uygulama çöktüğünde. Özellikle konuşlandırıldığında. Bu bilgisayarda VS2010 yüklü olması "Bilinmeyen Hata" ile arasında bir fark yaratabilir FileNotFoundException.
• 3. taraf bir kütüphane çöktüğünde veya yanlış davrandığında.
• Kod kötü yazıldığında. Özellikle de aynı dosyaya son 10 yılda 10 farklı kişi dokunmuşsa, bunların 7'si artık şirkette değildir.
• Proje büyük olduğunda
• Kod oldukça yekpare olduğunda.
• Birden fazla katman (GUI, SQL, BL) olduğunda.

"Hata ayıklayıcı" nın birden fazla araca başvurabileceğini unutmayın. Visual Studio hata ayıklayıcı, SQL hata ayıklayıcı (çoğunlukla depolanan procs için) ve SQL profiler (hangi SP çağrıldığını bulmak için) de kullanın. Hızlı bir sysadmin-ish Python betiği yazdığım bu kalibre araçlara ihtiyacım var mı? Hayır. Kendi küçük GUI tabanlı aracımı yaparsam? Bağlı olmak. Net WinForms ise - muhtemelen değil. WPF ise - evet.

Zaten bir "gerçek" programcı ne tanımlar? Hızlı olanı? bilgili? Algoritmalarda iyi mi? İyi dokümantasyon yazar mı? Tam olarak ne zaman bu yeni unvana mezun olur? Büyülü çizgiyi ne zaman geçer?

100 yılı aşkın bir mevcut insan çabasıyla ellerini kirletmeyen bir programcının, karmaşıklık ve kendi sınırlamalarına (kod kalitesinden de öfkelenerek) alçalma şansı olmadığını söyleyebilirim.

Şahsen benim için mevcut olan en iyi hata ayıklayıcıyı kullanmaya çalışıyorum ve sık sık kullanıyorum. Bir görev yeterince basitse ve bir hata ayıklayıcı gerektirmiyorsa - o zaman kullanmıyorum. İhtiyacım olup olmadığını anlamak çok uzun sürmüyor.

...

Şimdi, teoride kod tabanını o kadar uzun süre okuyabiliyordum ki, sadece anlıyorum. Ancak, uygulamalı yaklaşım en iyi şekilde çalışır, artı sık sık gördüğüm o aptal kodu yeniden yazmak istiyorum. Ne yazık ki içinde olduğum kod tabanı temizlemek için 10 + yıl sürer. Bu nedenle, hata ayıklayıcı kullanmak açık bir ilk adımdır. Sadece 5 milyon kod satırından hangisinin harekete geçtiğini öğrendiğimde, o sınıfın ne yaptığını anlamaya çalışmak için dosyayı yukarı ve aşağı tarayabilirim.

"Hata ayıklayıcıları sevmiyorum. Asla sahip değil, muhtemelen asla. - Linus Torvalds

Öte yandan, bir Stack Overflow hesabı yok, bu yüzden onun fikriyle ilgilenip ilgilenmediğinden emin değilim :)

Sorumlu özel sorum şu durumlarda , deneyimli bir programcı olarak hangi hata ayıklayıcıyı kullanırsınız?

• Kodunuzu okuyarak "hata ayıklama" işlemi yapılamadığında.
• Belirli değişkenlerin belirli bir zamana sahip olduğu değerleri tahmin edemediğinizde .
• Senin ne zaman zihinsel modeli kodunuzun Kodunuzdaki tarafından verilen çıktıyı uymuyor

Düzenle:

Programlama yolculuğumda bir hata ayıklayıcıyı nasıl kullanacağımı bilmeme şansım / talihsizlik yaşadım. Böylece geçmişte bir hata ayıklayıcı olmadan hata ayıklamak zorunda kaldım. Ancak bir hata ayıklayıcı kullanmayı öğrendikten sonra -> Hata bulmada 100 kat daha üretken oldum .

Mevcut cevaplardan biraz farklı bir bakış açısı vermek; Genellikle gerçek zamanlı bir bileşeni olan sistemlerde çalışan gömülü bir yazılım mühendisi olarak nadiren hata ayıklayıcı kullanıyorum.

Bazen bir hata ayıklayıcı inanılmaz bir araç olabilir ve ne zaman bir masaüstünde kod oluşturmak ve çalıştırmak mümkün o zaman ben her zaman bir hata ayıklayıcı kullanırdım.

Çipte, gerçek zamanlı kısıtlamalar ile, bir hata ayıklayıcı kullanmaya çalışmakla ilişkili ağır bir yük vardır. Yürütmeyi duraklattığınız anda, muhtemelen ölümcül olarak, sistemin geri kalanının zamanlamasını üzersiniz. Genellikle çipte, kritik olmayan kodda printf ve zaman açısından kritik kodda IO sallama en iyi ve aslında en basit araçtır. Bir hata ayıklayıcı kadar iyi değildir, ancak gerçek bir sistemle çalışmak çok daha ucuzdur.

Sanırım deneyimli programcılar neredeyse sadece gerektiğinde hata ayıklayıcıları kullanıyorlar. Bir hatayı izlemek için kodun yürütülmesini takip etmekten daha iyi bir yol ...

Dünya Skeetlerinin hata yapmadığı ya da sadece her şeyi bildiği varsayımı altında mısınız? En önemsiz programlar hariç tümü, bazı durumlarda beklenmedik şekillerde davranır. Sorunların araştırılması gerektiği belirtiliyor. Yani seçimler, spektrumun bir ucunda print ifadeleri kullanmak ya da bakalım neler olduğunu incelemek, diğer taraftan ipotek göndermek ya da kod yürütülürken ve ortada neler olup bittiğini anlamak için ortada bakmaktır.

Belki de bunu düşünmenin daha iyi bir yolu, deneyimli programcıların hata ayıklayıcıyı ne zaman kullanacaklarını bilmeleridir. Yığın izine bakarak birkaç bağımlılığa sahip olan kodda, neyin yanlış olduğunu bulmak için muhtemelen yeterlidir. Ancak, kodunuzun diğer kodlarla çalıştığı karmaşık senaryolar vardır ve yazmadığınız şeylere bakmak için bir hata ayıklayıcıya ihtiyacınız vardır.

Yapmıyorum ve 10 yılı aşkın süredir program yapıyorum. C / c ++ 'da programladığımda alırdım. Şimdi java'da program yapıyorum. Gerçek şu ki, doğru şekilde oturum açıyorsanız, çoğu yetenekli geliştirici için yeterli olan bir yığın izlemesi ile sonuçlanacaksınız. Ayrıca, (iyi) birim testleri ve fonksiyonel testler yazıyorsanız, tüm hata sınıflarını ortadan kaldırır.

Seyrek.

Yöntemleriniz aklınız tarafından derlenip çalıştırılacak kadar küçük / basit olmalı, birim testleri işlevselliği kapsamalıdır. Bir hata bulursanız, bir test yazın. Çalıştır, düzeltin.

Yalnızca ASP.NET çerçevesi gibi denenemez koddan beklenmedik davranışlar aldığında hata ayıklayıcıyı kullanma eğilimindedir.

Smalltalk'ta neredeyse tamamen hata ayıklayıcıda gelişiyorum :

1. Başarısız olacağını bildiğim bir test yazın.
2. Testi çalıştırın. Başarısız olduğunda, hata ayıklayıcı açılır.
3. Hata ayıklayıcıda, testi geçmek için gerekli kodu yazın.
4. Yürütmeyi sürdür.
5. Yeşil ışık alırsam, yeni bir başarısızlık testi ile 1. adıma gidin. Aksi takdirde, hata ayıklayıcıda neyi yanlış yaptığımı öğrenin ve düzeltin.

Kimin umrunda? Bilmek istediğim bir hata ayıklayıcı kullanmak uzun vadede daha iyi bir programcı olmamı engelleyecek mi? Belki de birçok deneyimli geliştirici başladığında hata ayıklayıcılar daha düşük kaliteye sahipti ve bu yüzden bir saygınlıktı. Daha derin bir kavrayışı engelleyen bir koltuk değneği mi?

Muhtemelen geri kalanımızdan daha iyi olan bazı programcılar bir hata ayıklayıcıya ihtiyaç duydular ve bir tane oluşturdular. Bunun bir sonucu olarak daha üretken olduklarından eminim. Motivasyonun daha az ölümlülerin kod yazmasını sağlamak olduğundan şüphe ediyorum.

Gerektiğinde bir hata ayıklayıcı kullanıyorum. Bu günlük değil, ama bazen gerçekleşir. Tam olarak ne olduğunu görmek için bazen kodun içinden geçmek daha iyidir.

Hata ayıklayıcıları daha az kullandığımı itiraf etmeliyim. Delphi'de 10 yılı aşkın bir süredir gelişiyorum. Ayrıca PL / SQL'de saklı yordamlar yazıyorum. Birkaç aydan beri ben de PHP geliştiricisiyim.

Yıllar önce yazılmış bir gizli kod parçası bulursam ve bu kodu değiştirmem gerekiyorsa, hata ayıklayıcıyı her iki durumda da kullanıyorum. Bazen, kodu okumak zorsa, bir programın tam olarak nasıl çalıştığını bulmaya yardımcı olur. Çok az gerekli olan PHP'de, ancak olay tabanlı Delphi'de, bazen karmaşık bir çerçeveye sahip olduğunuzda yardımcı olur.

Ama dediğin gibi, hata ayıklayıcıyı kullanmak bir istisnadır. Çoğu sorun sadece kodu okuyarak ve sizin (veya bir başkasının) yaptığınız hataları düzelterek çözülür.

Ancak bu, koddan geçmek için geçerlidir. Bir istisna oluştuğunda sık sık çağrı yığını kullanıyorum ve bazen bir değişkeni incelemek için bir yere bir kesme noktası koydum. Ama neredeyse her zaman, yine de kapsamlı bir yeniden düzenleme gerektiren bir kod parçasında.

Bazen hiçbir hata ayıklayıcı olmadan kodlama, ancak sadece zoruyla zorlandığı zaman, yani. 8051 veya Z80'de eski gömülü gunge.

IMHO, herhangi bir karmaşık işte bir hata ayıklayıcı ve oturum açmanız gerekir. Bir kere diğerinin yerine geçmez. Örneğin, kodun yapabileceği tek şey donanımla etkileşim kurmak ve bir semafor ayarlamaksa, uygulama bir sürücüde yer alıyorsa bir günlük sistemi yardımcı olamaz.

Bir hata ayıklayıcı, uygulamaların yazdığınız şekle göre iyi çalıştığı bir sistem hatasıyla yardımcı olamaz, ancak bazı aralıklı iletişim protokolü hatası nedeniyle sistem hala çalışmaz.

Yani, aptal, apaçık hataları ve donanım cockups kaldırmak için hata ayıklayıcı gerekir. Aralıklı sistem entegrasyonu hatalarını yakalamak için iyi bir kayıt tutmaya ihtiyacım var.

İkisine de sahip olmalıyım - alabileceğim tüm yardıma ihtiyacım var!

Hata ayıklayıcıyı yalnızca bu adımlar başarısız olduğunda kullanırım:

1. Hatayı tekrarlanabilir hale getirin. Düşünün. Bu genellikle ihtiyaç duyulan her şeydir.
2. Yığın izini ve günlükleri kontrol edin.
3. Sorunlu kodun etrafına daha fazla günlük ekleyin.

Bu adımlar tüm vakaların% 95'ini halleder. Bu, nadiren bir hata ayıklayıcı kullandığım anlamına gelir ve bunu yaptığımda bana çok fazla bilgi verme eğilimi gösterir ve ilgisiz ayrıntılarda bataklığa uğrarım. Bu özellikle çok iş parçacıklı, gerçek zamanlı bir sistem üzerinde çalışırken geçerlidir.

Bu yüzden, mantıklı bir şekilde yerleştirilmiş günlük ifadeleri uzun bir yol kat ediyor.

Çok deneyimli programcıların çok eski programcılar ile aynı olması ve hata ayıklayıcıların her zaman mevcut olmadığı ve bazen çok iyi olmadığı zaman programlamayı öğrendikleri ve alışkanlıklarını oluşturdukları olabilir mi?

Printf hata ayıklamada gerçekten iyi olursanız (ve seksenlerde geri dönersek, gerçekten iyi olmaktan başka seçeneğimiz yoktu), belki bir hata ayıklayıcı bu kadar eklemez.

Bu kişisel seçim meselesi.

Dürüst olmak gerekirse, hata ayıklayıcıların, programınızın yürütülmesinin herhangi bir adımında koçunuzda ne olduğunu bilmenin çok yardımcı olduğu bazı durumlarda yararlı olduğunu düşünüyorum.

Bir hata ayıklayıcının birincil yardımcı programı, program kendisini durduracak şekilde tasarlanmadan durdurmaktır: bu özellik oldukça önemlidir.

Bu 2 özellik dışında bir hata ayıklayıcının gerçekten gerekli olduğunu düşünmüyorum; Yaptığınız herhangi bir karmaşık program bir çeşit "ayrıntılı" moda sahip olmalıdır, yani printf veya std :: cout ile yaptığı her şeyi, yaptığı seçimleri ve diğer birçok parametreyi anlatmalıdır.

Bir program yaptığınızı ve kullanıcının onu kullanırken bir problemi olduğunu hayal edin: Kullanılmak üzere tasarlandığı şekilde kullanıp kullanmadığını veya şikayet ettiği şey bir hata olabilir mi?

Hata ayıklayıcılar aracınızın elektrikli direksiyonuna benzer: bir tane daha rahattır, ancak sürücünüzü daha iyi yapmaz.

Programlama, tasarım ve mantıkla ilgilidir, araçların şeyleri izlemenize yardımcı olma yolu sizi daha iyi bir programcı yapmaz.

Ayrıca hata ayıklayıcılar, derlenmiş diller için yararlıdır, yorumlanmış diller için çok daha azdır.