Hata 5 yaşından büyükse, bu bir özellik midir? [kapalı]


18

Ayrıntıları eklememe izin verin: Birçok kodlayıcı, test kullanıcısı, KG analisti, ürün sahibi vb. İle kurumsal bir yerde çalışıyorum ve işte beni rahatsız eden bir şey:

On yıldan uzun bir süredir berbat (oldukça işlevsel olsa da) yazılımlar satmayı başardık. Birçok özelliği var ve ürün rekabetçi, ama orada bazı ciddi hatalar yanı sıra binlerce "kağıt kesim" - müşterilerin alışması gereken küçük sıkıntılar.

Bazı şeylere bakmak beni üzüyor çünkü bilgisayarlar hayatımızı kolaylaştırmak için yardımcı olmazsa, onları kullanmamamız gerektiğine kesinlikle inanıyorum. Meslektaşlarıma güveniyorum - akıllılar, yetenekliler ve odaklanma bunu yaparken işleri geliştirebilirler.

Ancak, bazı eski işlevlere karşı hataları kapalı veya unutulmuş olarak görmeden dosyalamak zor olabilir. "Bu eonlar için böyle çalıştı" tipik bir cevaptır. Ayrıca, KG regresyon yaptığında, doğru görünmeyen herhangi bir şey kadar farklı olan herhangi bir şeyi arama eğilimindedirler. Bu nedenle, eski bir soruna yönelik bir düzeltme bir hata olarak yazılabilir, çünkü "benim zamanımdan önce bile böyleydi".

İçimdeki genç kodlayıcı düşünüyor: bu çılgınca şeyi yeniden yaz! Satış, müşteriye yakın olma şansına sahip biri olarak, bu yaklaşıma şüphe etmek istiyorum.

Ben de senin fikrin / tecrübenle ilgileniyorum. Lütfen risk, fayda-maliyet ve diğer teknik olmayan faktörleri göz önünde bulundurmaya çalışın.


2
Sanýrým "... eonlar için böyle çalýţtýn" demek istiyorsun.
Soğan-Şövalye

Asla yeniden yazmayın. Kendi üzerine çöken (kırma şeyleri ile daha fazla ekleyemezseniz) daha fazla hata ortaya

Eğer şimdi müşteri kaybetmiyorsanız, bir gün yapacaksınız. Birisi sonunda insanları yazılımlarının sizinkinden daha kolay olduğuna ikna edecektir. Şimdi, muhtemelen bununla baş etmemelisin. Bu şirketinizdeki bir kültür değişikliğidir ... tek başınıza yapabileceğiniz ya da yapmanız gereken hiçbir şey yok.
Brad

Yanıtlar:


14

Acını hissediyorum.

Ancak bir şeyi sadece bir hata olduğu için düzeltmek yeterince iyi bir neden değildir.

Düzeltmenizin diğer kodları kırmayacağından emin olmalısınız (sadece sizin değil, kodunuzu kullanan müşterilerinizin kodu). Bir düzeltme gönderirseniz ve bu her müşteri sistemini bozarsa çok hoşnutsuz müşterileriniz olur.

