Her arızayı teşhis etmeden ve tamir etmeden önce üremek konusunda ısrar etmek mantıklı mıdır?

Bir yazılım ürün şirketinde çalışıyorum. Ürünümüzü uygulayan büyük kurumsal müşterilerimiz var ve onlara destek sağlıyoruz. Örneğin, bir kusur varsa, yamalar vs. sunarız. Başka bir deyişle, oldukça tipik bir kurulumdur.

Son zamanlarda, bir müşterinin, kümelenmiş bir ürün uygulamasında eşzamanlı veritabanı erişimi ile ilgili olması gereken bir günlük dosyasında bulunan bir istisna hakkında bana bir bilet verildi. Bu nedenle, bu müşterinin özel yapılandırması bu hatanın ortaya çıkması için kritik öneme sahip olabilir. Müşteriden gelen tek şey onların günlük dosyasıydı.

Ekibime önerdiğim yaklaşım, hatayı müşterininkine benzer bir konfigürasyon kurulumunda yeniden üretmeye çalışmak ve karşılaştırılabilir bir kayıt tutmaktı. Bununla birlikte, yaklaşımı aşırı derecede zaman alıcı olduğu için hatayı çoğaltmaya ihtiyacım olmadığı ve VM'lerde bir sunucu kümesinin simüle edilmesini gerektireceğimi söylemediğime katılıyorlar. Ekibim, iş parçacığı ve / veya güvenli olmayan kodun nerede olduğunu görmek için basitçe "kodu takip etmemi" önerdi ve meydana geldiği çevre gibi bir küme uygulaması olmayan basit bir yerel gelişimden etkilenen değişikliği uyguladı. hatanın kaynağı.

Bana göre, somut, görünür bir tezahürden ziyade soyut bir plandan (program kodu) çalışmak zor görünüyor, bu yüzden genel bir soru sormak istedim:

Teşhis etmeden ve tamir etmeden önce her kusuru yeniden üretmek ve hata ayıklamakta ısrar etmek mantıklı mıdır?

Veya:

Kıdemli bir geliştiriciysem, çok iş parçacıklı kod okuyabilir ve uygulamanın çalıştırılması, farklı kullanım senaryosu senaryolarının test edilmesi ve uygulama aşamasına geçilmesi yerine tüm kullanım senaryolarında ne yaptığına dair zihinsel bir resim oluşturmalı mıyım? kod satır satır? Yoksa bu tür bir çalışma ortamı talep ettiğim için fakir bir geliştirici miyim?

Sissies için hata ayıklama mı?

Kanımca, olay biletine cevaben yapılan herhangi bir düzeltme, orijinal ortama mümkün olduğunca yakın olacak şekilde simüle edilmiş bir ortamda test edilmelidir. Sorunu gerçekten çözeceğini başka nasıl bilebilirsin? Hava yastıklarının gerçekten işe yaradığını göstermek için kuklalarla test etmeden çarpışma yapmadan yeni bir araç modeli çıkarmak gibi.

Son fakat en az değil, eğer bana katılıyorsanız:

Yaklaşımımın makul, muhafazakar ve kurşun geçirmez olduğuna inandırmak için ekibimle nasıl konuşmalıyım?

Teşhis etmeden ve tamir etmeden önce her kusuru yeniden üretmek ve hata ayıklamakta ısrar etmek mantıklı mıdır?

En iyi çabanı göstermelisin. Bazen tam olarak çoğaltılamayacakları kadar karmaşık olan koşullar ve ortamlar olduğunu biliyorum , ancak yapabilirseniz kesinlikle denemelisiniz.

Eğer hatayı hiç çoğaltmamış ve kendiniz görmemişseniz, gerçekten düzelttiğinizden nasıl% 100 emin olabilirsiniz? Belki de önerilen düzeltmeniz , asıl kusuru yeniden oluşturmaya çalışmadığınız sürece tezahür etmeyecek başka ince hatalar ortaya koyuyor .

Üst düzey bir geliştiriciysem, (okuyuculu) kodu okuyabilir ve uygulamayı çalıştırmak, farklı kullanım senaryolarını uygulamak için test etmek yerine, tüm kullanım senaryolarında ne yaptığına dair zihinsel bir resim oluşturabilir miyim? kod satır satır mı? Yoksa bu tür bir çalışma ortamı talep ettiğim için fakir bir geliştirici miyim? Sissies için hata ayıklama mı?

