Hataları düzeltin veya müşterinin onları bulmasını bekleyin.


35

Diğer insanlar, gördüklerinde hataları düzeltir mi, yoksa düzeltmeden önce ölen / veri kaybı / insanlar ölene kadar bekler mi?

örnek 1

 Customer customer = null;
 ...
 customer.Save();

Kod açıkça yanlıştır ve bunun bir yolu yoktur - boş referansta bir yöntem çağırıyor. Çünkü kaza değil olur Save, herhangi bir oluşum verilere erişemez olur; bu yüzden sadece statik bir fonksiyon çağırmak gibi. Ancak herhangi bir yerdeki küçük değişiklikler aniden çökmeyen kodların çökmesine neden olabilir: çökmeye başlamak.

Ancak , aynı zamanda kodu düzelten de düşünülemez :

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

belki tanıtmak kilitlenme; bunlardan biri eksiksiz kapsama sahip ünite testleri ve manuel kullanıcı testi ile keşfedilmedi.

Örnek 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

Fizik bilerek İnsanlar R olması gerekiyor anlayacaktır 2 paydada.

Kod yanlış, kesinlikle yanlış. Hızın fazla tahmin edilmesi, retro-roketlerin çok yakında ateşlenmesine ve uzay aracının tüm yolcularını öldürmesine neden olacak.

Ancak hızın fazla tahmin edilmesi de başka bir konuyu gizliyor olabilir: mekik çok hızlı hareket ederken hava yastıkları açılmaz. Eğer aniden kodu düzeltirsek:

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

Şimdi hız doğru ve aniden hava yastıkları açılmaması gerektiğinde açılıyor.

Örnek 3

İşte son zamanlarda sahip olduğum bir örnek, bir dizgenin geçersiz karakterler içerip içermediğini kontrol ediyorum:

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

Ya Do somethingdalda bir böcek olduğu ortaya çıkarsa ? Açıkça yanlış kodun düzeltilmesi:

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

Kodu düzeltir, ancak bir hata ortaya çıkarır.


Gördüğüm gibi iki olasılık var:

  • kodu düzeltin ve kırdığınız için suçlayın
  • kodun kilitlenmesini bekleyin ve bir hata olduğundan dolayı suçlanın

Ne yapmak sen siyaseten mi?


Örnek 4 - Bugünün gerçek dünya böceği

Bir nesne yapıyorum ama yanlış kurucu arıyorum:

Customer customer = new Customer();

"Parametresiz" yapıcının, kalıtım zincirinde daha ileride aslında parametreli hale getirilmiş bir yapıcı olduğunu belirtir:

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

Bunu adlandırmak bir hatadır, çünkü sonraki tüm yapıcıları atlar.

Nesnenin soyunu böylesine tehlikeli bir kurucuya maruz bırakmayacak şekilde değiştirebilirdim, ancak şimdi kodu şu şekilde değiştirmem gerekiyor:

Customer customer = new Customer(depends);

Ancak bu değişikliğin hiçbir şeyi bozmayacağını garanti edemiyorum. Benim gibi Örnek 1 inşa yukarıdaki, belki birileri bir yerlerde, bir şekilde, bazı ezoterik koşullarda bağlıdır Customergeçersiz ve önemsiz dolu olması.

Belki de Customer, doğru bir şekilde yapılandırılmış olan nesne, daha önce hiç yapmadığım bir kodun çalışmasına izin verecektir ve şimdi bir çökme olabilir.

Karının hayatı üzerine bahse giremem.

Buradan salıya kadar test edebilirim, kızınızın hayatında bir gerileme yapmadığına yemin edemem.

Yaparım:

  • Kodu düzeltip kırdığınız için suçlanıyor musunuz? veya
  • Böceği bırak ve müşteri bulduğu zaman suçlanmak?

