: Bu makale yalnızca eğlence amaçlı yazılmıştır. İşyerinde tekrarlamaya çalışmayın. Ancak evde ne yapmak istiyorsanız onu yapın. Yasal Uyarı Biz geliştiriciler düzenli olarak karşılaşıyoruz, bu işimizin sadece bir parçası. Bu nedenle ilk bakışta “Bilerek hata yapabilir misiniz?” sorusu akla gelir. sıradan görünebilir - "Evet, elbette bir hata yazabilirim." Ancak düşündüğünüzde artık her şey o kadar da açık görünmüyor. hatalarla Gerçek şu ki . Bir hata bir hatadır, genel olarak bir kusurdur. hata, bozuk kodla aynı şey değil çalışma programı. Yazılım sorunları bağlamında "hata" terimi, 1947'de bir güvenin Harvard Mark II bilgisayarında arızaya neden olmasıyla ortaya çıktı. Mühendisler kelimenin tam anlamıyla rölelerden birine sıkışmış bir güve buldular ve bunu "bulunan ilk gerçek hata durumu" olarak adlandırdılar. Sorun ne? Dünyanın matematik formülleriyle çok iyi tanımlandığı biliniyor. Ve formüller aslında algoritmalardır. Bu nedenle, eğer bir olguyu matematiksel olarak tanımlayabilseydik, ortaya çıkan formülü yanlış sonuç verecek şekilde düzeltmek önemsiz olmayan bir iştir. Yine de umutsuzluğa kapılmanın zamanı değil. burada bize yardımcı olabilir. Bunları hepimiz gördük . Sınırlarda her zaman bir sorun vardır 🤷♀️. Öyleyse, bir hata oluşturmanın ilk fikrine dikkat edelim - . yalnızca bazen Sınır koşulları if index == 0 {…} else if index == n-1 {…} uç durumları göz ardı edin Genel olarak diziler arasında yineleme yapmak potansiyel hataların deposudur. Ve bunlardan en yaygın olanı olmasıdır. Eğer böyle bir şeye hiç rastlamadıysanız, hiç kodlamamışsınız demektir. Ne yazık ki, bu hata o kadar popüler ki insanlar diziler için gibi güvenli sarmalayıcılar yazmaya başladı. Yani bugün meslektaşlarınız bu şey olmadan herhangi bir kodu onaylamaz. Deneyebilirsin ama pek mümkün değil… indeksin sınırların dışında array[safe: index] Yaygın hatalar içerir. Özyinelemeli bir algoritma, çıkış koşulu olmadığında sonsuz sayıda yinelenebilir. Özyineleme burada isteğe bağlı görünüyor - yazın ve işiniz bitti. Ancak böceğin popülaritesi bir kez daha aleyhimize oynuyor. Geliştiriciler sonsuz döngülerin potansiyel sorunlarının çok iyi farkındalar ve kod incelemesinde gözleri kesinlikle buna benzer bir şeyi yakalayacak 👮 yığın taşmasını while true Sinsi planınızı hala üretime sokmak için, . çıkış koşulları için global bir değişken kullanmayı deneyin ve onu sessizce dışarıdan değiştirin var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } } Genel tavsiye Konu hata yazmaya gelince ChatGPT'nin bile yardım etmeyi reddetmesi komik. Belki de sadece premium aboneliğe ihtiyacım var… 🤔 İşin iyi tarafına bakılırsa , hatasız kod yazmaya katkıda bulunan bir dizi genel kural sunar: Küçük Artışlarla kod yazın, kodlama standartlarını takip edin, birim testleri yazın ve falan-bla-bla. Tam tersini yapmayı deneyebiliriz - spagetti kodu yazıp SOLID'i unutabiliriz. Ancak bu şekilde yazdığımız . Zarif, nokta atışı bir silah yerine, programımızı fethedecek, yönetilemez bir kaosla karşılaşıyoruz. yapay zeka tüm kodlar üzerindeki kontrolümüzü kaybederiz Hata oluşturma sorununu çözerken alt görevleri belirlemeye değer. Öncelikle bazı nadir görülen uç durumları bulmamız gerekiyor. İkinci olarak, kod incelemesinden geçebilmesi için hatayı normal kod olarak gizlememiz gerekir. Üçüncüsü, QA departmanının dikkatini köreltmeliyiz. Dördüncüsü, hemen yakalanmayın. Ancak bu zaten isteğe bağlıdır. Genel tavsiyem şu şekildedir (ve siz de yorumlarınızda kendi tavsiyenizi paylaşırsınız): . İki katına çıkarmak için önemli parametrelerin değerlerini en beklenmedik yerlerden değiştirin. Bunu sanki bir VPN'mişsiniz gibi birkaç sınıf aracılığıyla yapın. Erişim düzeyini değiştirin Alt sınıfta beklenmedik bir mantık uygulayın. Kısacası . SOLID'deki L prensibini kırın class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } } Daha büyük işlevlerdeki sinsi değişikliklerinizi gizleyin. ; kalabalığın içinde kaybolun. Ne kadar çok sıra olursa o kadar iyi Çekme isteklerinde de aynı prensibi kullanın. Küçük bir PR'da fark edilme olasılığı daha yüksektir. Hatayı parçalara ayırmaya ve bunları koymaya çalışın. Mümkünse farklı eleştirmenlere de. farklı çekme isteklerine QA'nızın zayıf noktalarını bulun ve güvenini kazanın. Veya kontrol sırasında konuşarak dikkatlerini dağıtın. Bu arada Heisenbug'u duydun mu? Bu, araştırma/ sırasında kaybolan veya davranışını değiştiren bir hatadır. Schrödinger'in kedisi gibi. Düzeltme sorunu size atanmayacaksa mükemmeldir. hata ayıklama Heisenbug'un yaygın bir örneği, program bir optimizasyon derleyicisi ile derlendiğinde ortaya çıkan bir hatadır, ancak aynı program optimizasyon olmadan derlendiğinde ortaya çıkmaz (genellikle bir hata ayıklayıcı ile incelemek amacıyla yapıldığı gibi). Hata ayıklama sırasında, optimize edilmiş bir programın normalde kayıtlarda tutacağı değerler genellikle ana belleğe aktarılır. Yapabilirsiniz Kendine inan! Tarih, çok ciddi şirketlerde üretime bir hatanın kabul edildiği örnekleri bilir. En pahalı yazılım hatalarından biri, 1996 yılında, Cluster görevini taşıyan Ariane 5 roketinin havalandıktan sadece 40 saniye sonra patlamasıyla meydana geldi. Başarısızlığın roketin yönlendirme sistemindeki bir yazılım hatasından kaynaklandığı belirtildi. Ariane 5 Flight 501: 1999'da NASA, bir yazılım hatası nedeniyle Mars Climate Orbiter'ı kaybetti. Yazılım, metrik birimler (newton-saniye) yerine emperyal birimleri (pound-saniye) kullandı ve uzay aracının Mars atmosferinde yanmasına neden oldu. NASA'nın Mars Climate Orbiter'ı: Dahası, duvardan atlama veya Mahatma Gandh davranışı gibi bazı hatalar özellik haline gelebilir… muhtemelen. Mario'daki Civilization'daki Bir hata geliştirmek, algoritmanız üzerinde düşünme ve olası sorunları kapsamlı bir şekilde tahmin etme yeteneğidir. Yani kodda hata bırakmak için bir nedeniniz olmasa bile, yine de dikkate almaya değer.
