JavaScript'te bir video oynatıcı oluşturduğunuzu hayal edin. Bu video oynatıcı, kullanıcının özyinelemeli bir işlev kullanarak kullanıcının videosunu tekrar tekrar oynatıyor ve bu nedenle tarayıcı bir too much recursion RangeErroranda bir tetikleyecektir .

Muhtemelen hiç kimse döngü özelliğini bu kadar kullanmayacak. Uygulamanız bir hafta boyunca uygulama döngüsünden çıkmış olsa bile bu hatayı atmaz, ancak yine de devam eder. Sorunu çözmek, uygulamanızdaki döngü oluşturmanın çalışma şeklini yeniden tasarlamanızı gerektirir; bu, oldukça fazla zaman alır. Ne yaparsın? Neden?

• Hatayı düzeltmek

• Böceği bırak

Sadece insanların girebilecekleri hataları düzeltmesin mi? Hata düzeltme ne zaman yapmaz, ne zaman yapmaz?

DÜZENLE:

Özyinelemeli gerçek bir hataya neden olmama yaklaşımı sizin için endişeliyse, oynatıcının bir videoyu her oynatışında bir değişkenin arttığını varsayalım 1. 2 ⁵³ döngüden sonra bu değişken taşacak ve programınız bir istisna atarak başa çıkamayacak.

Pragmatik olmak zorundasın.

Hatanın gerçek dünyada tetiklenmesi muhtemel değilse ve düzeltilmesi gereken maliyet yüksekse, birçok kişinin düzeltmek için kaynakları iyi kullanacağını düşünürsünüz. Buna dayanarak, bırak dedim ancak kesmenin birkaç ay içinde sizin veya halefiniz için belgelenmesini sağlayın (son paragrafa bakınız).

Bununla birlikte, bu konuyu bir “öğrenme deneyimi” olarak kullanmalısınız ve bir sonraki döngüde tekrarladığınızda tekrar tekrar bir döngü kullanmayın.

Ayrıca, bu hata raporu için hazır olun. Son kullanıcıların sınırlara ve baskı kusurlarına karşı ne kadar başarılı olduklarını görünce şaşıracaksınız. Son kullanıcılar için bir sorun çıkarsa, düzeltmeniz gerekecektir - kesmeyi belgelemiş olmanızdan memnun olacaksınız.

Windows 95'te 49.7 gün sonra bilgisayarların çökmesine neden olan benzer bir hata oluştu . Piyasaya sürüldükten birkaç yıl sonra fark edildi, çünkü çok az sayıda Win95 sistemi bu kadar uzun süre kaldı. Yani bir nokta var: böcekler, diğer, daha önemli hatalar ile ilgisizleştirilebilir.

Yapmanız gereken , programın bütünü için risk değerlendirmesi ve bireysel hatalar için etki değerlendirmesidir .