Tek yaklaşımları buysa, "kafasında" kodunu çalıştıran birine güvenmezdim . Başlamak için iyi bir yer . Hatayı çoğaltmak, düzeltmek ve daha sonra çözümün hatanın tekrar ortaya çıkmasını engellediğini göstermek - bitmesi gereken yer .

Yaklaşımımın makul, muhafazakar ve kurşun geçirmez olduğuna inandırmak için ekibimle nasıl konuşmalıyım?

Çünkü, hatayı hiç çoğaltmazlarsa, bunun düzeltildiğinden emin olamazlar. Müşteri geri gelir ve hatanın hala orada olduğundan şikayet ederse, bu İyi Bir Şey değildir . Sonuçta, bu problemle başa çıkabilmeniz için size büyük $$$ (varsayıyorum) ödüyorlar.

Eğer varsa başarısız düzgün sorunu çözmek için, siz (bir dereceye kadar) müşteri ile kırık inanç ettik ve pazarda yarışmacı olduğunda, bunlar müşteri kalmayabilir.

Söz konusu hatanın giderildiğini nasıl doğrulamak istiyorlar? Test edilmemiş kodu kullanıcıya göndermek ve çözmelerine izin vermek mi istiyorlar? Hatayı yeniden üretemediği hiçbir test kurulumunda, hatanın bulunmadığı gösterilemez. Kesinlikle tüm istemci ortamını yeniden oluşturmanıza gerek yok, ancak hatayı yeniden oluşturacak kadar ihtiyacınız var.

Düzeltmeden önce her böceğin yeniden üretilmeye çalışılmasının makul olmadığını düşünüyorum. Ancak, onu yeniden üretmeye çalışırsanız ve yapamazsanız, o zaman daha fazla kör yamanın iyi bir fikir olup olmadığına dair bir iş kararı olur.

İdeal olarak, her hatayı çoğaltabilmek istersiniz, böylece en azından bunun giderildiğini test edebilirsiniz.

Ama ... Bu her zaman mümkün olmayabilir ya da fiziksel olarak mümkün olmayabilir. Özellikle her kurulumun benzersiz olduğu 'işletme' tipi yazılımlarla. Maliyet / fayda değerlendirmesi de var. Kritik olmayan bir sorun hakkında kod üzerinden bakmak ve birkaç eğitimli tahmin yapmak birkaç saat süren, teknik destek ekibinin bir müşterinin ortamını tam olarak kopyalayabilmek umuduyla kurmaya ve çoğaltmaya çalışmakla haftalar geçirmesinden çok daha ucuz olabilir. sorun. 'Enterprise' dünyasında çalıştığımda, genellikle kodlayıcıları uçurup sahadaki hataları düzeltmelerini istiyorduk, çünkü müşterinin kurulumunu çoğaltmanın bir yolu yoktu.

Bu yüzden, ne zaman yapabilirseniz çoğaltın, ancak yapamazsanız, sistem hakkındaki bilgilerinizi kullanın ve suçluyu kodda tanımlamaya çalışın.

Hatayı çoğaltarak hataya bakmak için bir gereklilik olduğunu düşünmüyorum. Bahsettiğiniz gibi, sorunu ayıklamanın birkaç yolu var - ve hepsini kullanmalısınız. Size bir günlük dosyası verebildikleri için kendinizi şanslı saymalısınız! Siz veya şirketinizdeki biri hatayı çoğaltabiliyorsa, harika! Değilse, günlükleri hala ayrıştırmaya ve hatanın oluştuğu koşulları bulmaya çalışmalısınız. Meslektaşlarınızın önerdiği gibi, kodu okumak, hatanın hangi koşulların olabileceğini bulmak ve ardından senaryoyu kendiniz yeniden yaratmaya çalışmak mümkün olabilir.

