Hata İzleyici Nasıl Kullanılır

Bunlara hata, kusur, hatta tasarım yan etkileri deseniz de, onlardan kaçış yoktur. İyi bir hata raporunun nasıl gönderileceğini ve ayrıca bir tanesinde nelerin aranacağını bilmek, bir projenin güzel bir şekilde ilerlemesini sağlamak için temel becerilerdir.

İyi bir hata raporunun üç şeye ihtiyacı vardır:

• Hatanın mümkün olduğunca kesin olarak nasıl yeniden oluşturulacağı ve bunun ne sıklıkla hatanın ortaya çıkmasına neden olacağı.

• En azından sana göre ne olması gerekirdi.

• Gerçekte ne olduğu veya en azından kaydettiğiniz kadar bilgi.

Bir hatada bildirilen bilgilerin miktarı ve kalitesi, hata hakkında olduğu kadar rapor eden hakkında da çok şey söyler. Kızgın, kısa hatalar ("Bu işlev berbat!"), geliştiricilere kötü zaman geçirdiğinizi söyler, ancak başka bir şey değil. Çoğaltmayı kolaylaştırmak için bol miktarda içeriğe sahip bir hata, bir sürümü durdursa bile herkesin saygısını kazanır.

Hatalar, herkesin önünde tüm geçmişi olan bir sohbet gibidir. Başkalarını suçlamayın veya hatanın varlığını inkar etmeyin. Bunun yerine daha fazla bilgi isteyin veya neleri kaçırmış olabileceğinizi düşünün.

Bir hatanın durumunu, örneğin Açık'ı Kapalı olarak değiştirmek, hata hakkında ne düşündüğünüzün genel bir ifadesidir. Hatanın neden kapatılması gerektiğini düşündüğünüzü açıklamak için zaman ayırmak, hayal kırıklığına uğramış yöneticilere ve müşterilere haklı çıkarmanın ardından sıkıcı saatler kazandıracaktır. Bir hatanın önceliğini değiştirmek benzer bir genel açıklamadır ve sizin için önemsiz olması, başka birinin ürünü kullanmasını engellemediği anlamına gelmez.

Kendi amaçlarınız için bir böceğin alanlarını aşırı yüklemeyin. Bir hatanın konu alanına "VITAL:" eklemek, bazı raporların sonuçlarını sıralamanızı kolaylaştırabilir, ancak sonunda başkaları tarafından kopyalanacak ve kaçınılmaz olarak yanlış yazılacak veya başka bir raporda kullanılmak üzere kaldırılması gerekecektir. Bunun yerine yeni bir değer veya yeni bir alan kullanın ve diğer kişilerin kendilerini tekrar etmesine gerek kalmaması için alanın nasıl kullanılması gerektiğini belgeleyin.

Herkesin, ekibin üzerinde çalışması gereken hataları nasıl bulacağını bildiğinden emin olun. Bu genellikle açık bir ada sahip genel bir sorgu kullanılarak yapılabilir. Herkesin aynı sorguyu kullandığından emin olun ve herkesin üzerinde çalıştığı şeyi değiştirdiğinizi ekibe bildirmeden bu sorguyu güncellemeyin.

Son olarak, bir hatanın standart bir iş birimi olmadığını, bir kod satırının kesin bir çaba ölçümü olmadığını unutmayın.

Matt Doar Tarafından