• Bu yazılım bir güvenlik sınırında mı?
• Öyleyse, bu hata bir istismara neden olabilir mi?
• Bu yazılım, amaçlanan kullanıcılar için “görev kritik” midir? ( Java EULA'nın kullanmak için yasakladığı şeylerin listesine bakın )
• Hata veri kaybına neden olabilir mi? Finansal kayıp? İtibar kaybı?
• Bu hatanın oluşma olasılığı nedir? (Bunu senaryoya dahil ettin)

Ve bunun gibi. Bu , hangi hataların düzeltileceğine karar verme süreci olan hata triyajını etkiler . Hemen hemen tüm nakliye yazılımlarında henüz düzeltilmesi gereken kadar önemli sayılmayan küçük hataların çok uzun bir listesi vardır.

Diğer cevaplar zaten çok iyi ve örneğinizin sadece bir örnek olduğunu biliyorum ama bu sürecin henüz tartışılmayan büyük bir bölümünü belirtmek istiyorum:

Varsayımlarınızı tanımlamanız ve daha sonra bu varsayımları köşe davalarına karşı test etmeniz gerekir.

Örneğinize baktığımda, birkaç varsayım görüyorum:

• Özyinelemeli yaklaşım sonunda bir hataya neden olacaktır.
• Bu hatayı kimse görmeyecek çünkü videoların yığın sınırına ulaşması çok uzun sürüyor.

Diğer insanlar ilk varsayımı tartıştılar, ama ikinci varsayıma bakalım: Videom sadece ikinci bir saniyenin kesri ise?

Ve elbette, belki de bu yaygın bir kullanım durumu değildir. Ama sen gerçekten emin kimse çok kısa video yükleyebilir olacak? Videoların minimum bir süre olduğunu varsayıyorsunuz ve muhtemelen bir şey varsaydığınızı bile bilmiyordunuz! Bu varsayım, başvurunuzdaki başka yerlerde başka hatalara neden olabilir mi?

Tanımlanamayan varsayımlar büyük bir hata kaynağıdır.

Söylediğim gibi, örneğinizin sadece bir örnek olduğunu biliyorum, ancak varsayımlarınızı belirleme süreci (çoğu zaman göründüğünden daha zordur) ve sonra bu varsayımlara ilişkin istisnaları düşünmek, zamanınızı nereye harcayacağınıza karar vermede büyük bir faktördür.

Öyleyse kendinizi "bunun etrafında programlanmamalıyım, çünkü asla olmayacak" diye düşünürseniz, bu varsayımı gerçekten incelemek için biraz zaman ayırmalısınız. Genellikle, ilk başta düşündüğünüzden daha yaygın olabilecek köşe davaları düşüneceksiniz.

Söyleniyor, boşuna bir egzersiz haline geldiği bir nokta var. JavaScript uygulamanızın bir TI-89 hesap makinesinde mükemmel çalışıp çalışmadığından büyük olasılıkla umursamıyorsunuz, bu yüzden herhangi bir zaman harcamak sadece israf olur.

Diğer cevaplar bunu zaten kapsıyordu, ancak “bu önemli” ile “bu zaman kaybıdır” arasındaki çizgiyi ortaya çıkarmak kesin bir bilim değildir ve birinden tamamen farklı olabilecek birçok faktöre bağlıdır. bir başkasına kişi veya şirket.

Ancak bu sürecin büyük bir kısmı ilk önce varsayımlarınızı tanımlamak ve daha sonra bu varsayımların istisnalarını tanımaya çalışmaktır.

Aşağıdaki kağıdı okumanızı tavsiye ederim:

Güvenilirlik ve Tehditleri: Bir Taksonomi

Diğer şeylerin yanı sıra, programınızda ortaya çıkabilecek çeşitli arıza türlerini açıklar. Tanımladığınız şeye uyuyan hata denir ve bu yazıda şöyle açıklanır:

Bir hata ürettiğinde bir hata etkindir, aksi halde uykudadır. Aktif bir hata, a) önceden uykuda olan ve hesaplama işlemi veya çevresel koşullar tarafından etkinleştirilen bir iç arıza veya b) harici bir arızadır. Hata aktivasyonu, atıl bir hatanın aktif hale gelmesine neden olan bir bileşene bir girişin (aktivasyon düzeni) uygulanmasıdır. Çoğu iç arıza, hareketsiz ve aktif durumları arasında geçiş yapar

Bunu açıkladıktan sonra, hepsi bir maliyet-fayda oranına indirgenir. Maliyet üç parametreden oluşur:

• Sorun ne sıklıkla ortaya çıkıyor?
• Sonuçlar ne olurdu?
• Kişisel olarak seni ne kadar rahatsız ediyor?

İlk ikisi çok önemlidir. Mavi ayda bir kez kendini gösteren ve / veya hiç kimsenin umrunda olmayan veya mükemmel bir şekilde iyi ve pratik bir geçici çözümü olan bir böcek ise, bunu bilinen bir sorun olarak güvenle belgeleyebilir ve daha zorlu ve daha fazlasına geçebilirsiniz. önemli görevler. Bununla birlikte, eğer hata bir miktar para işleminin başarısız olmasına ya da uzun bir kayıt sürecinin kesilmesine neden olacak ve böylece son kullanıcıyı sinirlendirecekse, bunun üzerinde hareket etmeniz gerekir. Üçüncü parametre şiddetle tavsiye ettiğim bir şey. Vito Corleone'nin sözleriyle:

Kişisel değil. Onun işi.

Profesyonel iseniz, duyguları bir kenara bırakın ve en uygun şekilde davranın. Ancak, yazdığınız uygulama sizin için bir hobi ise, o zaman duygusal olarak ilgilisiniz ve üçüncü parametre bir hatanın düzeltilip düzeltilmeyeceğine karar vermede geçerli olduğu kadar geçerlidir.

Bu hata yalnızca birisinin oynatıcınızı 7 gün 24 saat şirket sunumu yapan bir lobi ekranına koymasını sağlayana kadar keşfedilmez. Demek hala bir böcek.