Ancak, test edilmemiş gerçek düzeltmeyi bırakmayın. Yaptığınız herhangi bir değişiklik standart dev, QA testi ve entegrasyon testi rutininden geçmelidir. Test edilmesi zor olabilir - çok hata ayıklaması zor olan okuyuculu koddan bahsettiniz. Burası bir test yapılandırması veya ortamı yaratma yaklaşımınıza katılıyorum. Kodda bir sorun bulduysanız, ortamı oluşturmayı, sorunu yeniden oluşturmayı ve düzeltmeyi test etmeyi çok daha kolay bulmalısınız.

Bana göre bu, daha az hata ayıklama sorunu ve daha fazla müşteri hizmetleri sorunudur. Bir müşteriden bir hata raporu aldınız; konusunu bulmak ve çözmek için gereken özeni gösterme sorumluluğunuz vardır.

Benim düşünceme göre ... karar verici olarak konumunuzu haklı gösterebilmelisiniz. 3. hat destek departmanının amacı, müşteriden kabul edilebilir bir çabayla hataları en kısa sürede düzeltmekse, herhangi bir yaklaşım bu hedefe uymalıdır. Ayrıca, yaklaşımın beklenen en hızlı sonuçları verdiği kanıtlanmışsa, ekibi ikna etmek için bir sorun olmamalıdır.

Destek konusunda çalıştıktan sonra, müşteriden hatayı sürekli olarak yeniden üretmek için gerçekleştirdikleri bazı "senaryoları" ve hatayı tutarlı bir şekilde yapmazsa, hatayı üreten aday örnekleri vermesini her zaman makul bir şekilde beklerdim.

Eğer sistemde yeniydim ve kodla ilgili bir arka planım olmasaydı, ilk adımlarım hatanın muhtemel kaynaklarını belirlemeye çalışmaktı. Bir aday kodunu belirlemek için günlük kaydı yetersiz olabilir. Müşteriye bağlı olarak, rahatsız edici kodun konumu ile ilgili daha fazla ipucu veren günlük dosyalarını geri alabilmeleri için bir hata ayıklama sürümü vermeye meyilli olabilirim.

Kod bloğunu hızlı bir şekilde tanımlayabilirsem, akışın görsel eşlemesi kodu bulmak için yeterli olabilir. Değilse, birim test tabanlı simülasyon yeterli olabilir. İstemci çoğaltma ortamı oluşturmak, özellikle de sorunun büyük oranda tekrarlanabilirliği varsa daha az zaman alabilir.

Yaklaşımınızın önerilen çözümlerin bir birleşimi olması gerektiğini ve birinden ne zaman çıkıp bittiğini bilmek işin verimli bir şekilde yapılmasının anahtarı olduğunu düşünüyorum.

Ekibin, çözümünün hatayı daha hızlı bulma şansı varsa, onlara hatayı düzeltmek için gereken süreyi çok fazla etkilemeyeceğini ispatlamak için uygun bir zaman dilimi verme fikrini destekleyeceğinden eminim. Gittiğiniz rota.

Teşhis etmeden ve tamir etmeden önce her kusuru yeniden üretmek ve hata ayıklamakta ısrar etmek mantıklı mıdır?

Evet, bazı uyarılarla söylüyorum.

• Bence kodu okuyup problemli olabilecek yerler bulmaya çalışmalısın. Bir yama oluşturun ve sorunu çözüp çözmediğini görmek için bunu müşteriye gönderin. Bu yaklaşım başarısızlığa devam ederse, diğer seçenekleri araştırmanız gerekebilir. Sadece adresleme olabilir iken hatırlıyorum bir hata değil olabileceğini bildirildi böcek.
• Gerekçeli olarak çoğaltamazsanız ve kodda kırmızı bayrak bulamazsanız, müşteriyle daha yakın bir koordinasyon gerektirebilir. Sitede hata ayıklama yapmadan önce müşteri sitelerine uçtum. Bu en iyi dev ortamı değil, ama bazen sorun çevresel ise, kesin nedeni bulmak, tutarlı bir şekilde yeniden üretebileceğiniz zaman en kolay olacaktır.

Bu senaryoda masanın müşteri tarafındayım. İnanılmaz derecede büyük bir Oracle veritabanı kümesi kullanan bir ABD hükümet ofisinde çalışıyordum (birkaç terabayt veri ve günde milyonlarca kayıt işliyor).