Eski bir sistemin yerini almak için yeni kodların yazıldığı birçok ünlü örnek var. Kullanıcılar bu hataya bağımlı oldukları için açıkça eski sistemdeki bir hatanın işlevselliğini eklemek zorunda kaldılar (Adlara isim vermeyeceğim, ancak Google'ı kullanabileceğinizden eminim).

Regresyon Testleri temel olarak müşterilerinizin ne olmasını beklediğinin bir testidir. Bir regresyon testini kaldırmadan önce birine zarar vermeyeceğinden emin olun (bu neredeyse imkansızdır). Bir hatayı düzeltebilirseniz ve bu regresyon testlerini bozmazsa, gerçek bir düzeltmedir.


Regresyon testi kısmı, uygun test kapsamı seviyesini bildiğinizi varsayarsak doğrudur.
Pemdas

Öte yandan, bir GUI kodlarsanız, daha az bağımlılık vardır; kullanıcılar daha kolay gelişir.
Matthieu M.12

@Matthieu M .: Kesinlikle. Alışkanlıkları değiştirmek (alışkanlıkları düzeltmeye yatırım yaptığınız sürece), otomatik sistemleri (çoğu insan arka odada unutmuş olacak) düzeltmekten daha kolaydır.
Martin York

3

bir hata düzeltmeye karar verirken dikkate alınması gereken bazı şeyler ... hiçbir şekilde her şey dahil.

  • Kritik mi (sistem çöküyor)? ... açıkça bunlar düzeltiliyor
  • Müşteriler sık ​​sık şikayet ediyor mu? Bu, koddaki bir şeyde olduğu gibi bir hata olabilir veya özellik kullanıcı dostu olmadığı gibi bir gereksinim hatası olabilir veya farklı çalışmasını bekler.
  • İş açısından bakıldığında, hatayı düzeltmek veya yeni bir özellik uygulamak daha yararlı mıdır?
  • Hata, önemli ölçüde mimari değişiklikler gerektiriyor mu veya sistemin diğer alt sistemler tarafından büyük ölçüde güvendiği bir parçası mı? Bu test süresini önemli ölçüde etkileyebilir ve hatayı doğrulamak için gerekli test kapsamını zorlaştırabilir mi? Gerçekten eskiyse, kodun buggy bölümünü değiştirerek sistemde başka ne olacağını tam olarak anlamak zor olabilir.
  • Buggy sistemi nedeniyle potansiyel müşterileri mi kaybediyorsunuz?

Potansiyel müşterileri kaybetme konusunda - bu benim için ve hatta satış / pazarlamanın bilmesi zor, ancak tutma oranı yüksekti (anahtarlama maliyeti de yüksek olsa da). A / B testi düzgün yapmadığınız sürece, B yapmanın aksine A yapmanın daha iyi olup olmadığını tartışmayabilirsiniz.
İş

1
Sizin durumunuzda bunun ne kadar geçerli olduğundan emin değilim, ancak sık sık (üçte bir kez) satış mühendislerimizle, satış yapmalarını engelleyen alandaki tartışma konularını görüşmek üzere bir toplantı yapıyoruz. Bu, eksik özellikler içerebilir veya kullanıcı etkileşimi açısından kötü çalışan bir şey olabilir.
Pemdas

3

Hatayı tanımlayın. "Spesifikasyon tarihe göre sıralanmış, ancak işlem tutarına göre sıralanmıştır" kodda bir hata olması gerekmez. Belgelenmemiş bir değişiklik olabilir - bazen, bir yerlerde, birileri sıralama düzeninin değiştirilmesini istedi, ancak spesifikasyonlar, gereksinimler, manuel (hatta kullanıcı arayüzündeki düğmeler ve etiketler) eşleşecek şekilde değiştirilmedi ve kimse aklına gelmedi. Göstermek ve tekrar "tarihe" olarak değiştirmek için kaosa neden olacak ve ui, spec, manuel vb güncellemek için biraz "kırık pencereler teorisi hariç, temelde, zamanınızı boşa harcıyor ."

Bazı şeyler açıkça böcek. Bu düğmeyi tıklatırsanız patlar. Veya Pazartesi günleri bu düğmeyi tıklatırsanız patlar. Birisi size nedenini anlamak için zaman harcamakla görevlendirmedikçe, araştırmak için çok çaba harcayabilirsiniz. Ve nedenini öğrendikten sonra, değiştirememeniz iyi olabilir, çünkü bu kullanıcılar veya yönetim için daha önemli bir şeyi mahveder.

"Sersemlik" görüyorsanız - bellek sızıntıları, sizinkine uymayan bazı optimizasyon, girintileme ve adlandırma kurallarına açıkça ihtiyaç duyan kod - yapacak bir şeyiniz olmadığında veya kendi zamanınızda bunları düzeltmek süper caziptir . Bununla birlikte, bu "düzeltmeler" kaynak kontrolündeki geçmişi çok az veya hiç yarar için berbat, risk felaketleri gibi "asla bu modülü derlemiyoruz çünkü üretimde kullandığımız ikili kod kaybolan koddan inşa edildi ve sadece üzerine yazdınız "ve" hatalarını "düzelttiğiniz" insanları ciddi şekilde üzebilir.

Patronunuzla bire bir görüşmenizi tavsiye ederim. Sizi rahatsız eden şeyleri açıklayın - kodlama stili mi, kullanıcıları rahatsız etmek zorunda olduğunuzdan emin olduğunuz şeyler, yanlış numaralar, tutarsızlıklar veya felaketin gerçekleşmesini bekliyor mu? Sonra yön isteyin ve (bu anahtardır) alın.


2

Eski bir hatayı düzeltmek istiyorsanız, mevcut işlevselliği bozmamaya dikkat etmeniz gerekir. Birim testleri varsa, bu daha kolaydır, ancak şirketin ve yazılımın ima edilen yaşı göz önüne alındığında, bunlar mevcut değildir. Martin Fowler tarafından Refactoring kitabından geçmenizi tavsiye ederim, çünkü yan etkileri en aza indirmeye çalışırken hataları düzgün bir şekilde yeniden düzenleme ve düzeltme. Ayrıca şirket normal zaman boyunca eski hatalar gidiyor sizinle Tamam emin olmanızı tavsiye ederim. Bunu ancak saatten fazla mesai yaparsanız yapmanıza izin verebilirler.

Ayrıca, bir hata bir özellik haline geldiğinde, yani istemciler tarafından bir şey sağladığı için kullanıldıysa, bu davranışı istedikleri zaman için uygun bir yedek sağladığınızdan emin olun (veya yalnızca bir hata yerine bir özellik olarak belgelendirin).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.