it-swarm.dev

Kodlama sırasında hata sayısı nasıl azaltılır?

Kimse mükemmel değildir ve ne yaparsak yapalım, zaman zaman hataları olan bir kod üreteceğiz. Hem yeni yazılım yazarken hem de mevcut kodu değiştirirken/korurken ürettiğiniz hata sayısını azaltmak için bazı yöntemler/teknikler nelerdir?

30
GSto

Süslü kodlamadan kaçının. Kod ne kadar karmaşıksa, hata olma olasılığı da o kadar artar. Genellikle modern sistemlerde, açıkça yazılmış kod yeterince hızlı ve küçük olacaktır.

Kullanılabilir kitaplıkları kullanın. Bir yardımcı program rutin yazma hataları olmamasının en kolay yolu onu yazmak değil.

Daha karmaşık şeyler için birkaç resmi teknik öğrenin. Karmaşık koşullar varsa, bunları kalem ve kağıtla çivileyin. İdeal olarak, bazı ispat tekniklerini bilin. Kodu doğru bir şekilde kanıtlayabilirsem, düzeltmesi kolay büyük, aptal, bariz hatalar dışında neredeyse her zaman iyidir. Açıkçası, bu sadece şimdiye kadar devam ediyor, ancak bazen küçük ama karmaşık şeyler hakkında resmi olarak akıl yürütebilirsiniz.

Mevcut kod için, yeniden düzenleme yapmayı öğrenin: kodda davranışı değiştirmeden daha okunabilir hale getiren otomatik bir araç kullanarak kodda nasıl küçük değişiklikler yapılacağını öğrenin.

Çok hızlı bir şey yapma. İşleri doğru yapmak, ne yaptığınızı kontrol etmek ve ne yaptığınızı düşünmek için biraz zaman ayırmak daha sonra büyük bir zaman ödeyebilir.

Kodu yazdıktan sonra, iyi hale getirmek için elinizde olanı kullanın. Birim testleri harika. Testleri önceden önceden yazabilirsiniz, bu da büyük geri bildirim olabilir (tutarlı bir şekilde yapılırsa, bu test odaklı bir gelişmedir). Uyarı seçenekleriyle derleyin ve uyarılara dikkat edin.

Bir başkasına koda bakmasını sağlayın. Resmi kod incelemeleri iyidir, ancak uygun bir zamanda olmayabilirler. Çekme istekleri veya scm'niz bunları desteklemiyorsa, eşzamansız incelemelere izin verir. Arkadaş kontrolü daha az resmi bir inceleme olabilir. Çift programlama, iki çift gözün her şeye bakmasını sağlar.

58
David Thornley

Birim Testleri ikinci kez açılan hata sayısını azaltmanıza izin verin. Kodunuzda bir hata bulursanız, birim testi yazmak, kodun daha sonra tekrar gelmeyeceğinden emin olmanızı sağlar. (Ayrıca, tüm vakaları düşünmek ve binlerce ünite testini önceden yazmak bazen zor bir iştir)

30
Ryan Hayes

Ana dillerim C++ ve Python olmasına rağmen oldukça işlevsel bir programlama stili geliştirdim. Tüm bağlamın bir işleve (veya yönteme) geçmesi, bu işlevin işini yapması ve aradığım anlamlı verileri döndürmesi durumunda kodumun çok daha sağlam hale geldiğini fark ettim.

Örtük durum düşmandır ve benim deneyimime göre 1 numaralı hata kaynağıdır. Bu durum genel değişkenler veya üye değişkenler olabilir, ancak sonuçlar sorun istediğiniz işleve geçmeyen bir şeye bağlıysa. Açıkçası durumu ortadan kaldırmak mümkün değildir, ancak minimize edilmesinin program güvenilirliği üzerinde büyük olumlu etkileri vardır.

Ayrıca iş arkadaşlarıma her şubenin (eğer, süre,? :) için muhtemel bir hata olduğunu söylemek istiyorum. Hatanın tezahürünün ne olacağını söyleyemem, ancak kodunuz ne kadar az koşullu davranış olursa, yürütme sırasında kod kapsamının daha tutarlı olması nedeniyle hata ücretsiz olması daha olasıdır.

Şekil verin, tüm bunların performans üzerinde de olumlu etkileri var. Kazan!

9
dash-tom-bang

Birim test yorumlarının her ikisinde de +1.

Bunun ötesinde, derleyicinizin sunduğu en yüksek uyarı seviyesini ayarlayın ve uyarıların hata olarak değerlendirildiğinden emin olun. Hatalar genellikle bu "hatalı" hatalarda gizlenir.

