Kodlama yaparken hata sayısını nasıl azaltabilirim?

Kimse mükemmel değildir ve ne yaparsak yapalım, zaman zaman içinde böcek bulunan kodlar üreteceğiz. Hem yeni yazılım yazarken hem de mevcut kodu değiştirirken / sürdürürken, ürettiğiniz hata sayısını azaltmak için bazı yöntemler / teknikler nelerdir?

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

Kullanılabilir kütüphaneleri kullanın. Bir yardımcı program yordamı yazarken hata olmamasının en kolay yolu onu yazmamaktır.

Daha karmaşık şeyler için birkaç resmi teknik öğrenin. Karmaşık durumlar varsa, bunları kalem ve kağıtla çivileyin. İdeal olarak, bazı ispat tekniklerini bilin. Eğer kodun doğru olduğunu ispatlayabilirsem, düzeltmesi kolay olan büyük, dilsiz, belirgin hatalar dışında neredeyse her zaman iyidir. Açıkçası, bu sadece çok ileri gidiyor, ama bazen resmen küçük ama karmaşık şeyleri aklınıza getirebilirsiniz.

Var olan kod için, yeniden düzenlemeyi öğrenin: davranışta değişiklik yapmadan kodu daha okunaklı hale getiren, genellikle otomatik bir araç kullanarak kodda küçük değişiklikler yapma.

Çok hızlı bir şey yapmayın. İş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 yapmak için ne gerekiyorsa kullanın. Birim testleri harika. Sık sık önceden gelebilecek testleri yazabilirsiniz, bu da büyük geri bildirim olabilir (tutarlı bir şekilde yapılırsa, bu teste dayalı bir gelişmedir). Uyarı seçenekleriyle derleyin ve uyarılara dikkat edin.

Şifreye bakacak başka birini bul. Resmi kod incelemeleri iyidir, ancak uygun bir zamanda olmayabilirler. İsteklerinizi çekin veya scm'niz onları asenkronize incelemelere izin vermiyorsa desteklemiyorsa benzer. Arkadaş kontrolü daha az resmi bir inceleme olabilir. Çift programlama, iki göz çiftinin her şeye bakmasını sağlar.

Birim Testleri , ikinci kez açılan böcek sayısını azaltmanıza izin verir. Kodunuzda bir hata bulursanız, bir birim testi yazmak daha sonra geri gelmemesini sağlayacaktır. (Artı, tüm davaları düşünmek ve binlerce ünite testi yazarken öne geçmek bazen zor oluyor)

Her iki birim test yorumu için +1.

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

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

Bahsedilenlere ek olarak:

• Hata kodlarını göz ardı etmeyin - örneğin 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 olur.
• Kodunuzun asla bir koşul girmeyeceğini ve bu nedenle “bu durumu yok saymanın güvenli olduğunu” varsaymayın.
• Kodunuzu test edin, sonra başka biri tarafından test ettirin. Kendi kodumu test edecek en kötü insan olduğumu biliyorum.
• Bir ara verin, ardından kodunuzu tekrar okuyun ve "açık olanı kaçırdıysanız" bakın. Genellikle bana olur.

Şu an unuttuğum başka şeyler var ama diğerleri kesinlikle onları düşünecek. :)

Başlıca dillerimin C ++ ve Python olmasına rağmen oldukça işlevsel bir programlama stili geliştirdim. Tüm bağlamı, bu işin işini yapması gereken bir işleve (ya da yönteme) aktarırsam ve aradığım anlamlı verileri döndürürsem kodumun daha sağlam hale geldiğini öğrendim.

Örtük devlet düşmandır ve deneyimlerime göre 1 numaralı böcek kaynağıdır. Bu durum genel değişkenler veya üye değişkenler olabilir, ancak sonuçlar işleve geçmeyen bir şeye bağlıysa sorun isteyebilirsiniz. Açıkça, durumu ortadan kaldırmak mümkün olmamakla birlikte, bunu en aza indirmenin program güvenilirliği üzerinde büyük olumlu etkileri vardır.

İş arkadaşlarıma da her şubenin (eğer öyleyse? :) muhtemel bir hata olduğunu söylemek isterim. Böceğin tezahürünün ne olacağını söyleyemem, ancak kodunuzun şartlı davranışı ne kadar az olursa, uygulama sırasında kod kapsamının daha tutarlı olması nedeniyle hatasızlık olasılığı o kadar artar.

Go rakamı, tüm bunların da performans üzerinde olumlu etkileri var. Kazan!

• Daha fazlasını yapan daha az kod yazın.
• Düşük seviye uygulamalar ve üst düzey sonuçlar hakkında düşünün
• Kodunuzda yarattığınız soyutlamayı düşünün.
• Mümkünse yalnızca temel karmaşıklığı yazın.

Biraz daha az teknik cevap: yorulduğunuzda (9 saat / gün yeterli), sarhoş veya 'pişmiş' olduğunuz zaman programlamayın. Yorgun olduğumda temiz kod yazmak için gerekli sabra sahip değilim.

Birim testleri ve entegrasyon testleri yazınız .

Birim test ve araçları ile ilgili bazı büyük cevaplar. Onlara ekleyebileceğim tek şey şudur:

Test cihazlarınızı olabildiğince erken işe alın