Yeniden üretmemiz çok kolay olan garip bir problemle karşılaştık. Hatayı Oracle'a bildirdik ve haftalarca onlarla ileri geri gittik ve günlüklerini gönderdik. Sorunu çözemediklerini söylediler, ancak bize soruna cevap vermesi umuduyla ilgili birkaç düzeltme eki gönderdiler. Hiçbiri yapmadı.

Sonunda konuyla ilgili hata ayıklamak için birkaç geliştiriciyi yerimize getirdiler. Ve bu, hatanın kök sebebi bulunduğunda ve daha sonra bir yamanın sorunu doğru şekilde çözmesiydi.

Sorun hakkında olumlu değilseniz, çözüm konusunda olumlu olamayacaksınız. En az bir test durumu durumunda sorunun nasıl güvenilir bir şekilde yeniden üretilebileceğini bilmek, hatanın nedenini bildiğinizi kanıtlamanıza olanak sağlar ve bu nedenle, daha sonraki eksikliklerden dolayı sorunun tersine çevrildiğini kanıtlamanıza da olanak sağlar düzeltmeyi uyguladıktan sonra aynı test durumunda hata.

Bununla birlikte, yarış koşulları, eşzamanlılık sorunları ve diğer "deterministik olmayan" hatalar, bir geliştiricinin bu şekilde saptaması en zor olanlar arasındadır, çünkü nadiren, herhangi bir geliştiricinin kopyasından daha fazla yük ve karmaşıklığı olan bir sistemde meydana gelirler. program ve görev daha sonra aynı sistemde yeniden çalıştırıldığında kaybolurlar.

Çoğunlukla, rastgele bir hataya benzeyen şey, bittikten sonra, hatanın nasıl olduğunu bildikten sonra deterministik olarak yeniden üretilebilir olmasına neden olan deterministik bir nedene sahip olur. Buna meydan okuyanlar, gerçek Heisenbugs (steril, izlenen bir ortamda onlar için test etmeye çalışırken kaybolmuş görünen rastgele böcekler)% 99.9 zamanlama ile ilişkilidir ve bir kez anladığınızda, ileriye dönük yolunuz daha netleşir; Başka bir şey, kodun yürütülmesi sırasında edgewise olarak bir kelime alacaksa ve böyle bir güvenlik açığı bulduğunuzda, çoğaltmaya çalıştığınız davranışı gösterip göstermediğini görmek için sınamada yararlanmaya çalışın.

Bu durumlarda tipik olarak önemli miktarda derinlemesine kod incelemesi yapılır; Kodlara bakmak, kodun nasıl davranması gerektiğine dair önyargılı fikirlerden vazgeçmeniz ve müşterinizin gözlemleyeceği şekilde başarısız olabileceği senaryoları hayal etmeniz gerekir. Her senaryo için, mevcut otomatik test ortamınızda (yani sadece bir test için yeni bir VM yığına ihtiyaç duymadan) verimli bir şekilde çalıştırılabilecek bir test geliştirmeye çalışın, kodun beklediğiniz gibi davrandığını kanıtlar veya ispatlar ( Beklediğinize bağlı olarak, bu kodun müşterilerin sorunlarının olası bir nedeni olduğunu kanıtlar veya ispatlar). Yazılım mühendisleri için bilimsel yöntem budur; gözlemleyin, hipotezleyin, test edin, yansıtın, tekrarlayın.

Teşhis etmeden ve tamir etmeden önce her kusuru yeniden üretmek ve hata ayıklamakta ısrar etmek mantıklı mıdır?

Hayır, kesinlikle değil. Bu aptalca bir politika olurdu.

Sorunuz ve önerinizle ilgili gördüğüm sorun, onların arasında bir ayrım yapamamasıdır.

• hata raporları
• başarısızlıklar ( hatalar )
• hatalar (bazen hatalar da denir )

Bir hata raporu , bir hatayla ilgili iletişimdir. Birinin bir şeylerin yanlış olduğunu düşündüğünü söylüyor. Neyin yanlış olması gerektiği konusunda belirli olabilir veya olmayabilir.

Bir hata raporu, bir başarısızlığın kanıtıdır.

Bir başarısızlık yanlış giden bir olaydır. Özel bir arıza, ancak neye sebep olmuş olabileceği konusunda herhangi bir ipucu ile olması gerekmez.

Bir hata, bir hatadan kaynaklanıyor olabilir.