Cevabı Neler yapıyorsunuz? gerçekten bir iş kararıdır, mühendislik değil:

• Hata, kullanıcılarınızın yalnızca% 1'ini etkilerse ve oynatıcınız% 20 oranında başka bir özellik için gerekli olan bir özelliği desteklemiyorsa, seçim açıktır. Hatayı belgeleyin, sonra devam edin.
• Hata düzeltmesi yapılacaklar listenizdeyse, yeni özellikler eklemeye başlamadan önce düzeltmek daha iyi olur. Sıfır hatalı yazılım geliştirme sürecinin avantajlarından yararlanacaksınız ve zaten listenizde olduğundan fazla zaman kaybetmeyeceksiniz.

Özellikle büyük şirketlerde (veya büyük projelerde) ne yapılacağını belirlemenin çok pratik bir yolu var.

Sabitleme maliyeti, düzeltmenin getireceği getiriden daha yüksekse, hatayı saklayın. Viceversa, düzeltmenin maliyetinden daha fazla geri dönmesi durumunda, hatayı düzeltin.

Örnek senaryoda, bu pahalı hatayı düzeltmek yerine yeni özellikler geliştirirseniz, ne kadar kullanıcı kazanacağınıza veya ne kadar kullanıcı kazanacağınıza bağlı olarak değişir.

tl; dr Bu yüzden RESOLVED/WONTFIXbir şey var. Sadece aşırı kullanmayın - dikkatli olmazsanız teknik borç birikebilir. Bu, tasarımınızla ilgili gelecekte gelecekte başka sorunlara neden olabilecek temel bir sorun mu? O zaman tamir et. Aksi takdirde? Bir öncelik haline gelinceye kadar bırakın (eğer öyleyse).

Tanımladığın durumda aslında üç hata var:

1. Sabitlenmiş olup olmadığına karar vermek için, günlüğe kaydedilen tüm hataları değerlendirme sürecinin olmaması (hatayı bilet / iş günlüğünüze / hangi sistemde mevcutsa, doğru mu?)? Bu bir yönetim kararıdır.

2. Takımınızdaki becerilerin eksikliği, bunun gibi hatalı çözümlerin kullanılmasına yol açar. Gelecekteki sorunlardan kaçınmak için bunun ele alınması acil bir durumdur. (Hatalarınızdan öğrenmeye başlayın.)

3. Videonun çok uzun bir süre sonra gösterilmemesi sorunu.

Sadece üç hatanın (3) düzeltilmesi gerekmeyebilir.

Burada, bırakılanın tersine giderilen hatanın maliyetini değerlendirmeyi tartışan çok sayıda cevap var. Hepsinde iyi tavsiyeler var, ancak bir hatanın maliyetinin genellikle hafife alındığını, muhtemelen oldukça hafife alındığını eklemek isterim. Bunun nedeni, mevcut böceklerin sürekli gelişim ve bakım için suları karıştırmasıdır. Test cihazlarınızı birkaç "düzeltmeyecek" hatayı takip ederken, yazılımda gezinirken yeni hatalar bulmaya çalışın, çalışmalarını daha yavaş ve hataya daha açık hale getirin. Son kullanıcıları etkilemesi muhtemel olmayan birkaç "düzeltmeyecek" hata, geliştirmeye devam etmeyi yavaşlatmaya devam edecek ve sonuç daha ciddi olacaktır.

Yıllar süren kodlamada öğrendiğim bir şey, bir böceğin geri geleceğidir. Son kullanıcı her zaman onu keşfedecek ve geri rapor edecektir. Hatayı düzeltip düzeltmeyeceğiniz, "yalnızca" bir öncelik ve son tarih meselesidir.

Son sürümde tekrar tekrar tökezlediği için, yalnızca bir sonraki sürüm için bir gösteri durdurucusu haline gelmesi için bir sürümde düzeltmeye karşı karar verilmesine neden olan büyük hatalar oldu (bence büyük). Aynı tersi - biz hiç kimsenin kullanmadığı bir özellikte bir hatayı düzeltmek için zorlandık, ancak yönetimin görmesi kolay oldu.

Burada üç şey var:

Prensipler

Bu madalyonun bir yüzü. Bir dereceye kadar, ben hissediyorum olduğunu (onlar "çalışmak" bile, ya da kötü uygulamalara) kimse bunu fark olsa bile, sabitleme hatalar ısrar etmek iyi.

