Sıfır hata programcısı nasıl olunur?

Hiç kod yazmayın.

Sıfır hata programcısı olmanın tek yolu budur.

Hatalar kaçınılmaz çünkü programcılar insan, yapabileceğimiz tek şey onları önlemek, bir hata oluştuğunda hızlı tepki vermek, hatalarımızdan ders almak ve güncel kalmak.

Önemsiz bir program için sıfır hata imkansızdır.

Çok yakınlaşmak mümkün, ancak verimlilik azalıyor. Ve sadece bazı yüksek riskli yazılımlar için faydalıdır. Space Shuttle yazılımı aklıma geliyor. Ancak üretkenlikleri günde birkaç satırlık sıradadır. Patronunuzun bunu istediğinden şüpheliyim.

Bu yazılım hatasızdır. Mükemmel, insanlar elde ettiği kadar mükemmel. Şu istatistikleri göz önünde bulundurun: Programın son üç sürümü - her biri 420.000 satır uzunluğunda - her birinde yalnızca bir hata vardı. Bu yazılımın son 11 sürümünde toplam 17 hata vardı.

Mekiğin Global Konumlandırma Uyduları, programın sadece% 1.5'ini içeren bir değişiklik veya 6.366 satır kod ile gezinmesine izin vermek için yazılımı yükseltin. Bu değişikliğin özellikleri, bir telefon rehberinden daha kalın bir cilt olan 2.500 sayfa çalıştırır. Mevcut programın teknik özellikleri 30 cilt doldurur ve 40.000 sayfa çalıştırır.

"Sıfır hata programcısı" sessiz bir şarkıcı gibi bir oksimorondur, ancak 60 yıl kadar süren programlama, sizi daha iyi bir programcı yapacak olan bazı damıtılmış bilgelik parçaları üretti:

• Mütevazi olun - hatalar yapıyorsunuz ve yapacaksınız. Defalarca.
• Kafatasınızın sınırlı boyutunun tamamen farkında olun. Göreve tam tevazu ile yaklaşın ve veba gibi akıllı hilelerden kaçının. [Edsger Dijkstra]
• Dövüş kombinasyonel patlama
• Değişken durumdan kurtulun (mümkün olan yerlerde). Evet, fonksiyonel programlamayı öğrenin.
• Olası kod yolu sayısını azaltın
• Giriş ve çıkış boşluklarının (işlevlerinizin) boyutunu (büyüklüğünü) anlayın ve% 100 test kapsamına yaklaşmak için bunları azaltmaya çalışın
• Her zaman kodunuzun çalışmadığını varsayın - aksi halde kanıtlayın!

TDD

TDD'nin amacı, bu kod satırını gerektiren bir test yoksa, tek bir kod satırı yazmamanızdır. Ve onu aşırıya çıkarmak için, her zaman bir kabul testi yazarak yeni bir özellik geliştirmeye başlarsınız. Burada salatalık stil testleri yazmanın ideal olduğunu buldum.

TDD yaklaşımı en az iki fayda sağlar.

• Tüm kod belirli bir özelliği çözmek için yazılmıştır, bu nedenle gereksiz fazla üretim yoktur.
• Mevcut bir kod satırını her değiştirdiğinizde, bir özelliği bozarsanız size bildirilir

Sıfır hata olduğunu kanıtlamaz, çünkü bu imkansız olacaktır (sayısız diğer cevaplarla zaten belirtilmiştir). Ancak TDD'yi öğrendikten ve iyi hale geldikten sonra (evet, aynı zamanda pratiğe ihtiyaç duyan bir beceridir), kendi koduma çok daha fazla güveniyorum, çünkü iyice test edildi. Ve daha da önemlisi, işlevselliği kırma konusunda endişelenmeden tamamen anlamadığım mevcut kodu değiştirebilirim.

Ancak TDD size hiç yardımcı olmuyor. Sistemin mimarisini ve bu mimarinin tuzaklarını tam olarak anlamadıysanız, hatasız kod yazamazsınız. Örneğin. aynı anda birden fazla isteği işleyen bir web uygulaması yazıyorsanız, birden fazla istek arasında değiştirilebilir verileri paylaşamayacağınızı bilmelisiniz (performansı artırmak için değiştirilebilir verileri önbelleğe almak için acemi tuzağına düşmeyin).

