Kullanıcıların bir özellik olduğunu düşündüğü hataları nasıl tedavi edebilirim?

Soru :

Son kullanıcının bir özellik olduğunu düşündüğü bir hatayı ele almanın doğru yolu nedir?

Detaylandırma :

Kullanıcıların büyük bir yüzdesi bir özellik olarak bekleniyorsa, daha kararlı olması için "sabit" veya "sabit" bırakılması gerektiğini tahmin ediyorum? Ancak, kullanıcıların çok küçük bir yüzdesi bir özellik olmasını beklerse ...% 0.1 veya% 1 deyin ve bu hatanın düzeltilmesi gerekir.

Teorik olarak, bu küçük bir hata düzeltmesi olduğundan, anlamsal sürümleme ile göz önüne alındığında PATCH olarak nitelendirilebilir: xyZ Ancak, geriye dönük uyumluluğu bozduğu için (sadece birkaç kullanıcı için bile) BÜYÜK bir artış olmalıdır: Xyz Doğru mu? Belgelendiği sürece hala bir PATCH (özellik olarak tasarlanmadığı için) olarak nitelendirilebilir mi?

EDIT: Bu özel durumda, diğer geliştiricilerin kullandığı, dahili olarak kullanılan bir kitaplığın API'sindeki bir hata.

Kullanıcıların büyük bir yüzdesi bir özellik olarak bekleniyorsa, daha kararlı olması için "sabit" veya "sabit" bırakılması gerektiğini tahmin ediyorum?

Hata değer katıyor mu? Öyleyse, daha çok bir özellik. Bazen bir "hata" katma değer "özelliği" olarak ortaya çıkabilir.

Buna kesin olarak cevap vermek zor çünkü her bir durum farklı olacak.

Bu özel durumda, diğer geliştiricilerin kullandığı dahili olarak kullanılan kitaplığın API'sındaki bir hata.

Bu durumda, geriye dönük uyumlulukla ilgili bir sonraki kırılma değişikliğinizin bir parçası olarak bir düzeltme eklerim. Sen olamaz gerçekten sadece çoğu ortamda sürekli bunu yapmak ve bir zamanlama / zaman çerçevesi bunun için muhtemelen var.

Bir geliştirici olarak uğraşmak istediğim son şey yanlış veya tutarsız davranışları olan bir API. Hatalar bu kabul edilir.

En azından, dahili olarak "mevcut sürüm ile bilinen hatalar" türünü / wiki türünü oluşturun ve böylece tüm dahili kullanıcılarınızın işlevselliğin hataya benzer olduğunu bilmelerini sağlayabilirsiniz. Umarım insanların bir özelliği olarak hata kullandıkları alanları kapsayan yeterli testiniz vardır, böylece hatayı ne zaman / ne zaman düzeltirseniz işlerin nerede / ne zaman kırıldığını göreceksiniz.

Daha kararlı hale getirmenizi tavsiye ederim. Kullanıcılar, yazılımınızın yaptığı kanonik kaynaktır. Eğer istiyorlarsa ve ona güvenmeye geldiyse, iki kez sormayı düşünürdüm.

Buna iyi bir örnek, video oyunu "Kabileler" deki "Kayak" teknisyenidir. Başlangıçta fizik motorunun bir tepede zıplamayı nasıl ele aldığına dair bir hata, çekirdek oyun mekaniğinden birini buldu. Merak ediyorsanız, burada biraz daha okuyabilirsiniz .

Hata bir kütüphanede bulunduğundan, alabileceğiniz başka bir yaklaşım:

1. Hatalı kütüphane işlevinin bir klonunu yapın. Çoğu durumda, insanlar 2bu durumlarda işlev adına yalnızca a ekler , ancak bu işlevin arabirimine uygulamak istediğiniz başka değişiklikleriniz varsa, buna tamamen farklı bir ad da verebilirsiniz.

2. Yalnızca klondaki hatayı düzeltin (ve siz o sırada istediğiniz diğer tüm arayüz değişikliklerini uygulayın).

3. Orijinal işlevi kullanımdan kaldırılmış olarak bildirin.

4. Yakında çıkacak bazı büyük sürümlerde orijinal işlevi kaldırın.

