Uygulama hatalarının işlenmesi
Er ya da geç herkesin başına gelir: bir uygulama çalışmaz. Herhangi bir hata, çalışmaya devam etmenizi engeller. Hoş değil ama bununla baş etmeyi öğrenebilirsin.
Bir geliştirici olarak geçirdiğim yıllar boyunca, ne kadar çok konunun kendi patronu olduğunu varsaydığına her zaman şaşırmışımdır. Bir klasik, uygulama hatalarıyla ilgilidir. Ve bu blog gönderisinin konusu da tam olarak bu. Özellikle edinim ve aktarım konusunda, kullanıcının bakış açısından ve aynı zamanda bir dereceye kadar geliştiricinin bakış açısından.
bilgi toplamak
Eğer bir hata oluşmuşsa ve onu düzeltmeden mevcut işinize devam edemiyorsanız bir sorununuz var demektir. Kendiniz düzeltmeniz veya bir başkasının düzeltmesi gerekip gerekmediği önemli değildir: olay sırasında veya kısa bir süre sonra hata hakkında bilgi toplama fırsatı vardır. Tercihen dijital formatta ve yazılı olarak, mümkünse ekran görüntüleri ile birlikte. Hatalı bir çıktı dosyası gibi hatanın sonuçları da sonraki analize yardımcı olur.
Prensip olarak, bilgilerin toplanması anahtar sorular temelinde yapılandırılabilir. İşte bazı örnekler:
- Hatayı üç cümleyle nasıl tarif edebilirsiniz?
- Hangi sistem etkilenir?
- Hangi uygulama etkilenir?
- Hata ne zaman oluştu?
- Hatanın etkileri nelerdir?
- Hata nasıl yeniden üretilebilir?
Mantıklı görünüyor, ancak doğal olarak gelmiyor, başka bir deyişle, soruların önceden koordine edilmesi gerekiyor. Daha da iyisi: hata tespitini eğitin ve bunu tekrar tekrar yapın. Orada iyileştirme için çok yer olduğunu düşünüyorum. Örneğin çözümün bir parçası olarak sık sık takip etmeniz gerekse bile, hata mesajlarını elektronik olarak günlüğe kaydetmek için yalnızca bir bilet sistemi çözüm değildir. Bununla birlikte, temelde, böyle bir sistemde depolanan bilgilerin önemi ile ilgilidir.
Hataları tüm bilgiler bağlamında görüntüleyin
Bilgileri doldurduktan sonra, genellikle unutulan veya kasıtlı olarak atlanan önemli bir adım gelir. Özellikle şirketin organizasyonu nedeniyle sorun gidermeden destek gibi başka bir departman sorumlu olduğunda.
Niyet ettiğim adım, toplanan bilgileri yeniden düşünmek. Zaten çözümün bir ipucu var mı? Bağlantıları belirlemek mümkün mü? Hatta tüm bilgi durumuna uzaktan bakarsanız hatayı kendiniz düzeltebilirsiniz. Deneyimlerime göre, bu adım genellikle atlanır. Hatayı yansıtmadan bildirebilirsiniz. Çözüm nihayetinde başkasına aittir.
yardım almak
Bir hatayı kendi başına düzeltemeyen veya düzeltmesine izin verilmeyen herkes yardım almalıdır. Örneğin destek departmanından. Toplanan bilgiler biçimindeki iyi temel çalışmalardan genellikle memnunsunuz. Bu, kapsamlı sorgulardan tasarruf sağlar ve hatanın nedeninin analizine hızlı erişim sağlar. Bu arada, sorular için müsait olmalısınız.
Burada kesinlikle çok ideal bir durumu anlatıyorum. Herkesin destekle ilgili kendi deneyimleri vardır. Bazıları hala bu deneyimleri işliyor veya hayatlarının geri kalanında unutamayacak (veya unutamayacak). Ancak, çözüme katkıda bulunmanız önemlidir. Başkalarının işlerini nasıl yaptıkları onlara kalmış.
Geliştiricilerin yapabileceği olumlu katkı
Başta da belirtildiği gibi, bu makale aynı zamanda geliştiricinin “hataları tespit etme” konusundaki bakış açısıyla ilgilidir. Burada esas olarak “nitelikli hata mesajları” konusuna, yani mevcut hata durumu için bir anlamı olan bir hata mesajına atıfta bulunuyorum.
Deneyimlerime göre, örneğin hata mesajının uzunluğunda bir sınır gibi teknik kısıtlamalar olduğunda mantıklı bir şey üretmenin ne kadar zor olabileceğini biliyorum. Doğru kelimeleri bulmak her zaman kolay değildir. Mesaj bir hata hakkında daha fazla teknik bilgi mi yoksa teknik bilgi mi vermeli?
Dikkate alınması gereken birçok yön var ve çok fazla düşünce gerekiyor. İyi olan şey, bu hususların bir veya daha fazla geliştirici tarafından ele alınabilmesidir. Aksi takdirde, binlerce kullanıcı tahmin edebilir ve tahmin edebilir. Bu dengesizlik tek başına pozitif potansiyele yol açar. Ancak hepimiz uygulamadan bunun nasıl çalıştığını biliyoruz.
Bunu akılda tutarak, yapılandırılmış ve sağlıklı kalın
senin Michael’ın
()
Haberin Sonu