Kasıtlı olarak bir hata yapabilir misiniz?

Biz geliştiriciler düzenli olarak hatalarla 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.

Gerçek şu ki hata, bozuk kodla aynı şey değil . Bir hata bir hatadır, genel olarak bir kusurdur.

çalışma programı.

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ü yalnızca bazen yanlış sonuç verecek şekilde düzeltmek önemsiz olmayan bir iştir. Yine de umutsuzluğa kapılmanın zamanı değil. Sınır koşulları burada bize yardımcı olabilir. Bunları hepimiz gördük if index == 0 {…} else if index == n-1 {…} . Sınırlarda her zaman bir sorun vardır 🤷‍♀️. Öyleyse, bir hata oluşturmanın ilk fikrine dikkat edelim - uç durumları göz ardı edin .

Genel olarak diziler arasında yineleme yapmak potansiyel hataların deposudur. Ve bunlardan en yaygın olanı indeksin sınırların dışında 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 array[safe: index] 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…

Yaygın hatalar yığın taşmasını içerir. Özyinelemeli bir algoritma, çıkış koşulu olmadığında sonsuz sayıda yinelenebilir. Özyineleme burada isteğe bağlı görünüyor - while true 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 👮

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 yapay zeka , 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 tüm kodlar üzerindeki kontrolümüzü kaybederiz . Zarif, nokta atışı bir silah yerine, programımızı fethedecek, yönetilemez bir kaosla karşılaşıyoruz.

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):

• Erişim düzeyini değiştirin . İ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.

• 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. Ne kadar çok sıra olursa o kadar iyi ; kalabalığın içinde kaybolun.

• Ç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ı farklı çekme isteklerine koymaya çalışın. Mümkünse farklı eleştirmenlere de.

• 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/ hata ayıklama 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.

Yapabilirsiniz

Kendine inan! Tarih, çok ciddi şirketlerde üretime bir hatanın kabul edildiği örnekleri bilir.

Ariane 5 Flight 501: 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.

NASA'nın Mars Climate Orbiter'ı: 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.

Dahası, Mario'daki duvardan atlama veya Civilization'daki Mahatma Gandh davranışı gibi bazı hatalar özellik haline gelebilir… muhtemelen.

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.