Bir hata , başarısızlıkların bir nedenidir; İleride meydana gelebilecek arızaları önlemek için (ilke olarak) değiştirilebilecek bir şey.

Bazen bir hata bildirildiğinde, neden hemen açıktır. Böyle bir durumda, böceğin çoğaltılması saçma olur. Diğer zamanlarda, neden hiç net değil: hata raporu belirli bir başarısızlığı tanımlamıyor ya da açıklıyor ancak başarısızlık, sebebin ne olabileceğine dair bir ipucu sağlamayacak şekildedir. Bu gibi durumlarda, tavsiyenizin haklı olduğunu düşünüyorum - ancak her zaman değil: birincisinin çökmesine neden olanı (kontrol yazılımındaki belirli bir hata) araştırmayı kabul etmeden önce, kişi 370 milyon dolarlık bir uzay roketini düşürmekte ısrar etmiyor .

Ve ayrıca aralarında her türlü dava var; örneğin, eğer bir hata raporu kanıtlamazsa, ancak yalnızca, önceden bildiğiniz bir sorunun bir rol oynayabileceğini kanıtlarsa, bu daha yakından bakmanız için yeterli bir teşvik olabilir.

Bu nedenle, zorlu durumlar için tekrarlanabilirlik konusunda ısrarcı olmak akıllıca olurken, katı bir politika olarak uygulamak zor olabilir.

Yazılım geliştirmedeki her şeyde olduğu gibi, doğru cevap bir uzlaşmadır.

Teoride, var olduğunu kanıtlayamazsanız, hiçbir hatayı gidermeye çalışmamalısınız. Bunu yapmak, kodunuzda nihayetinde hiçbir şeyi çözmeyen gereksiz değişiklikleri yapmanıza neden olabilir. Ve kanıtlamak, önce onu yeniden üretmek, daha sonra bir düzeltme oluşturmak ve uygulamak, ardından artık gerçekleşmeyeceğini göstermek anlamına gelir. Buradaki bağırsaklarınız sizi doğru yöne yönlendiriyor - müşterinizin problemini çözdüğünüzden emin olmak istiyorsanız, en başta neyin sebep olduğunu bilmeniz gerekiyor.

Uygulamada, bu her zaman mümkün değildir. Belki de hata, kodunuza aynı anda erişen düzinelerce kullanıcısı olan büyük kümelerde ortaya çıkar. Belki de hatayı tetikleyen belirli veri setleri üzerinde belirli bir veri işlemi birleşimi vardır ve bunun ne olduğu hakkında hiçbir fikriniz yoktur. Belki de müşteriniz programı, böcek ortaya çıkmadan önce 100 saat boyunca etkileşimli olarak kesintisiz olarak çalıştırdı.

Bu gibi durumlarda, işe başlamadan önce departmanınızın hatayı yeniden üretmek için zamana veya paraya sahip olmama ihtimali çok yüksektir. Çoğu durumda, geliştirici, kodda sizi doğru duruma yönlendiren bir hata olduğu konusunda çok daha belirgindir . Sorunu teşhis ettikten sonra geri dönüp yeniden oluşturabilirsiniz. Bu ideal değildir, ancak aynı zamanda, kıdemli geliştirici olarak işinizin bir kısmı, kodun nasıl okunacağını ve yorumlanacağını, kısmen de bu tür gömülü böceklerin yerini bulmaktır.

Bence, sorunun yanlış kısmına odaklanıyorsunuz. Sonunda söz konusu hatayı çoğaltamazsanız ne olur ? Hiçbir şey bir müşteriye duymaktan daha sinir bozucu olamaz "evet, programı düştüğünüzü biliyoruz, ancak çoğaltamıyoruz, bu yüzden bu bir hata değil." Müşteriniz bunu duyduğunda, “yazılımımızın hatalı olduğunu biliyoruz, ancak hataları düzeltmek ve düzeltmek için uğraşamayız, bu yüzden sadece parmaklarınızı çarpın” olarak yorumladılar. Bildirilen bir hatayı "tekrarlanamaz" olarak kapatmak ya da "tekrarlanamaz olmak, ancak kararlılığı artırmaya çalışmak için bazı makul değişiklikler yaptık" olarak kapatmak daha mı iyi?