Eğer bir test ekibiniz varsa, onlara kod kaliteniz için kapı bekçisi olarak davranma ve sizin için kusurlarınızı yakalama tuzağına düşmeyin. Bunun yerine, onlarla çalışın ve mümkün olduğunca erken onları dahil edin (ç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 bulun. Test durumlarını onlarla inceleyin - hepsini kodunuzla mı kapatıyorsunuz?
• Gereksinimleri anlamalarını isteyin. Seninkilerle aynı mı?
• Açıklayıcı testler yapmak için onlara erken çalışma yapmaları verin - önerecekleri gelişmelere hayran kalacaksınız.

Test cihazlarınızla iyi bir çalışma ilişkisine sahip olmak, herhangi bir zarar vermeden önce, gerçekten erken varsayımları ve kusurları yakalayabileceğiniz anlamına gelir. Bu aynı zamanda, test uzmanlarının, ürün tasarımında yardımcı olma ve kendilerini düzeltmek için zaman olduğunda kullanılabilirlik sorunlarını yakalama konusunda kendilerini daha güçlü hissettiği anlamına gelir.

Statik Analiz Araçları

FindBugs gibi eklentiler ve uygulamalar kodunuzu tarar ve olası hataların olduğu yerleri bulur . Değişkenlerin başlatılmadığı ve kullanılmadığı veya 10'dan 9 kez çıkan sadece çılgınca şeyler olduğu yerler, böceklerin ortaya çıkmasını kolaylaştırır. Bunun gibi araçlar, henüz bir böcek olmasa da, başımın aşağı doğru hareket etmesini önlememe yardımcı oluyor.

Not: Bir aracın neden bir şeylerin kötü olduğunu söylediğini her zaman araştırmayı unutmayın . Asla öğrenmek için acıtmaz (ve her durumda her şey doğru değildir).

Kod denetimi veya çift programlama gibi diğer akran değerlendirmesi.

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

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

Buradaki diğer tüm önerilere ek olarak, olası tüm uyarıları en yüksek hassasiyet düzeyine getirin ve hata olarak kabul edin. Ayrıca dilin sahip olduğu herhangi bir yazı aracını kullanın.

Sen olurdu hayret birçok basit hatalar uyarı ve nasıl bu basit şeylerin birçoğu Kodunuzdaki gerçek böcek çevirmek tarafından yakalanmış olabilir nasıl.

Burada birçok iyi cevap var, fakat eklemek istediğim birkaç şey var. Gereksinimi gerçekten anladığınızdan emin olun. Kullanıcı gereksinimin X anlamına geldiğini düşündüğü ve programcının Y anlamına geldiğini düşündüğü zaman birçok hata gördüm. Hepimiz içeri girip kodlamayı sevdiğimizi biliyorum, ancak ön plana daha fazla zaman ayırıp anlayışı sağlamak, daha az yeniden işlem ve hata düzeltmesi olacak.

Desteklediğiniz işi yakından tanıyın, çoğu zaman eksik ya da daha sonra açıklamaya ihtiyaç duyan gereksinimlerde gereksinimleri görürsünüz. Y görevini belirtildiği gibi yaparsanız, mevcut Z özelliğini kıracağını unutmayın.

Veritabanı yapınızı anlayın. Birçok hata, sözdizimsel olarak doğru olan ancak yanlış sonuç veren bir sorgunun sonucudur. Sonuçlarınızın 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 üzere her zaman bir teknik uzmanım olur, kaçınılmaz olarak kaçırdığım verilerde bir şey görürler. Sonra kendinize ne yakaladıklarını not edin ve bir dahaki sefere simliar yaptığınızı hatırlayın.

Bence en önemli teknik zaman ayırmak . 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ün içinde kodlamanız için zorlarsa ... kodunuz daha fazla hatayla karşılanacaktır.

Bir süre önce okuduğum kitaplardan biri, kırık pencerelerle yaşamanız gerektiğini söyledi , çünkü insanlar bir başka kahvenin kırılmasını önemsemezler ... Kodlama aynıdır, herkes kötü bir şey yapan ilk kişi olmayı umursar ama hızlı , ama hiçbiri bir sürü cehennem kodunu , çok fazla hatayı ve çok zayıf tasarım ve stili önemser .

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

ReSharper veya IDE'ler gibi IntelliJ IDEA gibi kod inceleme araçlarını kullanın ; örneğin "yazılan, ancak hiçbir zaman okumayan" değişkenleri işaret ederek, kopyala ve yapıştır hataları hakkında uyar. Bana çok zaman kazandırdı.

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

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

• Değişmezliği tercih edin. (Finali / salt okunur şekilde kullanın.) Sahip olduğunuz az değişken durum ne kadar azsa yanlış gidebilir.

• Erken optimize etmeyin. Pek çok programcı performans kaygıları ile tarafını takip eder, gereksiz yere kodlarını değiştirmelerine neden olur ve performansın bir sorun olup olmayacağını önceden bilmeden tasarımlarını bastardi. İlk olarak, yazılım ürününüzü akademik şekilde inşa edin, performansı göz ardı edin; sonra kötü performans gösterip göstermediğine bakın; (Muhtemelen olmaz.) Herhangi bir performans sorunu varsa, git ürününüzün kod kodunuzun tamamını değiştirmek ve kırmak yerine performans gereksinimlerini karşılamasını sağlayacak güzel ve resmi algoritmik optimizasyonlar sağlayabileceğiniz bir veya iki yeri bulun. Burada ve orada saat döngülerini sıkın.