33
Bir şeyi bozabileceği için herhangi bir şeyi değiştirmek istemiyorsanız ve bir şeyleri bozabileceğini ve kodun diğer bölümlerinde neler olabileceğine bakmak için kendinizi vasıfsız buluyorsanız, burada ne yapıyorsunuz? Yazmak üzere olduğunuz kod satırı yanlış olabileceğinden klavyede felç mi ediyorsunuz?
David Thornley

3
kesinlikle iyi araştırılmış bir soru
Muhammad Alkarouri 28:10

2
"Bir Şey Yap" çoğu zaman kodun ünite testine tabi tutulması gereken, yazdığınız veya kütüphanelerden gelen diğer işlevlere yapılan bir çağrıdır. Prosedürün kendisi de çok düşük bir seviyeye düştüğünüzde yeni hataların ortaya çıkma şansı bırakarak ünite testinden geçmiştir ... Bir köprü inşa edersem, köprüden yürüyen insanların ölmesine izin vermek yerine ilk önce daha küçük bir ölçekte test ederdim. . Hatalardan endişe duyduğunuzda birim testleri yapmıyorsanız, yanlış yapıyorsunuz demektir. Hangi durumda tamir ederseniz edin, suçlanırsınız, bu yüzden düzeltmek yerine onu engelleyebilir ve hiçbir şekilde suçlanamazsınız.
Tamara Wijsman

2
'[siz] insanlar düzeltmeden önce ölene kadar bekleyin'! İnek, cidden bunun tek bir cevabı olduğunu umuyorum ...
Chris Knight

3
Özellikle söylediğiniz bir şey hakkında bir yorum olarak: Kodda başka bir yerde olup olmadığını bilmiyorlar, ezoterik davranışa güveniyorlar: öyle mi? Birisi kodunda bir hack olarak açıkça yanlış bir kapsam kuralını kötüye kullanıyorsa, o zaman kod WRONG'dur. İyi OOP bu hatayı önlerdi, ancak sorunu çözmüyorsunuz, sorunu daha da kötüye kullanmaya açık bırakıyor ve sistemi daha dengesiz hale getiriyor. Hatayı düzeltin, umut testi herhangi bir problemi yakalar, daha fazla hatayı düzeltmez. Ürünün uzun vadeli stabilitesi hayati bir metriktir.
CodexArcanum

Yanıtlar:


34

Bu çılgınca duruma, böceğe, müşteriye ve şirkete bağlı. Uygulamanın düzeltilmesi ve potansiyel olarak yeni hataların ortaya konması arasında göz önünde bulundurulması gereken her zaman bir denge vardır.