TDD'de iyi olan geliştirme ekiplerinin kodu en az kusurla teslim ettiğine inanıyorum.

Mesele şu ki, hatalar tanımadığınız şeylerdir. Programlama dili/derleyici ve uygulamanızın çalışacağı tüm ortamlar hakkında bir tür ansiklopedik bilgi sahibi olmadığınız sürece, gerçekten% 100 hatasız kod üretmeyi bekleyemezsiniz.

Hata sayınızı birçok testle azaltabilirsiniz, ancak sonunda muhtemelen hesaba katılmayacak bazı saçaklar olacaktır. Joel Spolsky, bug-fixing üzerine güzel bir makale yazdı.

Evet, kodunuzda hiçbir zaman hata olması imkansızdır, ancak daha az hata olması imkansız değildir. "Bu aptal, her zaman böcek olacak" tutumu sadece kod bir hata sayısını önlemek için bir polis dışarı. Kimse mükemmel değil ama daha iyi olmak için çaba gösterebiliriz. Kendi geliştirme çabalarımda aşağıdaki noktaları yararlı buldum.

• Bu kolay değil. Gece boyunca düzelmezsiniz. Bu yüzden cesaretiniz kırılmasın ve pes etmeyin.
• Daha az yazın ve daha akıllı yazın. Daha az kod genellikle daha iyi koddur. Önceden plan yapmak ve harika tasarım desenleri yapmaya çalışmak doğaldır, ancak uzun vadede sadece ihtiyacınız olanı yazmak zaman kazandırır ve hataları önler.
• Karmaşıklık düşmandır. Belirsiz karmaşık bir karmaşa varsa daha az sayılmaz. Kod golf eğlenceli ama anlamak için cehennem ve hata ayıklamak için daha kötü bir cehennem. Karmaşık bir kod yazdığınızda, kendinizi bir problemler dünyasına açarsınız. İşleri basit ve kısa tutun.
• Karmaşıklık özneldir. Daha iyi bir programcı olduktan sonra karmaşık olan kod basitleşir.
• Deneyim önemlidir. Daha iyi bir programcı olmanın iki yolundan biri pratik yapmaktır. Alıştırma, nasıl yazacağınızı bildiğiniz programları yazmak DEĞİLDİR, biraz acı veren ve düşünmenizi sağlayan programlar yazmaktır.
• Daha iyi olmanın diğer yolu okumaktır. Programlamada öğrenilmesi gereken çok sayıda zor konu vardır, ancak bunları sadece programlama yoluyla öğrenemezsiniz, bunları incelemeniz gerekir. Zor şeyleri okumalısın. Güvenlik ve eşzamanlılık gibi şeyler, felaketleri temizleyerek öğrenmek istemiyorsanız, sadece kod yazarak doğru bir şekilde öğrenmek imkansızdır. Bana inanmıyorsanız gawker gibi epik güvenlik sorunlarına bakın. Eğer güvenliğin nasıl doğru bir şekilde yapılacağını öğrenmek için zaman ayırırlarsa ve sadece bu karışıklığı işe yaramaz bir şey yapmakla kalmazlardı.
• Blogları okuyun. Orada size bakmak ve programlama hakkında düşünmek için yeni ve ilginç yollar verecek bir sürü ilginç bloglar var ...
• Kirli ayrıntıları öğrenin. Dilinizin ve uygulamanızın belirsiz bölümlerinin nasıl çalıştığının küçük ayrıntıları çok önemlidir. Karmaşık kod yazmaktan kaçınmanıza yardımcı olan sırlar tutabilirler veya kaçınmanız gereken kendi hatalarına sahip parçalar olabilirler.
• Kullanıcıların nasıl düşündüklerini öğrenin. Bazen kullanıcılarınız delirir ve uygulamanızla anlamadığınız ve tahmin edemeyeceğiniz şekillerde çalışır. Deneyebilecekleri yabancı şeyleri bilmek ve uygulamanızın işleyebileceğinden emin olmak için kafalarına girmeniz gerekir.