Şuna bu şekilde bakın: Asıl sorun, örneğinizde mutlaka hata değil, bir programcının ilk başta bu döngüyü bu şekilde uygulamanın iyi bir fikir olduğunu düşünmesidir. İlk andan itibaren, bunun iyi bir çözüm olmadığı açıktı. Şimdi iki olasılık var:

• Programcı henüz farketmedi. Şey ... bir programcının kodunun nasıl çalıştığına dair bir sezgiyi geliştirmesi gerekir. Özyineleme çok zor bir kavram değildir. Böceği düzelterek (ve tüm ek çalışmaları yerine getirerek), belki bir şey öğrenir ve yalnızca gelecekte yapılacak ek işlerden kaçınmak için hatırlar. Sebebi yeterli zaman vardı değildi Eğer yönetim programcılar olduğunu öğrenmek olabilir do daha kaliteli kodu oluşturmak için daha fazla zamana ihtiyacım var.

• Programcı farketti, ancak “sorun değil” olarak nitelendirdi. Eğer bu kalmaya devam ederse, sonuçta, gerçekten acıdığı yerlere yol açacak bir laissez-faire kültürü geliştirilir. Bu özel durumda, kimin umurunda. Ancak bu programcı bir dahaki sefere bir bankacılık uygulaması geliştiriyorsa ve belirli bir takımyıldızın asla olmayacağına karar verirse. O zaman yapar. Zor zamanlar.

pragmatizm

Bu diğer taraf. Of Tabii büyük olasılıkla, bu özel durumda, hata düzeltmek olmaz. Ama dikkat et - pragmatizm var ve sonra pragmatizm var. İyi pragmatizm, bir sorun için çabuk fakat sağlam ancak sağlam temelli bir çözüm bulmanızdır. Başka bir deyişle, fazla mesai yapmaktan kaçının, ancak gerçekte uyguladığınız şeyler hala iyi düşünülmüş. Kötü pragmatizm, "aynen böyle" çalışan ve ilk fırsatta kopacak olan bir şeyi bir kenara bıraktığınız zamandır.

Hızlı başarısız, zor başarısız

Şüphe durumunda, hızlı ve başarısız bir şekilde başarısız olun.

Bu, diğerlerinin yanı sıra, kodunuzun çevreyi değil, hata durumunu fark ettiği anlamına gelir .

Bu örnekte, yapabileceğiniz en az şey, zor çalışma zamanı hatası ("yığın derinliği aşıldı" veya bunun gibi bir şey) oluşmaması için, kendinizin zor bir istisnasıyla değiştirmektir. Örneğin, global bir sayacınız olabilir ve keyfi olarak 1000 videodan sonra kaybedeceğinize karar verebilirsiniz (ya da normal kullanımda asla ortaya çıkmayacak kadar yüksek ve çoğu tarayıcıda çalışacak kadar düşük). Ardından, bu istisnayı (örneğin RuntimeExceptionJava'da veya Java veya Ruby'de basit bir dize gibi genel bir istisna olabilir ) anlamlı bir mesaj verin. Yeni bir istisna türü yaratma ölçüsüne veya kendi programlama dilinizde ne yaparsanız yapmayacaksınız.

Bu şekilde, var

• ... kodun içindeki sorunu belgelemiştir.
• ... onu deterministik bir problem haline getirdi. Özel durumun olacağını biliyorsun . Temel tarayıcı teknolojisindeki değişikliklerin kaprisinde değilsiniz (yalnızca PC tarayıcısı değil, akıllı telefonlar, tabletler veya geleceğin teknolojisi hakkında da düşünün).
• ... sonunda düzeltmeniz gerektiğinde düzeltmeniz kolaylaştı. Sorunun kaynağı mesajınızla belirtilir, anlamlı bir geri dönüş elde edersiniz.
• ... hala "gerçek" hata işlemesi yaparak zaman kaybetmeyin (unutmayın, hatanın oluşmasını asla beklemeyin).

Benim sözleşmem "Paranoya:" kelimesiyle bu tür hata mesajlarının önüne geçmektir. Bu bana ve diğer herkese bu hatanın ortaya çıkmasını asla beklemeyeceğimin açık bir işaretidir . Onları "gerçek" istisnalardan açıkça ayırabilirim. Bir GUI veya bir günlük dosyasında böyle bir şey görürsem, ciddi bir sorunum olduğundan emin olduğumu biliyorum - ne de olsa gerçekleşmelerini beklemedim. At bu (Sorunun oluştuğu tam olarak nerede bildiği gibi sahte ayıklama bir sürü hayatımı kurtardın, hızlı ve oldukça kolay bir şekilde çözmek için iyi bir şans) noktasında ben krizi moduna geçmek.