Ne yapacağımı belirlemek için genel bir kılavuz verirsem, bunun gibi bir şey olacağını düşünüyorum:

  1. Seçtiğiniz takip sistemindeki arızayı kaydedin. Gerekirse yönetim / iş arkadaşlarınızla görüşün.
  2. Potansiyel olarak korkunç sonuçlara neden olan bir kusur ise (örneğin, örnek 2'niz), otorite bildirene kadar koşun, çığlık atın, yukarı ve aşağı zıplayın ve hata düzeltmeyle ilişkili riskleri azaltacak uygun bir eylem planı belirleyin. Bu, çıkış tarihinizi geri alabilir, hayat kurtarabilir, pencerelerinizi yıkayabilir, vb.
  3. Kırılmayan bir kusur veya geçici bir çözüm varsa, onarım riskinin düzeltmenin yararından ağır basıp basmadığını değerlendirin. Bazı durumlarda, müşterinin ortaya çıkmasını beklemek daha iyi olacaktır, çünkü o zaman% 100 gerekli olmadığında işleri düzeltmek / tekrar test etmek için zaman harcamadığınızı biliyorsunuzdur.

Dikkat edin, bu yalnızca bir yayına yakın olduğunuzda geçerlidir. Tam geliştirme modundaysanız, sadece bu hatayı günlüğe kaydederim, böylece izlenebilir, düzeltilebilir ve çağrılabilir. Düzeltmek ve doğrulamak için yarım saatten daha uzun süren bir şey varsa, yöneticiye / ekibin liderine giderim ve kusurun mevcut sürüm döngüsüne uyması gerekip gerekmediğini veya sonraki bir zaman için planlanmış olup olmadığına bakarım.


Çok doğru. Bu yüzden (bazı) şirketlerin teknik yöneticileri, böcek taramaları vb. Var: işleri önceliklendirmek için. Ben inisiyatif alma - hiçbir şekilde - demiyorum ama iyi bir karar vermelisin. Yanlış inisiyatifin yanlış zamanda başlatılması "gevşek bir top olma" olarak adlandırılır ve bir şirketi öldürebilir. Ayrıca, belirli bir hatanın önemi şirketten şirkete değişir. Bazı programlar için, bir iletişim kutusundaki bir yazım hatası, gelecekteki bir sürümde düzeltilmesi gereken düşük öncelikli bir kozmetik hatadır ve diğerlerinde bir stop-stop acil durumudur.
Bob Murphy,

6
Arızayı günlüğe kaydetmek için +1. Diğer kusurlar ... öncelik alabilir
Shug

35

Müşteriler HER ZAMAN hataları bulur . Müşterilerden hiçbir zaman saklanma hatası yoktur. Sonunda ortaya koyduğunuz böcek her zaman size geri dönecektir. Onları tamir etmemek, sadece kötü bir profesyonel uygulamadır. Profesyoneller bunu yapmaz.

Müşteriler hata bulduğunda, şirket kötü görünüyor, bireysel bir geliştirici değil. Bu şirket için çok daha kötü, bu yüzden değişikliği yapmak için durumunuz var. Bu değişikliği diğer hatalara neden olma korkusuyla yapmaktan gerçekten emin değilseniz, daha üst düzey bir geliştirici, proje teknik sorumlusu veya böyle bir değişiklik hakkında karar vermek ve daha sonra sonuçları ele almak için pozisyonda olan başka biriyle konuşun.


2
Bu üzücü bir gerçek. Deliler gibi test ettiğimiz bir proje sunmak zorunda kaldık ve yine de müşteri 3 dakika içinde çökertmeyi başardı.
Oliver Weiler

4
@Helper Yöntemi: Belki aklı başında insanlar gibi test etseydiniz daha iyi olurdu.
Vinko Vrsalovic

@Helper Metodu: Daha ciddiyim, gerçekten de üç dakika olsaydı, bu testler müşteri tarafından beklenen gerçek kullanım durumlarının ne olduğunu bilmiyordu.
Vinko Vrsalovic

8
@Helper Yöntemi: müşteriyi teste dahil etmesini sağlayın (müşteri == müşteri varsayımı). Kod yazma ve test etme geliştiricileri sorunlu geliştiricilerin yazılımı aynı şekilde kullanmamalarıdır. Geliştiriciler naziktir. Bu onların işi - onların sanatı: Müşteriler paniğe kapılmış maymun gibi çarpıyorlar. Mümkün olduğunda, test çalışmasını paylaşın sorumluluğu paylaşın. Bu, her ortama uymuyor, ancak bir ekip olarak müşterilerle çalışmak, danışmanlar daha iyi yazılımlar getiremiyor.
brian chandley,

Daha kötüsü mü? (dolgu)
Merhaba71

24

Hatayı düzeltmek

Biz burada profesyoneliz. Kodda çökmeye veya yanlış davranışa neden olacak başarısız bir yol bulursanız düzeltmeniz gerekir. Ekibinizin prosedürlerine bağlı olarak, muhtemelen bir hata vermeniz, belki de bir regresyon testi yazmanız ve gemi döngüsünün doğru zamanında düzeltmeyi kontrol etmeniz gerekir. Düşük öncelikli bir hata ise, bir dönüm noktasının başlangıcındaki düzeltmeyi kontrol etmek her zaman iyi bir zamandır, çünkü bir gerilemeye neden olursanız, dönüm noktasının bırakma döngüsünü etkilemeyeceksiniz.

Bunu yeniden düzenleme veya performans hatasıyla ilgili olmayan performans iyileştirmeleri yapma ile karıştırmayın.

'Küçük hata düzeltmeleri'nin ayrı bir deposunu tutabileceğiniz ve daha sonra bir dönüm noktasının başında kolayca birleştirebileceğiniz bir dağınık kaynak kontrol sistemi, burada çok yardımcı olur.


4
+1. Düzelt. Düzeltme başka bir şeyi kırarsa, yine de başka bir şeyin kırıldığını - düzeltin. Testiniz bu araları yakalamazsa, testiniz bozulur - bunu da düzeltin. Sen olamaz kendiniz bir şeyler kırma korkusu ile kodu değiştirmeden korkutulma izin - sadece mutlak yıkıma yol açar.
Tom Anderson,

21

Müşteri ne derdi?

İşte bunun nasıl bir oyun olduğunu hayal ediyorum:

Müşteri: x yaptığımda çöküyor.

Programcı: Ah evet! Bunu bir süre önce gördüğümü hatırlıyorum. Henüz önemli bir şey olmadığını düşündüm, o yüzden orada bıraktım.

Müşteri: [künt nesneye ulaşır]

Evet. Hatayı düzelt. Müşteriyi ağırlaştırıcı bir deneyime karşı koruyacak ve acil duruma gelmeden düzeltmek zorunda kalacaksınız.

Düzeltmenizin gerçekten çökmesine neden olabileceğini düşünüyorsanız, henüz bir düzeltme bulamadınız.


8

Verdiğiniz tüm örneklerin ortak bir ipliği olduğu görülüyor. Tam olarak anlamadığınız bir hatayı düzeltmek istiyor gibisiniz. Bunu söylüyorum çünkü her biri için istenmeyen sonuçların ortaya çıkma ihtimalini not ediyorsunuz.

Muhtemelen büyük bir hata olduğunu söyleyebilirim ve Ben Laurie'nin yazdığı gibi anlamadığınız bir hatayı düzeltmiyor . Bu ünlü örnekte Debian ekibi, Debian için OpenSSL şifresini ve bir analiz aracının sonuçlarını takip ederken Ubuntu gibi türevleri şifrelemiştir.

Koda bakarak bir kusur olduğunu düşünüyorsanız, hatayı müşterinin görebileceği şekilde çoğaltabildiğinizden emin olun. Kaynaklarınızı başka bir şeyi düzeltmek için harcamak istemiyorsanız.


7

En kısa zamanda teknik borcunuzdan para almaya başlayın .

Örnekleriniz kesinlikle eski kurallara benziyor , çok fazla teknik borç var ve değişim korkusu olduğunu hissediyorum (BTW, bu bir eleştiri ya da yargı değildir). Tüm ekibiniz, bu teknik borcunuz olduğunu kabul etmelidir (bu nedenle, bunun için tek başına suçlanamazsınız) ve bununla nasıl başa çıkacağınıza karar verebilirsiniz.

Örnek 1'de, Save()hiçbir örnek verisine erişmezse, tam olarak hangi müşteri verilerini kaydeder? Tamir etmeye ve test etmeye başla.

Örnek 2'de, hız hesaplayıcısını testlerle kapatmak ve tüm kilit örneklerde sonucu doğru hesapladığından emin olmak kolaydır.

Örnek 3'te, ölü kodu tekrar hayata döndürme tehlikesi vardır. Bu kod tamamen elimine edilmeli mi? Bunun altındaki boole koşulunun amacı nedir? Dize geçersiz karakterler içerdiğinden emin olmak mı? Veya içinde "PO BOX" olduğundan emin olmak için? Bu tür soruları ne kadar erken ele almaya başlarsanız o kadar iyidir.

Bu gibi birçok sorunu düzelttikten sonra, ekibinizle bir çeşit geçmişe dönük / ölüm sonrası yöntem uygulayın. Gelecekte, kusurlu enjeksiyon oranınızı azaltmak için deneyimlerden ders almak önemlidir.


5

Şimdiden iyi cevapların var. Sadece bir şeyin çökmesinden korkmakla ilgili bir şeyler ekleyeceğim.

İlk olarak, ideal durumda yazılım modülerdir, doğru bir şekilde yapılandırılmıştır ve kaygıların iyi bir şekilde ayrılması söz konusudur. Bu durumda, yaptığınız değişikliklerin, ilgili tüm kodun kontrolünde olacağınız ve hiçbir gizli sürpriz olmadığı için hiçbir şeyi kırma ihtimaliniz çok düşük.

Ne yazık ki, ideal durum kurgusaldır. Bağlantının ne kadar gevşek olduğuna bakılmaksızın, kaplin olacaktır ve bu nedenle başka bir şey kırılma olasılığı ortaya çıkacaktır.

Bunun çözümü iki katıdır:

  1. Kodu mümkün olduğu kadar iyi yapılandırın.
  2. Kod yeterince yalıtıldığında, başka hiçbir şeyin kırılmayacağını bildiğinizden emin olun.

İyi olan yapılandırılmış kod yapma değil , yeni bir mimari tasarım için tüm kodu yeniden yapılır. Aksine, testlerin rehberliğinde yeniden yapılanma burada senin arkadaşın. Bu adımda, işlevselliğini değiştirmezsiniz.

İkinci adım, hatayı düzeltmenizdir.

Birkaç nokta alakalı:

  1. Versiyon Kontrolü bu işlem için kesinlikle gereklidir.
  2. Yeniden düzenleme adımı ve hata düzeltme adımı sürüm kontrolünü ayrı taahhütler olarak daha iyi yerine getirir, bu nedenle her biri iyi tanımlanmış bir tarihsel işlevselliğe sahiptir.
  3. Başka bir hata yapma ihtimalini düzeltmeyin, hiçbir şey yapmazsınız. Aksine, kodunuzu daha iyi hale getirmeyi düşünün. Başka bir deyişle, böcekleri azaltmak yerine böcekleri arttırdığınızı bilmiyorsanız, bunu yapmalısınız.
  4. Son noktayla ilgili: geleceği tahmin etmeye çalışmayın. İnsanlar, tahminlerde çok iyi olduklarını düşünmeye eğilimlidirler. Gerçekte tahmin güçlerimiz kısa vadelidir. Bu yüzden belirsiz bir tanımlanmamış gelecekteki böcek hakkında endişelenmeyin. Bu aynı zamanda YAGNI'nin arkasındaki ilkedir .
  5. Hata dünyasında sürüm kontrolüne karşılık gelen araç hata izcidir . Buna da ihtiyacın olacak.
  6. İki nedenden ötürü hataları düzeltmeniz gerekir: müşteriyi memnun etmek için; ve gelişiminizde ilerleyebilmek için. Örnek 3'ü (fizik olanı) kullanmak için: eğer program müşteriye böylesi kırılmış bir denklemle yeterse, o zaman bu hatayı hafifletmek için yanlış bir şekilde geliştirilmiş yazılımın (örneğin, hava yastığının açılmasını) başka birçok parçası vardır. Bu yazılım için sürüm 2 (veya 1.1) gerekliyse, bu hatalı olanı temel alan doğru kodu geliştirmeyi daha da zor bulacaksınız. Öyleyse ya büyük yeniden yazıya, ya da büyük başarısızlığa doğru gidiyorsun. İkisinden de kaçınmanız gerekir.

Bunlar zaten birkaç noktadan fazla, bu yüzden burada duracağım.


3

İlk önce bir hatanın tanımını düşünmelisiniz:

  1. Okunan kod, doğru olduğunu düşündüğünüzle eşleşmiyor
  2. Yazılım görevlerini uygun şekilde yerine getirmiyor

# 1'e odaklanıyor görünüyorsunuz, burada # 2 oturmak için en iyi yer. Tabii, biz programcılar bizim kod olmak istiyorum sağ (# 1), ama insanlar için bunun için bize ödeme çalışmaları (# 2).

Yanlışlıkla yeni hatalar çıkarabilecek kod tabanına yapabilecekleriniz veya yapamadıklarınız, # 2'nin mevcut yazılımı görmesiyle ilgili değildir. Ancak, 1 numara kendiniz veya izleyen bakım programcısı için önemlidir. Karar vermek bazen zor olabilir, ancak # 2 ve # 1 çatışma çıktığında, # 2'nin açıkça daha önemli olduğunu bilmeniz gerekir.


2

Ne. Üçüncü bir yol var: “sorunlu kod” un aslında iş açısından soruna yol açtığını kanıtlamanın bir yolunu bulmak. BA / QA ile ne bulduğunuzu veya en azından yöneticinizi onaylayın. Ardından, herkes sorunun farkında olduğunda düzeltmeyi planlayın.

Bahsettiğiniz durumlarda geçerli bir hata dışında daha olası senaryolar vardır:

  1. Bakmakta olduğunuz kod ölü koddur. Muhtemelen Ysolik’in dediği gibi: Müşteriler daima hatalar bulur. Olmazlarsa, belki kod asla çalıştırılmaz.
  2. Bariz hatanın amacına sahip olduğu bir WTF durumu vardı. (Üretim kodundan bahsediyoruz, herhangi bir şey olabilirdi, değil mi?)
  3. İş dünyası / müşteriler sorunu zaten biliyorlardı, ancak düzeltmenin gereğini hissetmiyorlar.
  4. Belki daha fazla...

Yukarıdaki herhangi bir durumda, eğer bir yöneticiysem, bir geliştiricinin kararını kullanmasını ve "hatayı" yerinde düzeltmesini istemiyorum. Hatayı düzeltmek çoğu zaman yardımcı olabilir, ancak yanlış gittiğinde, iyi niyetinden daha fazla soruna neden olabilir.


1
Sadece kendi yargılarını kullanmayan geliştiricileri işe almak istiyorsan, orada senin için gerçekten vasat olanlar var. Yeteneklerine güven duyan gerçek iyi olanları işe almakta zorlanacaksın.
David Thornley

1
@Did: Düşüncemi uygunsuz bir dereceye kadar uzatma. Geliştiriciler kesinlikle yargılarına ihtiyaç duyarlar, ancak bir sınır olmalıdır. Bu durumda, geliştiriciler olası bir hatayı tespit etmek için yargılarını kullanır ve bunu gidermek için daha fazla adım atarlar.
Codism

2

Yaparım mı:

  • kodu düzeltip kırdığınız için suçlanıyor musunuz? veya
  • Böceği bırak ve müşteri bulduğu zaman suçlanıyor mu?

Hatayı düzeltiyorsunuz, ünite testlerini başlatıyorsunuz ve başarılı olduklarında düzeltmenizi kontrol ediyorsunuz.

(Birim testleriniz gerçekten uzun sürerse, önce düzeltmenizi kontrol edin ve ardından CI aracınızın size bir posta gönderip göndermeyeceğini bekleyin, çünkü işleminiz bir şey bozdu.)


1
Veya eğer girişli bir giriş kullanıyorsanız, onu ayarlayın, böylece gerçekten bozuk kodları girmezsiniz.
Adam Lear

3
Uzun zaman almak ayakkabılı kod işlemek için mazeret değildir.
Toby

@ Toby: Kim bahaneler hakkında konuşuyordu? Şu anda küçük bir takımda çalışıyorum, yarım düzine geliştiriciye bile. Proje için birim testleri 1 saat sürer. Bizim politikamız testleri çalıştırmaktır görünüyor ne yaparsanız ilgili ve sonra kontrol edip görünüşte ilgisiz bir şey kırdı olmadığını CI öğrenelim. Bu büyük bir takımda işe yaramaz, ancak küçük bir takımda çok zaman kazandırır.
sbi

1

Çökme / veri kaybı hataları varsa bunları düzeltin. Bilinen veri kaybı hatası olan bir programın gönderilmesi düpedüz zararlı ve affedilmezdir.

Eğer böcek kozmetik veya kritik değilse (önlenebilir), belgelendirilmeli ve bir geçici çözüm sağlanmalıdır. İdeal olarak sabitlenmesi gerekir, ancak bazen mevcut sürüm için düzeltmek çok pahalıdır.

Her büyük yazılım projesinin, ReadMe'de genellikle tam olarak aşağıdakileri listeleyen bir 'Bilinen Sorunlar' bölümüne sahip olduğuna dikkat edin: Bilinen hatalar.

Bugs'u tanımak ve onları iletmemek, IMHO'dur, ancak gerçekten küçük / kozmetik hatalar için kabul edilebilir.


1

Düzelt ve test et. Bilinen böcekleri sadece daha fazla böcek bulmaktan korktuğunuz için tutmaya karar verirseniz, programınız o kadar hızlı bir şekilde hareket eden bombaları tıkayan bir mayın tarlası haline gelir:

Siz usta olduğunuzdan ve kod altınız olduğundan, yanlış olduğunu gördüğünüzde değiştirmekten korkmayabilirsiniz. Koddan korkma ("başka bir yere çökerek misilleme yapabilir") kabul edilemez.


0

Açıkça bir kırıcı veya yanlış bir şey varsa, düzeltmeniz gerekir. Spec bir belirsizlik, yani kendinizi "iyi müşteri düşünme bulursanız varsa olabilir beklerdim, ama sanki o görünüyor olabilir gibi bir hata olması" veya spec sorunun "Biz bunu yapmak istendi ama berbat bir şey "o zaman ne yapacağını bulman gerek. Kodu duvardan atmak ve müşteri geri bildirimlerini beklemek kötüdür - varsa bir ürün yöneticisine sorabilir veya ürünü dağıtmadan önce müşteriye sorabilirsiniz.

Unutmayın, "bu sorunu biliyoruz ve gelecekteki bir sürümde düzelteceğiz", "bu sorunu biliyoruz, ancak bununla başa çıkmanızı önlemek için yeterince umursamıyorum" ile eş anlamlıdır.


0

Doğru eylem şekli ne böceği yok saymamak, ne de yerinde “düzeltmek”; Sorunuzda tanımladığınız nedenlerden dolayı.

Bence önce kodu anlamaya çalışmalısın. Gördüğünüz kodun biraz yaşı varsa ve kimse henüz "bug" ı farketmediyse, bunun bir nedeni olabilir. Bu nedeni bulmaya çalışın. Bir karar vermeden önce bakmak istediğim şey:

  • Geçmiş : Soruları cevaplamak için sürüm kontrol yazılımınızı kullanın: Koda kim dokundu? Ne değişti? Ve hangi taahhüt mesajlarıyla kontrol ettiler? Kodun göründüğü gibi bir sebep bulabilir misiniz?

  • Kullanın : Hangi kod hatalı kodu kullanıyor? Ve nasıl? Kod öldü mü? Hatalı davranışa dayanan başka bir kod var mı?

  • Yazar : Yukarıdaki bilgileri kullanarak hızlıca bir sonuca varamazsanız, kodun yazarına (en azından mümkünse) neden kodun göründüğü gibi göründüğünü sorun. Genellikle bir "Oups, düzeltilmesi gereken!" ya da "Hayır! Değiştirmeyin !!! Bu şekilde gerekli!" derhal.

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.