Önemsiz düzeltmeleri günlüğe kaydetmeli miyim?

İkilik bir kod dükkanındayım. Ve bir hata izleyicinin programcı sayısının bire eşit veya daha fazla olduğu yerlerde yararlı olduğunu anladığım halde, günlük hatalarının, değişikliklerin ve düzeltmelerin önemsiz oldukları zamana değecek kadar ikna olmadım. Basit bir hata bulduğumda anlıyorum, düzelttim ve bazı testlerden geçirdim. Ve sonra farkettim ki giriş yapmam gerekiyor.

Teoride, hata günlüğü hata bulma ve hata düzeltme arasında bir yerde yapılması gerektiğini biliyorum, ancak bunu düzeltmek günlüğe kaydetmekten daha hızlı ise, bir sürükleme gibi görünüyor. Daha büyük kod dükkanlarında, patron kimin ne yaptığını önemser ve başkalarının neyle uğraştığını bilmek güzeldir.

Kendimi önceden düzelttiğim şeyleri açıklarken bulup anında kapatıyorum. Herkesin bu kapalı hatayı tekrar görebileceğine dair şüphelerim var. İşlemi kesmenin zamanı geldi mi?

Yaptığınız her değişikliği sisteminize kaydetmelisiniz. Olaydan sonra günlüğe kaydetmede yanlış bir şey yoktur - hata raporunu değişiklik numarasına bağladığınız sürece.

Eğer bir şey ters giderse, hatayı takip edebilir ve yaptığınız değişikliği neden yaptığınızı öğrenebilirsiniz .

Vakaların büyük çoğunluğunda haklısınız ve hiç kimse bunlara bir daha bakmayacak, ancak 100'ün 1'inde bir şeyler ters gittiğinde bu bilgi paha biçilmez olacak - özellikle de sorun sadece 6 ay aşağıya çıkıyorsa.

GÜNCELLEŞTİRME

Açıkçası, hala yeni bir özellik geliştiriyorsanız ve bittiğinizi düşündüğünüz özelliğin bir bölümünü keşfederseniz, ayrı bir değişiklik olarak kaydetmeniz gerekmez. Bu durumlarda, ana özelliği isteyen öğeye karşı giriş yapardım.

Özelliğe sahip sistem KG veya müşteriye geçtikten sonra , yukarıda ana hatlarıyla belirtilenleri yapmak gerekir.

Bir kaynak kontrol aracı kullanıyorsanız, işlem açıklamasında düzelttiğiniz hatayı tanımlayabilirsiniz ve bu, süper küçük, önemsiz hata düzeltmeleri için genellikle yeterli belgelerdir.

Ayrıca, FogBugz ve Kiln gibi kaynak denetiminiz ve depolarınızla tam olarak entegre olan bir hata / özellik izleyici kullanıyorsanız, bu hata düzeltmelerini bulmak ve hangi kodda yaptığınız değişiklikleri görmek için global arama aracını kullanabilirsiniz. kolayca.

Ayrıca, programlama ortağınıza bir kod incelemesi atayabilirsiniz, böylece yaptığınız önemsiz düzeltmeyi gözden geçirebilir, ancak ayrılıyorum ...

Metrik bakış açısından hala faydalı olabilir.

Bu bilgiler patrona bir çok şeyi göstermek için kullanılabilir:

• daha fazla geliştiriciye ihtiyacımız var
• İşlemdeki başka bir şey bozuldu (neden bu kadar çok böcek? diğer adam böceklerin çoğunu üretiyor), belki de size çok fazla böcek olduğunu gösteriyor. Belki buna neden olan bir şey vardır? çok mu serbest bırakıyorsun yeterli test yapılıyor mu?
• üzerinde çalıştığınız şeylerin iyi bir listesi bonus zamanıdır.

Her şey söyleniyor, bahsettiğiniz bir böcek ne kadar küçük olduğuna bağlıdır. Yeni bir kod eklerken fark ettiğiniz liner'ler, örneğin giriş yapmak için anlamsız olacaktır.

Büyüklüğünden bağımsız olarak yaptığım her değişikliği kaydetmeye çalışıyorum. Siz veya bir başkasının (gelecek veya şimdiki zaman) geri dönüp, bu değişimin başka bir şeyin olası nedeni olup olmadığını asla bilemeyeceksiniz.