İşyerimdeki üst düzey bir geliştiricinin masasındaki bir post-it

Kimseye yardım ediyor mu?

Bunun düşünce süreci için genellikle iyi bir başlangıç ​​noktası olduğunu düşünüyorum. Her zaman düzeltilecek ve geliştirilecek çok şey vardır - ama gerçekte ne kadar değer katıyorsunuz? ... kullanılabilirlik, güvenilirlik, bakım kolaylığı, okunabilirlik, performans ... veya başka bir açıdan.

Üç şey akla geliyor:

İlk olarak , bir hatanın kodda bırakılma kararının sorumlu bir şekilde yapılmasından önce, tespit edilen bir hatanın etkisinin iyice araştırılması gerekir. (Sizin örnekte ben bir kerede temsil büyüyen yığını sızıntı ve daha yavaş ve daha yavaş her yineleme ile tarayıcınızı yapmak olabilir bellek hakkında düşündük.) Bu kapsamlı soruşturma genellikle daha uzun, bu yüzden sabitleme tercih ediyorum ediyorum hatayı düzeltmeye daha sürer çoğu durumda hata.

İkincisi , böceklerin ilk başta düşündüğünden daha fazla etkiye sahip olma eğilimi vardır. Hepimiz çalışma kodunu çok iyi biliyoruz çünkü bu "normal" durum. Öte yandan böcek bir "istisna" dır. Elbette, hepimiz çok fazla hata gördük, ancak genel olarak daha fazla çalışma kodu gördük. Bu nedenle, çalışan kodun, buggy kodunun davrandığından daha fazla nasıl davrandığı konusunda daha fazla deneyime sahibiz. Çalışma kodu ve hangi durumlarda ne yapacağı ile ilgili milyonlarca kitap vardır. Buggy kodunun davranışı hakkında hiçbir şeye yaklaşılmıyor.

Bunun nedeni basit: Hatalar sıralı değil, kaos . Genellikle kendi içlerinde bırakılmış bir düzen izleri vardır (ya da başka bir yöne koyarlar: Emri tamamen yok etmezler), ancak bu dolandırıcılık doğası programcının istediği emri bir tahribattır. Kaosun kendisi doğru olarak tahmin edilmeye karşı çıkma eğilimindedir. Böcekli bir programın, doğru bir programın yapabileceğinden daha fazla ne yapacağını söylemek artık zordur, çünkü artık zihinsel düzenimize uymuyor.

Üçüncüsü , örneğiniz, hatayı düzeltmenin programı yeniden tasarlamak zorunda kalacağı yönünü içeriyordu. (Bu yönü kaldırırsanız, cevap basit: Hatayı düzeltin, yeniden tasarlama gerekmediğinden çok uzun sürmemelidir. Aksi halde :) Böyle bir durumda programa şu anda tasarlandığı şekilde olan güvenini kaybederim. Yeniden tasarlama bu güveni geri kazanmanın bir yolu olabilir.

Bunların hepsi , programlar insanların kullandığı şeyler ve eksik bir özellik veya başka bir yerde, gerçekten hantal bir hata, hatalarınızı düzelterek önceliğe sahip olabilir. Tabii ki pragmatik yoldan git ve ilk önce başka şeyler yap. Ancak, bir hatanın etkisinin ilk hızlı bir tahmininin tamamen yanlış olabileceğini asla unutmayın.

Düşük olasılık / Hafif sonuçlar = Düşük öncelikli düzeltme

• Oluşma olasılığı çok düşükse
• Oluşumun sonuçları ılımlı ise
• Sonra hata bir tehdit oluşturmaz, daha sonra öncelikli bir düzeltme değildir.

Ancak bu tembel geliştiriciler için bir koltuk değneği olamaz.

• "Çok düşük gerçekleşme" ne anlama geliyor?
• Ne "hafif sonuçları" bile demek?

Gelişme olasılığının çok düşük olduğunu ve sonuçları hafif olduğunu belirtmek için, geliştirme ekibinin kodu, kullanım düzenlerini ve güvenliği anlaması gerekir.

Çoğu geliştirici, ilk başta öğrendikleri şeylerin asla gerçekleşmeyeceğinden, gerçekten de çok fazla olacağından şaşırıyor.