Benzer şekilde, derleme zamanında çalışan statik analiz araçlarına yatırım yapın (bunları derleyici uyarılarının fazladan bir seviyesi olarak görüyorum).

9
Alan

Bahsedilenlere ek olarak:

  • Hata kodlarını göz ardı etmeyin - ör. geçerli bir sonuç aldığınızı, bir dosyanın başarıyla oluşturulduğunu vb. varsaymayın. Çünkü bir gün bir şey olacak.
  • Kodunuzun asla bir koşul girmeyeceğini ve bu nedenle "bu koşulu görmezden gelmenin güvenli olduğunu" varsaymayın.
  • Kodunuzu test edin, sonra başka biri tarafından test ettirin. Ben kendi kodumu test etmek için en kötü kişi olduğumu düşünüyorum.
  • Bir mola verin, sonra kodunuzu tekrar okuyun ve "açık olanı kaçırıp kaçırmamaya" bakın. Genellikle başıma geliyor.

Şu anda unuttuğum bir sürü başka şey var, ama diğerleri kesinlikle onları düşünecek. :)

9
MetalMikester
  • Daha fazlasını yapan daha az kod yazın.
  • Düşük düzeyli sonuçları ve yüksek düzeyli sonuçları düşünün
  • Kodunuzda oluşturduğunuz soyutlamayı düşünün.
  • Mümkünse yalnızca temel karmaşıklığı yazın.
8
Paul Nathan

Biraz daha az teknik cevap: Yorgunken (9 saat/gün yeterlidir), sarhoş veya 'pişmiş' olduğunda programlamayın. Yorgun olduğumda temiz kod yazmak için gerekli sabrım yok.

8
Alexandru

birim testleri ve entegrasyon testleri yazın.

7
ysolik

Burada birim test ve araçlarla ilgili bazı harika cevaplar var. Onlara ekleyebileceğim tek şey şudur:

Testçilerinizi olabildiğince erken dahil edin

Bir test ekibiniz varsa, bunları kod kaliteniz için kapı bekçileri olarak ele alma ve kusurlarınızı sizin için yakalama tuzağına düşmeyin. Bunun yerine, onlarla çalışın ve mümkün olduğunca erken ekleyin (çevik projelerde bu projenin başlangıcından itibaren olacaktır, ancak gerçekten denersek onları daha önce dahil etmenin yollarını bulabiliriz).

  • Test planlarının ne olduğunu öğrenin. Test durumlarını onlarla gözden geçirin - hepsini kodunuzla mı kaptınız?
  • Onlardan gereksinimleri anlamalarını isteyin. Seninkiyle aynı mı?
  • Keşif testi yapmak için onlara erken çalışma yapıları verin - önerecekleri geliştirmelere hayran kalacaksınız.

Test kullanıcılarınızla iyi bir çalışma ilişkisine sahip olmak, herhangi bir hasar vermeden önce kötü varsayımları ve kusurları gerçekten erken yakalayabileceğiniz anlamına gelir. Ayrıca, testçilerin ürün tasarımına yardımcı olma ve bunları düzeltmek için zaman olduğunda kullanılabilirlik sorunlarını yakalama konusunda kendilerini güçlenmiş hissettikleri anlamına gelir.

5
Paddyslacker

Statik Analiz Araçları

FindBugs gibi eklentiler ve uygulamalar kodunuzu tarayın ve potansiyel hataların olduğu yerleri bulun. Değişkenlerin başlatılmadığı ve kullanılmadığı yerler ya da sadece 10'un 9 katı olan çılgın şeyler, hataların ortaya çıkmasını kolaylaştırır. Bunun gibi araçlar, henüz bir hata olmasa bile, boneheadimin yolda aşağı hareket etmesini önlememe yardımcı olur.

Not: Her zaman araştırmayı unutmayın neden bir araç size bir şeyin kötü olduğunu söyler. Öğrenmek için asla acıtmaz (ve her durumda her şey doğru değildir).

4
Ryan Hayes

Kod denetimi veya çift programlama gibi diğer akran denetimi biçimleri.

Fagan denetimi gibi yapılandırılmış kod incelemeleri en azından etkili ve verimli olabilir birim testi olarak ve hatta bazı durumlarda birim testinden daha iyi olduğu kanıtlanmıştır. Denetimler, yazılım yaşam döngüsünde daha önce ve kod dışındaki yapay nesnelerle de kullanılabilir.

Karl Wiegers'ın Yazılımdaki Akran Değerlendirmeleri bu konuda harika bir kitap.

3
Michael