İzleme önemlidir, ancak başka bir senaryoyu da göz önünde bulundurun: inceleme zamanınız geldiğinde. Patronunuzdan hata izleyiciden raporlar alarak resmi olarak şahsen veya gayri resmi olarak orada olacaksınız.

Numaranızı artırmalarını sağlayan 'hile' olarak düşünün. Ne de olsa, onlar sizin giderdiğiniz hatalardır ve önemsiz düzeltmeler olsalar bile onları düzeltmek için tanınmanız gerekir.

Onları kaydet.

Buna cevap vermek, bu süreçte nerede olduğunuza bağlıdır.

Bunlar yeni bir proje veya tasarlanan yeni bir özellik için geçerli olabilir.

İlk Tasarım İlk tasarım sırasında yarattığımız koddaki hataları bulursanız, bunun için bir hata izi oluşturmak gerekli olmaz. Değişiklik için ayrı bir taahhüt önereceğim, böylece daha sonra sorun yaşarsanız kolayca çözebilirsiniz.

Test yapmak

Kod her zaman hala ünite testi sırasında hala imkansız kabul edilir, bu yüzden farklı bir grup tarafından yapılmadığı sürece hayır diyeceğim. Ünite testi, bir hata izleyiciden farklı bir grup tarafından yapılırsa, test prosedürünü resmileştirmenin iyi bir yoludur.

CSCI testi bağlıdır. Başka bir grup tarafından mı yapıldı? Eğer öyleyse o zaman evet (yukarıya bakın). Bu, yayınlanmadan önceki testin son adımı mı? Öyleyse evet, çünkü bu noktada yazılımınız olgunlaşmış kabul edilmelidir. Metriklerle ilgileniyorsanız, bu noktada hataları izlemeye başlamak da iyi olacaktır.

Herhangi bir daha yüksek test seviyesi için hata izlemeyi kullanmanız gerekir. Bu noktalarda yazılımınız olgunlaşmış kabul edilmelidir ve izleme hataları önemlidir.

Serbest bırakmak

Her zaman yayınlanan koddaki hataları takip etmelisiniz. Bu hesap verebilirlik için önemlidir.

İhtiyaçlarınıza uygun bir süreci kolaylaştırmak da önemlidir. Gerçekten çok büyük bir hata takip sistemine mi ihtiyacınız var? 2 kişilik bir ekip için tüm alanlar gerçekten bu kadar önemli mi?

Belki de dış dünyaya yayımlanan yazılımın daha eski bir sürümünde, başka birisinin hatayla karşılaşması mümkün mü? Öyleyse, hem hatayı hem de düzeltmeyi günlüğe kaydetmek yararlı olabilir.

Diğerleri, hatayı düzeltmek yerine düzeltmek için daha uzun sürerse, kaydetmeye değer olmadığını belirtti. İlgili zaman aralığının hatayı bulmak ve düzeltmek arasında olmadığını, hatanın ortaya çıktığı zaman ile düzeltmenin serbest bırakıldığı zaman arasında olduğunu düşünüyorum.

Değişiklik ve bırakma geçmişi, hatanın gün ışığını hiç görmediğini gösteriyorsa, kaynak kontrolüne girdiğinizde düzeltmeyi günlüğe kaydetmeniz yeterli olacaktır.

Bu, bu soruya oldukça yakın , ancak bunun önemsiz düzeltmelere odaklandığından, bunun yinelendiğinden emin değilim .

Neden Jon Arid Torresdal tarafından böcek izlememelisiniz - bunun yerine bunları düzeltin.

1. Geliştirme sırasında: Bir özellik için bir hatayla karşılaşıyorsunuz; Eğer yapı kırar bir test vakası eklemek , daha sonra özelliği karşı düzeltme kontrol edin.

2. Serbest bıraktıktan sonra: davranışı belgeleyin . Bir güncelleme yayınlamayı planlıyorsanız, 1. adıma geçin. Bu sürümden sorumlu değilseniz, test + düzeltmeyi özel bir şubede saklayın.

Kod yayınlandıktan sonra başka öncelikler olabilir ve hatayı düzeltmek önemsiz olsa da, sürekli bir dağıtım yapmazsanız düzeltmenin dağıtımı kendi başına ekonomik olmayabilir.

Bağlı nasıl , ben bu tedbiri kullanmak önemsiz:

O alırsa artık o aldı daha bunu günlüğe düzeltmek o, o değil değer o günlüğü.