İşlem mesajındaki hataya / soruna gönderme iyi bir uygulama olarak değerlendiriliyor mu?

11

Kaynak denetleyicisinin otomatik olarak hata izleyiciye not yazmak için ayarlandığı bir proje üzerinde çalışıyorum. Hata mesajı kimliğini kayıt mesajına yazıyoruz ve kayıt mesajı hata izleyiciye not olarak ekleniyor.

Bu uygulama için sadece birkaç olumsuz tarafı görebiliyorum. Gelecekte kaynak kodu hata izleme yazılımından ayrılırsa (veya bildirilen hatalar / sorunlar bir şekilde kaybolur). Veya birileri taahhütlerin tarihine bakarken, ancak hata izleyicimize erişimi olmadığında.

Sorum şu: taahhüt mesajında bir hata / sorun referansı olması iyi bir uygulama olarak kabul edilir mi? Başka dezavantajları var mı?

programming-practices version-control issue-tracking

— Christian P
kaynak

10

Bu uygulamayı benimsedik ve bizim için çok iyi çalışıyor. Sürüm kontrol sistemi (VCS) ile kullandığımız diğer sistemler arasında sıkı entegrasyon, örneğin sürekli entegrasyon, hata izleyici vb. Son derece değerlidir. Gelecekte herhangi bir şeyi değiştirirsek, kesinlikle VCS ve hata izleme sistemi arasındaki bağlantılar da dahil olmak üzere yan etkileri değerlendirmek zorunda kalacağız.

Genel olarak bunu iyi bir uygulama olarak görüyorum. Bazı izleme sistemleri için, Subversion (SVN) için bugtraq özellikleri gibi ek seçenekler ve araçlar mevcuttur . Bu, oldukça az kişinin bu uygulamada değer gördüğünü göstermektedir.

— Manfred
kaynak

13

Gerçekten, gerçekten farklı bir hata izleyici kullansanız veya hata izleyici verileriniz bir şekilde kaybolsa bile hiçbir bilginin kaybolmadığından emin olmak istiyorsanız, neden sadece sorun kimliğini ve hatayla ilgili kısa bir açıklama eklemiyorsunuz? taahhüt mesajı?

Hata # 123: Giriş yaptıktan sonra uygulama kilitlendi

Daha sonra, taahhütlerin geçmişinden hata izleyiciye bağlantı var - ve hata izleyicinin hiç kullanılabilir olmaması gerekiyorsa, hala bu hatanın ne hakkında olduğunu görebilirsiniz.

— Christian Specht
kaynak

Aslında bunu yapıyoruz, bu yüzden taahhütlerin geçmişine her göz attığımızda hata izleyiciye geçmek zorunda değiliz.

— Christian P

Tamam, o zaman olduğu gibi bırakırım. IMO, bunu yapmanın en iyi yolu bu!

— Christian Specht

1

Evet, iyi bir noktaya değindiniz. Yine de bu benim varsayımımdı. Sadece hata / sorun kimliği tek başına benim deneyim yeterli değil. Taahhüt günlüğüne baktığınızda, her bir taahhüdün ne hakkında olduğunu görmek istersiniz, örneğin bu kod değişikliğinin geniş nedeni neydi? Hata izleme sistemi metni yazılım kullanıcılarına daha fazla yönelik olurken bazen taahhüt mesajı teknik açıdan daha fazladır.

— Manfred

Bu genellikle de çalıştığım standart uygulama oldu, bence bunu yapmanın doğru yolu.

— Carson63000

+1 her zaman bunu yapar! Ben sadece "Bu hata 5423 nedeni olabilir" gibi taşlar ile dolu bir projenin bakımını aldı Onların hata izleyici erişemez.

— Kryptic

2

Bu çok yaygın bir uygulamadır ve son derece elverişli buldum. TRAC kullanıyorum, böylece kod geçmişini okuyabilir ve değişikliği yönlendiren göreve ya da görev geçmişini okuyabilir ve kod değişikliklerine gidebilirim.

"Gelecekte bir zaman ..." Kodu hata izleyiciden ayırırsanız, eski düzeltme geçmişi muhtemelen daha fazla ilgi çekmeyecektir.

— kevin cline
kaynak

2

Ben de bu uygulamayı kullanıyorum ve çok iyi bir uygulama olarak görüyorum. Ancak sorun kimliğinin yanı sıra, hata / özellik (genellikle hata izleme sisteminden başlık) hakkında kısa bir açıklama ekliyorum. Bu genellikle zamandan tasarruf etmenize yardımcı olur, çünkü hata izleme sistemine bakmak zorunda değilim (çünkü değişikliği tanıyorum) VE dediğin gibi, eğer hata izleme sistemini bir şekilde kaybedersem, tamamen kaybolmadım.

— Nicolae Albu
kaynak