Bu yaklaşım özellikle arayüzü temelde bozulan işlevler için kullanışlıdır: Kullanıcı kodunu hemen kırmazsınız, ancak bozuk kodu kullanmaya kimin sabit kod kullanacağına güvenen bir uyarı verirsiniz. Ve insanlar uyarıyı dikkate almasa bile, kırık işlevi gerçekten kaldırdığınızda sizi gerçekten suçlayamazlar.

Bu özel durumda, diğer geliştiricilerin kullandığı dahili olarak kullanılan kitaplığın API'sındaki bir hata.

Bu diğer geliştiriciler davranışın bir özellik olduğunu düşünüyorlarsa, muhtemelen onu kullanmış ve üzerinde çalışan yazılımlar oluşturmuş olabilirler. Hatayı düzeltmek muhtemelen mevcut kodlarını kıracak ve sizi bunun için suçlayacak. Bu, hatayı düzeltmeyi bir takas haline getirir ve dikkate almanız gerekir

• hatayı düzeltmek gerçekten önemli mi, örneğin, hata düzeltilmemesi durumunda API'nızın kullanıcılarının uygulamalarını çökmesine izin verme riski yüksek mi? Yoksa bu sadece API'nin tutarlılığıyla mı ilgili?

• veya mevcut yazılımı sabit tutmak ve kitaplığınızı geriye doğru uyumlu tutmak daha mı önemlidir?

Sorunun cevabı her zaman basit değildir, API'nızın olası kullanıcı sayısını, yazılımlarını değiştirmek zorunda kalacakları potansiyel işi, API'nizi değiştirirseniz kırılacak yazılım miktarını dikkate almanız gerekir. , aynı zamanda değil API düzeltin.

"Bir sonraki büyük sürümünüzdeki değişikliklerin kırılması listesindeki" hata düzeltme değişikliğini belgelemeniz, müşterilerinizi mutlu etmiyor - bunu yaparsanız, API'yı neden bu kadar izin veremediğinize dair en azından bazı kurşun geçirmez kanıtlar olmalıdır. önceydi. Genellikle geriye dönük uyumluluğu korumak bir hatayı düzeltmekten daha önemlidir. Bu yüzden, yalnızca kullanıcı tabanınız ve yazılımları üzerindeki etkisini tahmin edebiliyorsanız ve en son kütüphane sürümünüze güncelleme yapmaya çalıştıklarında onlar için makul olmayan çabalar üretmeyeceğinizden eminseniz düzeltin. Ve bu konuda iyi bir tahmin yapmak için yeterli bilginiz yoksa, davranışı değiştirmemek daha iyi olacaktır.

(Ve evet, geriye dönük olarak uyumlu olmayan bir API değişikliği yapacaksanız, sürüm numaralarınız bunu açıkça ifade etmelidir, "bugfix" olarak adlandırıp adlandırmamanız önemli değildir).

Kucakla. Tüm ürününüzü yapabilir.

GunZ: The Duel (çevrimiçi bir oyun), tüm oyunu (K-Style olarak adlandırılan; YouTube'a bakın) değiştirmek için istismar edebileceğiniz ve sürekli kötüye kullanabileceğiniz bir hataya sahipti. Tüm oyunu daha zorlu hale getirdi; beceri aldı ve sadece şaşırtıcı ve eğlenceli yaptı .. o kadar eğlenceli ki moderatörler bile ana oyun tarzı olarak açıkça kullandılar. Oyunu yapan da
buydu .
Yıllar içinde oynamadım ama bu güne kadar, bir oyuncu olarak, tüm zamanların en sevdiğim oyunlarından biri çünkü çok yetenekli ve çok eğlenceli ve bu hataların hepsi sadece bir hata yüzünden.

Sonunda düzelttiler, ancak insanlar o kadar çok nefret ediyordu ki geliştiriciler onu ciddiye aldı.

Yani cevabım stabilize etmek ve bakımını yapmak (gerekirse yeniden düzenleme).

Bu güzel hikaye söyleniyor, aynı cevabın doğrudan bir avantajı olmayan herhangi bir şey için geçerli olduğunu düşünmüyorum. Hatanız avantaj sağlayan bir olaya neden oluyorsa, hatayı düzeltmek daha akıllıca olur ve mümkün olan her şeyi başarmanın başka bir yolunu bulur. Kapsam dışındaysa, yalnızca kapsamın dışında olduğu için dışarıda bırakmayı düşünün veya tanıtmak için başka bir modül (belki küçük bir modül) oluşturun. Temel olarak: tek sorumluluk ilkesini ihlal etmeyin .