Sıfır hata mı? Kulağa LISP'ye ihtiyacınız var (şüpheci yolu takip edin ve müzik videosundan kaçının) gibi geliyor.

Ana kodlama ortamlarında (Java, C #, PHP, vb.) Hatasız kod elde etmek oldukça zordur. Kısa kontrol yinelemelerinde iyi test edilmiş ve hakemli kod üretilmesine odaklanacağım.

Kodu olabildiğince basit tutmak hataları önlemenize yardımcı olacaktır.

kod analiz araçları ( FindBugs , PMD ve benzeri kullandığınızdan emin olun. üzerinde) - sıkı derleyici uyarılarıyla birlikte - kodunuzla ilgili her türlü sorunu ortaya çıkaracaktır. Size söylediklerini not edin, hatanın doğasının ne olduğunu gerçekten anlamaya çalışın ve daha sonra programlama deyiminizi değiştirmek için adımlar atın, böylece bu hatayı tekrar tanıtan bir şekilde kodlamak doğal değildir.

Şahsen ben hatasız programlama için çaba (pahalı zaman ve para) gibi görünüyor düşünüyorum. Sıfır hataya, hatta sıfıra yakın bir hataya ulaşmak için, geliştiricilerin kapsamlı bir şekilde test etmeleri gerekir. Bu, yama incelemesi için herhangi bir kod göndermeden önce her şeyi regresyon testi anlamına gelir. Bu model bana uygun maliyetli değil. Geliştiricilerin gereken özenli testleri yapmasını ve derinlemesine testi KG ekibine bırakmasını sağlamanız daha iyi olur. İşte nedeni:

• Geliştiriciler teste tabi tutulur. Bu doğru ve biliyorsun. (Ben bir geliştiriciyim!) İyi bir KG ekibi, geliştiricilerin asla düşünmediği Edge vakalarını her zaman bulur.
• Geliştiriciler kodlamada iyidir. Excel'de ne olduklarına (ve genellikle ne yapmayı tercih ettiklerine) geri dönmelerine izin verin.
• KG ekibi, tek geçişte birden çok geliştirici göreviyle ilgili hataları bulabilir.

Kod yazarken, buna karşı kaydedilen hataların olacağını kabul edin. Bu nedenle bir KG süreciniz var ve bunların hepsi geliştirici olmanın bir parçası. Tabii ki bu, son noktalı virgülünüzü yazar yazmaz bir şey gönderdiğiniz anlamına gelmez. Hala işinizde kaliteyi sağlamanız gerekiyor, ancak can aşırıya kaçıyorsunuz.

Akran incelemesi ve/veya test yapmadan görevlerini her zaman doğru şekilde yapan kaç meslek adlandırabilirsiniz?

Tüm "Kod yazma." cevaplar tamamen eksik. Ayrıca, patronunuz kesinlikle bir salak gibi görünmüyor!

Kodlarının ne yaptığını bilmeyen programcıları ne sıklıkta gördüğümü hatırlayamıyorum. Onların tek geliştirme felsefesi deneme yanılma gibi görünüyordu (ve çoğu zaman aynı zamanda kopyala/yapıştır/değiştir). Deneme ve yanılma bazı sorunların üstesinden gelmek için geçerli bir yol olsa da, genellikle sorun etki alanını analiz edebilir ve kullandığınız araçları anlamanıza ve biraz disiplin ve titizlikle çok özel bir çözüm uygulayabilirsiniz. ilk kez dağıtmadan önce yalnızca sorunu çözdü, ancak çoğu köşe vakası (potansiyel hatalar). Kodun hatasız olduğunu garanti edebilir misiniz? Tabii ki değil. Ancak karşılaştığınız veya okuduğunuz her hata ile, bir dahaki sefere yazarken/değiştirdiğinizde düşünmek isteyebileceğiniz şeylere ekleyebilirsiniz. Bunu yaparsanız, sonuç olarak neredeyse hatasız kod yazma konusunda çok fazla deneyim kazanacaksınız. - Yolculukta size yardımcı olabilecek daha iyi bir programcı olmak için tonlarca kaynak var ...

Şahsen, her bir satırı açıklayamadığım bir yerde asla kod işlemezdim. Her satırın orada olması için bir nedeni vardır, aksi takdirde kaldırılmalıdır. Tabii ki bazen, çağırdığınız yöntemlerin iç işleyişini varsayarsınız, aksi takdirde tüm çerçevenin iç mantığını bilmeniz gerekir.

Patronunuz, yazdığınız kodun mevcut sistem üzerindeki sonuçlarını ve etkilerini anlamanız gerektiğini söylemekte tamamen haklıdır. Böcekler meydana gelecek mi? Evet tabi ki. Ancak bu hatalar, çalıştığınız sistemi/araçları tam olarak anlamamanızdan kaynaklanacak ve her hata düzeltmesiyle daha iyi kapsama alanına sahip olacaksınız.

Diğer yorumların zaten doğru şekilde işaret ettiği gibi, hatalar olmadan önemsiz bir yazılım yoktur.

Yazılımı her zaman aklınızda bulundurmak istiyorsanız, bu testler sadece hataların varlığını değil, hataların varlığını kanıtlayabilir.

Çalışma alanınıza bağlı olarak, yazılımınızın resmi olarak doğrulanmasını deneyebilirsiniz. Resmi yöntemleri kullanarak, yazılımınızın spesifikasyona tam olarak uyduğundan emin olabilirsiniz.

Bu elbette yazılımın tam olarak ne istediğinizi yaptığı anlamına gelmez. Tam bir spesifikasyon yazmak neredeyse tüm durumlarda mümkün değildir. Temelde hataların oluşabileceği yeri uygulamadan spesifikasyona kaydırır.

Yani "hata" tanımınıza bağlı olarak, resmi doğrulamayı deneyebilir veya yazılımınızda olabildiğince çok hata bulmaya çalışabilirsiniz.

Ya "Merhaba Dünya!" Dan daha karmaşık bir şey yazmayın. veya herkese asla kullanmamasını söylerseniz.

Patronunuzdan bu ücretsiz kod adı verilen bazı örnekleri isteyin.

Diğerlerine katılıyorum. Soruna nasıl yaklaşacağım

• Test cihazı edinin. Nedeni için Joel Testine bakınız.
• Kütüphaneleri yaygın olarak kullanın; muhtemelen daha iyi hata ayıklanmıştır. Ben Perl için büyük bir CPAN hayranıyım.

Sıfır hata programcısı olmaya çalışabilirsiniz. Kod yazarken sıfır hata programcısı olmaya çalışıyorum. Ancak ben

• birden fazla test tekniği (ATDD)
• yazılımımızın resmi doğrulamasını oluşturmak
• ayrı bir KG ekibine sahip olmak
• kod tabanında yapılan her değişiklik için sert analizler yapın
• güvenlik ve ikazlara daha fazla eğilen bir dil kullanın

Bunları yapmıyorum çünkü yazdığım yazılım için maliyet engelleyici. Bu şeyleri yapsaydım muhtemelen sıfır hataya karşı daha fazla olurdum, ama iş anlamında olmazdı.

Altyapımızın büyük bir kısmının kullandığı dahili araçlar oluşturuyorum. Test ve kodlama standartlarım yüksek. Ancak bir denge var. Sıfır hata beklemiyorum çünkü insanların bu tür zamanları tek bir işin içine sokmasını sağlayamıyorum. Bir X-Ray makinesini, jet motorlarını, vb. Kontrol etmek için yazılım oluşturuyor olsaydım işler farklı olabilir. Yazılımım bozulursa hayat yok, bu nedenle bu güvence düzeyine girmiyoruz.

Güvence düzeyini, yazılımın kullanım amacıyla eşleştirirdim. NASA mekiğinin kullanacağı kod yazıyorsanız, sıfır hata toleransı makul olabilir. Sadece bir sürü ek ve çok pahalı uygulama eklemeniz gerekir.

Bence bir "sıfır hata" programcı olmak için iyi bir ilk adım hatalara karşı tutum değiştirmek olduğunu. "Olurlar", "daha iyi KG ve testçiler edinin" veya "geliştiriciler teste tabi tutulur" demek yerine şunları söylüyor:

Hatalar kabul edilemez ve bunları ortadan kaldırmak için elimden gelen her şeyi yapacağım.

Bu sizin tutumunuz haline geldiğinde, hatalar hızla düşecektir. Aramanızda hataları ortadan kaldırmanın yollarını bulmak için test odaklı geliştirme ile karşılaşacaksınız. Daha iyi teknikler hakkında ücretsiz tavsiyeler sunan çok sayıda kitap, blog yayını ve kişi bulacaksınız. ygulama (katas kodlama veya evde yeni şeyler denemek gibi) yoluyla becerilerinizi geliştirmenin önemini göreceksiniz. İşyerinde daha iyi performans göstermeye başlayacaksınız, çünkü zanaatınız üzerinde çalışmaya başlayacaksınız evde. Ve umarım, gördüğünüzde is iyi bir yazılım yazmak mümkündür zanaatınıza olan tutkunuz artacak.

Bir bakıma patronunuz haklı. Sıfır hataya yaklaşan bir yazılım yazmak mümkündür.

Ama sorun şu ki, (neredeyse) sıfır hata programları yazma maliyetyasak yüksek olmasıdır. Gibi şeyler yapmanız gerekir:

• Gereksinimlerinizin resmi özelliklerini kullanın. Biçimsel, Z veya VDM veya diğer bazı matematiksel ses gösterimi kullanımında olduğu gibi.

• Programınızın belirtimi uyguladığını resmi olarak kanıtlamak için teorem kanıtlama tekniklerini kullanın.

• Hataların her bir yolunu test etmek için kapsamlı birim, regresyon ve sistem test paketleri ve koşum takımları oluşturun. (Ve bu kendi başına yeterli değildir.)

• birçok kişi (resmi ve gayri resmi), yazılım (ve kanıtlar) gereksinimleri gözden geçirin. testler ve dağıtımlar.

Patronunuzun tüm bunları ödemeye hazır olması veya hepsini yapmak için gereken zamana katlanması son derece düşük bir ihtimaldir.

"Sıfır hata" statüsüne ulaştım. Kullanıcılarıma bunun belgelenmemiş bir özellik olduğunu söylüyorum, ya da yeni bir özellik istiyorlar ve bu nedenle bir geliştirme. Bunların hiçbiri kabul edilen yanıtlar değilse, sadece kendi gereksinimlerini anlamadıklarını söylüyorum. Böylece, hiçbir hata yoktur. Programcılar mükemmel.

İşte bir hata ücretsiz program yapmak için adımlar:

1. İşlevselliğiniz için UNAMBIGUOUS SPECIFICATIONS değilseniz asla kodlamaya başlamayın.
2. TEST ETMEYİN ya da yazılımdaki hataları yakalamak için TEST ETMEYİNİZ.
3. Test, gözden geçirme ve üretim sırasında bulunan kusurlardan tüm geri bildirimleri, ilk aşamada kusur ekleyen bir sürece ve geliştiricilere uygulayın. Kusurlar bulunur bulunmaz tüm arızalı bileşenleri tamamen atın. Kontrol listelerinizi güncelleyin ve geliştiricilerinizi tekrar böyle hata yapmamaları için yeniden eğitin.

Test yalnızca hataların olduğunu kanıtlayabilir, ancak bunun aksini kanıtlamak genellikle işe yaramaz. Geri bildirim ile ilgili olarak - madeni para yapan madeni para yapma makineniz varsa ve her 10 saniyede bir madeni paraların bir kusuru vardır. Bu madeni parayı alabilir, düzeltebilir ve tekrar makineye yerleştirebilirsiniz. geri dönüştürülmüş boş olan madeni para o kadar iyi değil, belki kabul edilebilir. her 100'lük madeni paraların 2 kez yeniden damgalanması gerekir. Makineyi tamir etmek daha kolay olur mu?

Ne yazık ki insanlar makine değil. İyi, hatasız bir programcı yapmak için çok fazla zaman harcamanız, eğitim almanız ve yaptığınız her kusur için yineleme yapmanız gerekir. Geliştiricilerin pratikte öğrenmesi ve uygulaması genellikle zor olan resmi doğrulama yöntemleri konusunda eğitilmesi gerekir. Yazılım geliştirme ekonomisi de buna karşı çalışıyor - sadece başka bir işverene atladığını görmek için daha az kusur yaratabilecek bir programcıyı eğitmeye 2 yıl mı yatırım yapacaksınız? Mükemmel paralar yapan makine satın alabilir veya aynı maliyetle bir sürü test oluşturmak için 10 kod daha maymun kiralayabilirsiniz. Bu kapsamlı süreci "makineniz" olarak algılayabilirsiniz, varlığınız - mükemmel geliştiricilerin kapsamlı eğitimine yatırım yapmak işe yaramaz.

Çok yakında, kabul edilebilir kalitede yazılım geliştirmeyi öğreneceksiniz, ancak muhtemelen yavaş olduğu için mükemmel kod üreten geliştirici için pazar bulunmadığı için basit bir nedenle ücretsiz olan biri olmayacaksınız.

Eğer büyük yazılım evlerini varsayarsak birinci sınıf geliştiricileri nasıl alacağımızı bilirsek ( sıfır hata programcısı ) Microsoft yazılımının olması gerekir hatalar olmadan düşebiliriz. Yine de bunun gerçek olmaktan uzak olduğunu biliyoruz.

Yazılımlarını geliştirmek ve düşük öncelikli hataların belirli bir seviyesine ulaştıklarında ürünü serbest bırakırlar ve daha sonra çözerler.

Basit bir hesap makinesinden daha karmaşık bir şey geliştirmediğiniz sürece, hataları hep birlikte önlemek mümkün değildir. Cehennem NASA bile araçlarında ve böceklerinde yedekliliğe sahiptir. Her ne kadar yıkıcı arızalardan kaçınmak için çok sıkı testlere sahip olsalar da. Ancak yine de yazılımlarında hatalar var.

Hatalar kaçınılmazdır tıpkı insan doğasının err olması gibi.

Hiçbir hataya sahip olmak,% 100 güvenli bir sisteme sahip olmak gibidir. Bir sistem% 100 güvenliyse, artık kesinlikle yararlı değildir (muhtemelen ton ve ton betonun içinde yer alır ve dışarıya hiç bağlanmaz. Kablolu veya kablosuz değil. , karmaşık hatasız bir sistem yoktur.

Savunmacı bir program: http://en.wikipedia.org/wiki/Defensive_programming

Birisi defansif programlama kurallarına uyarsa, değişiklikler kolayca izlenebilir. Bunu geliştirme sırasında titiz hata raporları ve doxygen gibi sağlam belgelerle birleştirin ve tüm kodunuzun ne yaptığını tam olarak bilmeli ve ortaya çıkan hataları çok verimli bir şekilde düzeltebilmelisiniz.

Bu, sadece genel bir yönlendirme değil, iyi bir metodolojinin yanlış anlaşılmasının bir sonucu olabilir mi?

Demek istediğim, patronunuzun "sıfır hata metodolojisi" (bkz. Bölüm 5) 'i duyması ve bunun ne anlama geldiğini anlama zahmetine girmemesi mümkün mü?
Tabii ki, yönetimin yeni özelliklerin gelişimini ertelemesi, size koymaması gereken hatalar lehine ...
Ve elbette, bu onun bonusunu tehdit ediyor, bu yüzden elbette bir tane almayacaksınız çünkü "iyi programcıların hataları yok" ...

hata yapmak bunları ((= === -) bulabildiğiniz sürece ve bunları düzeltin (tabii ki, tabii ki).

Yazılım testinin temel kavramlarından biri, programın mükemmel olduğundan ASLA kesinlikle emin olamayacağınızdır. Sonsuza kadar doğrulayabilirsiniz, ancak bu programın tamamlandığını asla kanıtlamaz, çünkü tüm giriş/değişken kombinasyonlarına karşı test etmek bile hızlı bir şekilde mümkün olmaz.

Patronunuz "sadece yazdığı için programlama hakkında çok zor olanları anlamayanlardan" biri gibi görünüyor