Hata belirgin, açık ve önemsiz değilse, çok özel bir hata mesajı, vb. İle, kullanıcı veya bakıcı bunu çoğaltamazsa bir hatayı düzeltmek genellikle çok zordur.

Ayrıca, adımları çoğaltamazsanız, hatanın düzeltildiğini onlara nasıl kanıtlarsınız?

Davanızla ilgili sorun, kullanıcının hatanın nasıl oluştuğunu, yani hangi işlemi yapmanın hangi ekranında olduğunu bilmemesidir. Sadece günlükleri var.

Bence amacın makul. Eğer psişik güçlerin olsaydı, muhtemelen maaş için çalışmayacaktın.

Bunu o alacaktı hatayı çoğaltmak mümkün olmadan patronlarınıza söylemeliyiz bir zaman _uknown miktarda dışarı bulmak için ve orada hiç yok garantee olacak.

Bazı meslektaşlarınız, hatayı tamamen şanssız bulup düzelttiklerinde sorun ortaya çıkacak .

En uç noktaya gidelim ve hatayı çok daha önce bulduğunuzu varsayalım: kodunuzda, yazarken. Öyleyse tam orada düzeltme konusunda herhangi bir vasıfınız olmazdı - az önce yazdığınız kodda bir mantık hatası görüyorsunuz, yapmak istediğinizi yapmıyor. Bunun bir hata olduğunu göstermek için bütün ortamı kurmaya ihtiyaç duymazsın.

Şimdi bir hata raporu geliyor. Yapabileceğiniz birkaç şey var. Bunlardan biri koda geri dönüp tekrar okumak. Şimdi, bu ikinci okumada, koddaki hatayı hemen bulduğunuzu varsayalım - basitçe yapmayı düşündüğünüz şeyi yapmaz ve yazdığınızda bunu farketmediniz. Ve bu, yeni gelen hatayı mükemmel bir şekilde açıklıyor! Düzeltmeyi sen yaptın. Yirmi dakika sürdü.

Bu hata raporuna neden olan hatayı düzeltti mi? % 100 emin olamazsınız ( aynı şeye neden olan iki böcek olabilir ), ancak büyük olasılıkla yaptı.

Yapabileceğiniz başka bir şey de müşterinizin yapılandırmasını olabildiğince çoğaltmak (birkaç günlük çalışma) ve sonunda hatayı yeniden oluşturmaktır. Çoğu durumda, hatayı çoğaltamayacağınız anlamına gelen zamanlama ve eşzamanlılık sorunları vardır, ancak çok fazla zaman deneyebilir ve bazen aynı şeyin olduğunu görebilirsiniz. Şimdi hata ayıklamaya başlarsınız, koddaki hatayı bulun, çevreye koyun ve tekrar tekrar deneyin. Artık oluşan hatayı görmüyorsunuz.

Bu hata raporuna neden olan hatayı düzeltti mi? Hala% 100 emin olamazsınız - bir, aslında müşterinin yaptığı tamamen farklı bir hata görmüş olabilirsiniz, iki, belki de yeterince sık denemediniz ve üç, belki de konfigürasyon hala biraz farklı ve Bu sistemde düzeltildi, ancak müşterinin değil.

Bu yüzden kesinliği elde etmek imkansızdır. Ama ilk yöntem yolu daha hızlı (hızlı çok müşteriye bir yama verebilir) 'dir, daha ucuz bir yoldur ve eğer sen belirti açıklar net bir kodlama hatasına rastlar da sorunu bulmaya aslında daha olasıdır.

Bu yüzden değişir. Bir test ortamı kurmak daha ucuzsa (veya daha iyisi: sorunu gösteren otomatik bir test), o zaman bunu yapın. Fakat eğer pahalıysa ve / veya hatanın gösterdiği koşullar tahmin edilemez ise, ilk önce kodu okuyarak hatayı bulmaya çalışmak her zaman daha iyidir.

Soruyu okurken pozisyonunuz ve ekibiniz arasında temel bir karşıtlık görmüyorum.