Eğitim sistemimiz olasılık ve mantığı çok iyi öğretmiyor. Çoğu yazılım mühendisinin de dahil olduğu çoğu kişi, bozuk bir mantık ve kırık olasılık sezgisine sahiptir. Gerçek dünya problemleri ile tecrübe etmek ve kapsamlı simülasyonlarla tecrübe etmek, bunu çözmeyi bildiğim tek yol.

Sezgilerinizi gerçek dünya verileriyle yüzleşin

Kullanım kalıplarını takip edebilmek için birkaç kütük yapmak önemlidir. Kodu, olmaması gerektiğini düşündüğünüz şeylerle doldurun. Onların yaptıklarına şaşırırsınız. Bu şekilde, sezgilerinizi zor verilerle karşılaştırabilir ve iyileştirebilirsiniz.

Hafif bir problem örneğime ve bir kontrol ölçüsüne sahibim

Uzun zaman önce çalıştığım bir e-ticaret sitesinde, başka bir programcı bir hata yaptı: Bazı belirsiz durumlarda sistem müşteriyi kütük kayıtlarından bir kuruş az borçlandırdı. Bu hatayı keşfettim, çünkü muhasebe sistemini daha esnek hale getirmek için günlükler ile hesap bakiyeleri arasındaki farklılıkları belirlemek için raporlar yaptım. Bu hatayı hiçbir zaman düzelmedim, çünkü fark çok küçüktü. Fark günlük olarak hesaplandı ve aylık 2,00 ABD Dolarından düşüktü. Öyle oldu ki, bir yıl içinde mevcut sistemin yerini alması gereken yepyeni bir sistem geliştiriyorduk. Kaynakları aylık 2.00 ABD Doları olan ve uygun bir kontrol ölçütüne tabi tutulan bir şeyi düzeltmek için potansiyel olarak kârlı bir projeden ayırmanın bir anlamı yoktur.

Sonuç

Evet, hemen düzeltilmesi gerekmeyen, yeni özellik geliştirmeyi geciktirecek kadar önemli olmayan hatalar var. Ancak sistemin küçük olduğundan emin olmak için bu böceğin kontrolüne sahip olması gerekir, çünkü kendi sezgimize güvenemeyiz.

Sanırım bu baştan yanlış soruyu soruyor.

Soru "bu hatayı düzeltmeli miyim, yoksa bu hatayı düzeltmemeli mi" değil. Herhangi bir geliştiricinin sınırlı bir süresi vardır. Bu yüzden soru şu: "Bir saat, dört saat veya bir haftada yapabileceğim en faydalı şey nedir".

Bu hatayı düzeltmek yapılacak en faydalı şeyse, yazılımı çoğu kişi için en fazla miktarda geliştirdiği için hatayı düzeltin. Başka bir yerde daha büyük geliştirmeler yapabilirseniz, insanların kaçırdığı özellikleri ekleyerek veya daha önemli bir hatayı düzelterek, diğer şeyleri yapın. Ve gelecekteki gelişiminizi daha verimli hale getiren her şey için ekstra bonus puanları.

Hata onarım her zaman bir overkill

İlk önce böcek kısmını sınıflandıralım .

Dürüst bir hata mı , örneğin bir kerelik hata mı yoksa testlerden kaçan değişken gölgeleme mi? Bu durumda, sorunu "düzeltmeye" ek olarak yeni ünite testleri de yazdığınızdan eminim ki, tüm bu kodların yararlı bir çalışma olduğu durumlarda yakındaki kodu tekrar gözden geçirme fırsatı bulmuşsunuzdur .

Bununla birlikte, aslında sizin durumunuzda olduğu gibi bir tasarım hatası varsa , tasarımı yeniden değerlendirmelisiniz veya en kötü durumda, bu özelliği devre dışı bırakın .

Yani, lütfen düzeltmeyi denemeyin .

Elbette daha kötüsünü yapabilirdin - hack-on-hack metodolojisini deneyebilirsin . Video döngü bir hack (kötü mimari ve bilinen bir kopma var). Döngü sınırını ekleyebilirsiniz , böylece N yinelemelerden sonra (test ettiğiniz tarayıcı sınırının altındadır) döngü sona erer.

Sonuçlar açıktır, şimdi hem bozuk kodu hem de yeni döngü sınırını desteklemelisiniz.

PS olağanüstü görünüm için özür diler.

PPS Terminoloji ile ilgili bir not: bir hatayı "düzeltemezsiniz". Belki bir veteriner olabilir, ama oraya gitmeyelim ;-). Sorunlar giderilir veya "düzeltilir", hatalar giderilir veya giderilir.