Buradaki diğer tüm önerilere ek olarak, olası tüm uyarıları en yüksek hassasiyet seviyesine getirin ve hata olarak kabul edin. Dilin sahip olduğu linting araçlarını da kullanın.

Uyarılarla kaç basit hatanın yakalanabileceğine ve bu basit şeylerin kaçının kodunuzdaki gerçek hatalara dönüştüğüne şaşıracaksınız .

2
greyfade

Burada birçok iyi yanıt var, ama eklemek istediğim birkaç şey var. Gereksinimi gerçekten anladığınızdan emin olun. Kullanıcı gereksinimin X anlamına geldiğini ve programcı bunun Y anlamına geldiğini düşündüğünde çok fazla hata gördüm. Kötü veya belirsiz gereksinimler hakkında açıklama için geri itin. Hepimizin içine atlamayı ve kodlamayı sevdiğimizi biliyorum ama daha fazla anlayış sağlamak için daha fazla zaman harcadık, daha az yeniden çalışma ve hata düzeltmesi olacak.

Desteklediğiniz işi tanıyın, genellikle eksik olan veya daha fazla açıklamaya ihtiyaç duyan gereksinimlerdeki şeyleri görürsünüz. Y görevini belirtildiği gibi yaparsanız, mevcut Z özelliğini bozacağını bilin.

Veritabanı yapınızı anlayın. Birçok hata, sözdizimsel olarak doğru olan ancak yanlış sonuçlar veren bir sorgunun sonucudur. Sonuçlarınızın ne zaman komik göründüğünü nasıl tanıyacağınızı öğrenin. Karmaşık bir raporlama sorgusu yazıyorsam, gitmeye hazır olarak işaretlemeden önce sonuçlarımı gözden geçirmek için bir teknik uzman alıyorum, kaçınılmaz olarak kaçırdığım verilerde bir şey görecekler. O zaman kendinize neyi yakalamadıklarını not edin ve bir dahaki sefere simliar yaptığınızı hatırlayın.

2
HLGEM

Code-test-code-test yerine Test-Code-Test uygulamasını takip ediyorum. Bu, kullanım durumlarını düşünmeme ve mantığı uygun şekilde çerçevelememe yardımcı oluyor

1
viv

Şaşırtıcı bir şekilde, aşağıdaki üç çok önemli noktadan henüz bahsedilmemiştir:

  • İddiaları bolca kullanın. Her zaman kendinize sormanız gereken soru "bunu iddia etmeli miyim?" ama "iddia etmeyi unuttuğum bir şey var mı?"

  • Değişmezliği tercih edin. (Nihai/salt okunur olarak kullanın.) Ne kadar az değişebilir duruma sahipseniz, o kadar az şey ters gidebilir.

  • Zamanından önce optimize etmeyin. Birçok programcı performans endişeleriyle yan izler alır ve performansın bir sorun olup olmayacağını önceden bilmeden kodlarını gereksiz yere kıvırmalarına ve tasarımlarını piçlendirmelerine neden olur. İlk olarak, performansınızı göz ardı ederek yazılım ürününüzü akademik şekilde oluşturun; sonra, kötü performans gösterip göstermediğine bakın; (Muhtemelen olmayacaktır.) Herhangi bir performans sorunu varsa, tüm kod tabanınızı değiştirmek ve kesmek yerine ürününüzü performans gereksinimlerini karşılayacak Güzel ve resmi algoritmik optimizasyonlar sağlayabileceğiniz bir veya iki yer bulun. Burada ve orada saat döngülerini sıkın.

1
Mike Nakis

Yeniden Paylaşıcı gibi kod inceleme araçlarını kullanın veya IntelliJ IDEA gibi birçok kopya hakkında uyarı veren IDE'leri kullanın. - böcek ve diğerleri "yazılan ancak hiç okunmayan" değişkenlere işaret eder. Bana çok zaman kazandırdı.

1
DonJoe

Bence en önemli teknik acele etmeyin. Yeni bir modülü kodlamak için iki güne ihtiyacınız olduğunu düşünüyorsanız, ancak patronunuz sizi yalnızca bir günde kodlamaya zorlarsa ... kodunuz daha fazla hataya neden olacaktır.

Bir süre önce okuduğum kitaplardan biri, kırık pencereler ile yaşamamaman gerektiğini söyledi, çünkü insanlar anotronun kırılıp kırılmadığını umursamayacaklar ... Kodlama aynı, herkes umursacak bir şey yaparken ilk olmak kötü ama hızlı, ama hiçbiri bir umurumda değil cehennem kod, çok hata ve çok kötü tasarım ve stil ile.

1
greuze