• Evet, müşteri ortamında meydana gelen sorunu yeniden üretmek için elinizden geleni yapmalısınız. Ancak en iyi çaba, bunun için bir zaman kutusu tanımlamanız gerektiği anlamına gelir ve günlükte sorunu gerçekten yeniden oluşturmak için yeterli veri olmayabilir.

  Eğer öyleyse, hepsi bu müşteri ile olan ilişkiye bağlıdır. Sizden ondan başka hiçbir şey almayacaksınız, teşhis araçları ve arızalı sistemde çalıştırma yeteneği olan bir geliştirici gönderebilirsiniz. Genellikle aramızda bir yerdeyiz ve eğer ilk veriler yeterli değilse, daha fazlasını elde etmenin yolları var.

• Evet, kıdemli bir geliştirici kodu okuyabilmelidir ve günlük içeriğini takip eden sorunun nedenini bulması muhtemeldir. Gerçekten de, kodu dikkatlice okuduktan sonra problemi gösteren bir birim testi yazmak çoğu zaman mümkündür.

  Bu tür ünite testlerini yazmaya devam etmek, kırılan işlevsel ortamı yeniden üretmek kadar iyidir. Tabii ki, bu yöntem bir şey bulacağınızın garantisi değildir. Bazı çok iş parçacıklı yazılımlarda başarısızlığa yol açan olayların tam sırasını anlamak, yalnızca kodu okuyarak bulmak gerçekten zor olabilir ve canlı hata ayıklama yeteneğinin kritik hale gelmesi olasıdır.

Özetle, her iki yaklaşımı da eşzamanlı olarak deneyeceğim ve problemi gösteren (ve sonrasında çözüldüğünü gösteren) canlı bir sistem ya da problemi kıran bazı kırma ünitelerinin test edilmesini isteyeceğim (ve düzeltmeden sonra da düzeltildiğini göstereceğim).

Kodu düzeltip vahşi doğada göndermeye çalışmak gerçekten çok riskli görünüyor. Başıma gelen benzer bazı durumlarda (kusurun içsel olarak yeniden üretilemediği durumlarda), bir düzeltme çılgınca gerçekleştiyse ve müşteri sorununu çözemediğinde ya da beklenmedik olumsuz sonuçlar doğurduysa, öneren adamı asıl sorunu bulması için destek ekibine yardım etmek zorunda kalacaktı. Gerekirse müşteriyle ilgilenmek de dahil olmak üzere.

Kulağa daha ayrıntılı bir kayıt yaptırmanız gerekiyor gibi geliyor.

Daha fazla günlüğe kaydetme eklemek hata ayıklamanıza gerek kalmayacağınızı (veya bu durumda, durumu yeniden oluşturacağınızı) garanti edemezken, gerçekte neyin yanlış gittiği konusunda size daha iyi bir fikir verecektir.

Özellikle karmaşık / zorlayıcı durumlarda veya bir hata ayıklayıcıyı kullanamayacağınız herhangi bir durumda, "printf () tarafından hata ayıklama" ya geri dönmeniz tek başvurunuz olabilir. Bu durumda, (ihtiyaç duyduğunuzdan daha fazlasını beklediğiniz kadar) giriş yapın ve buğdayı samandan süzmek için iyi araçlara sahip olun.

Teşhis etmeden ve tamir etmeden önce her kusuru yeniden üretmek ve hata ayıklamakta ısrar etmek mantıklı mıdır?

Kimse henüz net bir şekilde söylemediği için: Kesinlikle hayır!

Yazılım geliştirmedeki her şey gibi, hata düzeltme işlemi zaman, risk ve maliyeti göz önünde bulundurmak anlamına gelir. Bunlar arasında bir denge bulmak, geliştiricinin iş tanımının yarısıdır.

Bazı hatalar 2 gününü harcayacak kadar önemli değil, onarıma 10 dakika harcayacak kadar önemlidir. Diğer hatalar deterministik değildir ve zaten bir test ortamının düzeltildiğini ispat edemediğini biliyorsunuz. Test ortamını ayarlamak 2 gün sürerse, bu hatalar için yapmazsınız. Bunun yerine, zamanınızı 2 gün yerine 5 dakika içinde bir test ortamı oluşturmak için yollar bulmak gibi daha akıllıca şeyler için harcarsınız.

Ve elbette, eğer onları yanlış yaparsanız bir müşterinin 100.000 $ + kaybedeceği hatalar var. Müşterinin her saat için 100.000 $ + lık kaybedeceği ve hatanın düzeltilmediği hatalar. Böceğe bakıp bir karar vermelisin. Tüm böcekleri aynı şekilde tedavi etmek için kullanılan battaniye ifadeleri işe yaramıyor.

Çok güzel bir soru! Benim düşüncem, sorunu yeniden oluşturamazsanız, o zaman% 100 yapamayacağınızı kesin olarak söyleyemezsiniz:

a) aslında sorunu düzeltir. b) başka bir hata oluştur

Bir hatanın meydana geldiği zamanlar vardır ve onu düzeltirim ve test etmeye zahmet etmem. İşe yaradığından emin olduğumu% 100 biliyorum. Fakat bizim QA departmanımızın işe yaradığını söyleyene kadar hala hala bir hata olduğunu ... ya da düzeltmeden yaratılan yeni bir hatayı bulabileceğimi düşünüyorum.

Hatayı çoğaltamaz ve ardından yeni sürümü yükleyip düzeltildiğini onaylarsanız,% 100 kesin bir şekilde, hatanın gittiğini söyleyemezsiniz.

Birkaç dakika boyunca başkalarına açıklamanıza yardımcı olacak bir analoji düşünmeye çalıştım ama aklıma hiçbir şey gelmedi. Vazektomi komik bir örnektir ama aynı durum değildir :-)

[ile ilişkili] eşzamanlı veritabanı erişimi, kümelenmiş uygulama, çok iş parçacıklı

Teşhis etmeden ve tamir etmeden önce her kusuru yeniden üretmek ve hata ayıklamakta ısrar etmek mantıklı mıdır?

Yeniden üretmeye çalışırken çok fazla zaman harcamam. Bir senkronizasyon problemine benziyor ve bunlar daha çok muhakkak buluyorlar (sorunun oluştuğu alt sistemi belirlemeniz gereken loglardan başlayarak), sorunu yeniden üretmenin bir yolunu bulmak ve bir hata ayıklayıcıya saldırmaktan çok . Tecrübelerime göre, kodun optimizasyon seviyesini azaltmak veya bazen ve hatta ek enstrümantasyonları etkinleştirmek, hatanın kendini göstermesini engellemek için yeterli gecikme veya eksik senkronizasyon ilkelliği eklemek için yeterli olabilir.

Evet, hatayı yeniden oluşturmanın bir yolu yoksa, düzeltdiğinizden emin olamayacaksınız. Ancak, müşteriniz size onu yeniden üretme yolu vermezse, aynı sonuçla fakat farklı bir kök nedenle benzer bir şey arıyor olabilirsiniz.

Her iki faaliyet de (kod inceleme ve test) gerekli, ikisi de yeterli değil.

Ayı, hatayı yeniden denemek için deneyler yaparak harcayabilir ve koda bakıp arama alanını daraltmak için bir hipotez oluşturmazsanız asla bir yere gidemezsiniz. Koddaki bir hatayı görselleştirmeye çalışırken göle bakarak aylar ayırabilir, bir kez, iki kez, üç kez bulduklarını düşünebilirsin, sadece giderek daha da sabırsız bir müşterinin "Hayır, böcek hala orada." "

Bazı geliştiriciler bir aktivitede (kod incelemesi ve yapım testleri) diğerinden daha iyidir. Mükemmel bir yönetici böcek atarken bu güçlü yönleri ağırlar. Bir takım yaklaşımı daha verimli olabilir.

Sonuçta, hatayı düzeltecek yeterli bilgi olmayabilir ve başka bir müşterinin de benzer bir sorun bulacağını umarak bir süre beklemesine izin vermeniz gerekir, bu da size yapılandırma sorunu hakkında daha fazla bilgi verir. Hatayı gören müşteri sorunu gerçekten istiyorsa, daha fazla bilgi toplamak için sizinle birlikte çalışacaktır. Bu sorun yalnızca bir kez ortaya çıkarsa, müşteri önemli olsa bile büyük olasılıkla yüksek öncelikli bir hata değildir. Bazen bir hata yapmamak, yeterince bilgili olmayan, net olmayan bir kusur aramak için etrafta dolaşan adam saatlerini üflemekten daha akıllıdır.