Sıfır hata programcısı nasıl olunur? [kapalı]


168

Patronum bana her zaman iyi bir programcının, değiştirdiği kodun güvenilir, doğru ve tamamen doğrulanmış olduğunu doğrulayabilmesi gerektiğini söylemiştir; tüm sonuçları tamamen anlamanız ve değişikliklerin neden olacağı etkileri anlamanız gerekir. Bu tür bir programcı olmak için elimden gelenin en iyisini yapmaya çalıştım - tekrar tekrar test ederek - ancak böcekler hala orada.

Sıfır hata programcısı nasıl olabilirim ve kodumun her karakterinin neye yol açacağını ve etkileyeceğini nasıl bilebilirim?


Benim dışımda hiç kimse aslında ilk seferinde mükemmel kod yaratmaz. Ama benden sadece bir tane var. - Teknik Konuşma: Linus Torvalds git, Google, 15 Ağustos 2007 izquotes.com/quote/273558
JensG


0-bug programlama diye bir şey yoktur. Nedenini anlamak için matematikçi Godel'i okuyun.
Michael Martinez,

Yanıtlar:


365

Hiç kod yazmayın.

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

Hatalar kaçınılmazdır çünkü programcılar insandır, tek yapmamız gereken onları önlemek için elimizden gelenin en iyisini yapmak, bir hata oluştuğunda hızlı bir şekilde tepki vermek, hatalarımızdan ders almak ve güncel kalmaktır.


73
+1 Takip: Ya da kodlama yapmayan (fildişi kule) bir mimar olabilir ve yine de çok para kazanabilirsiniz! Bu en iyisi.
Martin Wickman,

26
Hata yapmak insandır, böceklerinizi ilahi olarak düzeltmek için.
Ward Muylaert,

11
Patron tarafından tercih edilen bir iş arkadaşım vardı, çünkü sürekli küçük bir böcek sayısına sahipti. Nasıl yaptı? Basit, başkasına istemediği böcekleri atadı ve her zaman en kolay / en küçük özellikleri kullandı.
toby

46
Kimin ilk söylediğini bilmiyorum ama, "Eğer hata ayıklama hataları gidermeye yönelik bir işlemse, programlama onları içine sokma süreci olmalıdır."
Bruce Alderman,

8
Daha da iyisi: bir patron olmak ve herhangi bir şeyin sorumluluğunu almak zorunda kalmadan iç çamaşırınızın perişan hissetmesini sağlayın.
biziclop

124

Önemsiz olmayan bir program için sıfır hata mümkün değildir.

Çok yaklaşmak mümkün, ancak üretkenlik acı çekiyor. Ve sadece bazı yüksek riskli yazılımlar için faydalı olacaktır. Uzay Mekiği programı aklıma geliyor. Ancak üretkenlikleri günde birkaç satırlık bir düzendedir. Patronunun bunu istediğinden şüpheliyim.

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

Mekiğin, programın yalnızca% 1,5'ini veya 6,366 kod satırını içeren bir Global Konumlandırma Uydularında gezinmesine izin vermek için yazılımı yükseltin. Bu değişikliğin teknik özellikleri, bir telefon rehberinden daha kalın olan 2.500 sayfadır. Mevcut programın teknik özellikleri 30 cilt dolduruyor ve 40.000 sayfa yayınlıyor.


3
İmkansız değil. Ama pek olası değil.
Billy ONeal,

36
FB'nin hatasız olduğunu düşündüren nedir? Facebook'un güvenlik ve gizlilik modeli büyük bir hatadır. Örneğin, Facebook patronları Facebook hesabı güvenlik zayıflıkları nedeniyle geçen hafta saldırıya uğradı.
Stephen C

6
@Elaine Facebook'un felsefesi "hızlı git ve bir şeyleri kır " ( geek.com/articles/news/… ) ve sayısız böcek yaşadım ( facebook.com/board.php?uid=74769995908 ) kendime Twitter farklı değildir, sık sık aşağı olduğu bilinir ( engineering.twitter.com/2010/02/anatomy-of-whale.html ) ve "takip böceği" ( status.twitter.com/post/587210796/…) ).
Yevgeniy Brikman

9
Hareketli hedefleri unutma. PerfectProgram 1.0'daki bir özellik 2.0'da hata olabilir
Carlos

4
@CodesInChaos: teori diyor orada var onların davranışlarını kanıtlamak mümkün olduğu programlar. Tüm programların davranışını kanıtlamanın imkansız olduğu söylenemez . Ortak programların çoğunun kanıtlanabilir tipte olduğunu ve “Kodumun durma sorunu nedeniyle hatasız olması imkansız” olduğunu iddia ederek teorinin yanlış bir uygulama olduğunu tahmin ediyorum.
endolith

98

"Sıfır hata programcısı" sessiz bir şarkıcı gibi bir oksimorondur, ancak 60 yıldan fazla bir süredir devam eden programlama, sizi daha iyi bir programcı yapacak damıtılmış bilgelik parçaları üretmiştir:

  • Mütevazı olun - siz hata yapıyorsunuz ve yapacaksınız. Defalarca.
  • Kafatasınızın sınırlı büyüklüğünün tamamen farkında olun. Göreve alçakgönüllülükle yaklaşın ve veba gibi zekice numaralardan kaçının. [Edsger Dijkstra]
  • Kombinatoryal patlama ile mücadele
  • Değişken durumdan kurtulun (mümkün olduğunda). Evet, fonksiyonel programlamayı öğrenin.
  • Mümkün kod yollarının sayısını azaltın
  • Giriş ve çıkış alanlarının (işlevlerinizin) boyutunu (büyüklüğünü) anlayın ve% 100 test kapsamına daha da yaklaşmak için bunları azaltmaya çalışın
  • Her zaman kodunuzun çalışmadığını varsayalım - aksi takdirde kanıtlayın!

2
Kodumun çalıştığını kanıtlamaktan memnuniyet duyarım ... ama testler sadece çalışmadığını kanıtlayabilir. Resmi bir kanıt mı konuşuyorsunuz veya burada hata ayıklama görevini mi öngörüyorsunuz?
Matthieu M.

Bu konudaki ilk yararlı cevap. @Matthieu: İki baytın olası her bir birleşimi için, bir işlevin tekrar bir bayt olan doğru bir sonuç (örneğin: maks.) Döndüreceğini kanıtlayabilirsiniz. İki ve daha fazla bu tür fonksiyonlara sahip olabilirsiniz ve şimdi onları zincirleyebilir ve bu fonksiyonların çok sayıda olası kombinasyonunu elde edebilirsiniz, bu da bir daha bayt üretecektir. Yalnızca yanlış bir şeyi ispatlayabileceğiniz fikri yanlış. Popüler, ama yanlış.
kullanıcı bilinmeyen,

@Matthieu M .: Test, işlerin beklediğiniz gibi çalıştığını kanıtlar. Tüm öğelerin beklediğiniz gibi çalıştığını kanıtlayabilirseniz, oradan da beklediğiniz giriş davranışlarıyla uğraştığınızı kanıtlarsınız. Bu davranışın ne olduğunu ve ne olması gerektiğinin farkına vardıktan sonra, bunun için yeni bir test yazarsınız. Artık beklenen davranışınızın bir parçası.
deworde

1
@deworde: Test fikrini anlıyorum, ancak niş durumların yanı sıra, yaptığım gerçek işlerin çoğunluğu ayrıntılı bir şekilde test edilemedi, çünkü olası kombinasyonların sayısı çok büyüktü (ve ben bile eklemiyorum bile) zamanlama sorunları). Niş durumlarının yanı sıra, testler yalnızca şu ana kadar devam etti (en azından nominal durumun geçip
geçmediğini

"veba gibi zekice numaralardan kaçının" - bu tek başına bu iyi cevabı verirdi. Olduğu gibi - harika.
BЈовић

25

TDD

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

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

  • Tüm kodlar belirli bir özelliği çözmek için yazılmıştır, dolayısıyla gereksiz aşırı üretim yapılmaz.
  • Mevcut bir kod satırını her değiştirdiğinizde, bir özelliği ihlal ederseniz size bildirilir.

İmkansız hataları kanıtlamaz, çünkü bu imkansız olurdu (sayısız diğer cevaplar tarafından çoktan belirtilmiş). Ancak TDD'yi öğrendikten ve bu konuda iyi olduktan sonra (evet, aynı zamanda pratik gerektiren bir beceridir), kendi koduma çok daha fazla güveniyorum, çünkü tamamen test edildi. Ve daha da önemlisi, işlevselliği bozma endişesi olmadan tamamen anlamadığım mevcut kodu değiştirebiliyorum.

Ancak TDD size tümüyle 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şken verileri paylaşamayacağınızı bilmeniz gerekir (performansı artırmak için değişken verileri önbelleğe almak için acemi tuzağa düşmeyin).

TDD'de iyi olan geliştirme ekiplerinin en az kusurlu kodu verdiğine inanıyorum.


19

Şey hatalar sen şeyler, olduğu yok tanır. Programlama dili / derleyicisi ve uygulamanızın çalışacağı tüm ortamlar hakkında bir tür ansiklopedik bilgi sahibi olmadığınız sürece,% 100 hatasız kod üretmeyi gerçekten bekleyemezsiniz.

Hata sayınızı çok sayıda testle azaltabilirsiniz, ancak sonunda, hesaba katmayacağınız bir kaçak vakası olacak. Joel Spolsky özellikle hata düzeltme konusunda güzel bir makale yazdı .


1
+1. Twisted Sister sözleriyle, Bilmediğiniz şeyler size zarar verebilir / göremediğiniz şeyler sizi çığlık attırabilir.
Mühendis

17

Evet, kodunuzda asla hata olmaması imkansızdır, ancak daha az hata olması imkansız değildir. "Bu aptal, her zaman böcek olacak" tutumu, kodunuzdaki böcek sayısını azaltmaktan kaçınmak için sadece bir polistir. Kimse mükemmel değil, ama daha iyi olmak için çabalayabiliriz ve yapmalıyız. Kendi çabalarımı geliştirmek için aşağıdaki noktaları faydalı buldum.

  • Bu kolay değil. Gece boyunca iyileşmeyeceksin. Öyleyse cesaretini kırma ve pes etme.
  • Daha az yaz ve daha akıllıca yaz. 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. Daha az karmaşık bir karışıklık olursa, daha az sayılmaz. Kod golf eğlenceli ama anlamak cehennem ve hata ayıklamak için daha kötü bir cehennem. Ne zaman karmaşık bir kod yazsanız, kendinizi bir sorun dünyasına açıyorsunuz. Her şeyi basit ve kısa tut.
  • Karmaşıklık özneldir. Bir zamanlar karmaşık olan kod, daha iyi bir programcı olduğunuzda basitleşir.
  • Meseleleri tecrübe edin. Daha iyi bir programcı olmanın iki yolundan biri pratik yapmaktır. Pratik yapmak, kolay yazmayı bildiğiniz programları yazmak değil, biraz acı çeken ve sizi düşündüren programlar yazıyor.
  • Daha iyi olmanın diğer yolu okumaktır. Programlamanın öğrenmesi gereken çok fazla zor konu var ama bunları yalnızca programlayarak öğrenemezsiniz, onları incelemelisiniz. Sert şeyleri okumalısın. Güvenlik ve eşzamanlılık gibi şeyler felaketleri temizleyerek öğrenmek istemediğiniz sürece, sadece kod yazarak doğru şekilde öğrenmek imkansızdır. Bana inanmıyorsanız, gawker gibi sitelerin epik güvenlik sorunlarına göz atın. Güvenliği doğru yapmayı öğrenmek için zaman ayırırlarsa ve sadece işe yaramaz bir şey yapmazlardı.
  • Blogları oku. Size bakmak ve programlamayı düşünmek için yeni ve ilginç yollar verecek ilginç tonlarca blog var.
  • Kirli detayları öğren. Dilinizin ve uygulama çalışmanızın ne kadar belirsiz olduğu konusundaki küçük detaylar çok önemlidir. Karmaşık kod yazmaktan kaçınmanıza yardımcı olacak sırlar tutabilirler veya kaçınmanız gereken kendi hataları olan kısımlar olabilirler.
  • Kullanıcıların nasıl düşündüğünü öğrenin. Bazen kullanıcılarınız delirmişlerdir ve anlamadığınız ve tahmin edemediğiniz şekillerde uygulamanızla birlikte çalışacaktır. Deneyebilecekleri garip şeyleri öğrenecek ve uygulamanızın başa çıkabildiğinden emin olmak için kafalarına girmeniz gerekir.

8

Şahsen, hatasız programlama için çabalamanın daha pahalı olduğunu düşünüyorum (hem zaman hem de para olarak). Sıfır böceğe, hatta sıfıra yakın bir böceğe ulaşmak için, geliştiricilerin iyice test etmesi gerekir. Bu, yama incelemesi için herhangi bir kod göndermeden önce her şeyin regresyon testi olduğu anlamına gelir. Bu model beni düşük maliyetli olarak etkilemiyor. Geliştiricilerin özenli bir sınama çalışması yapması ve ayrıntılı sınamayı QA ekibine bırakması konusunda daha iyi olmanız. İşte nedeni:

  • Geliştiriciler test emmek. Bu doğru ve sen bunu biliyorsun. (Ben bir geliştiriciyim!) İyi bir KG ekibi, geliştiricilerin asla düşünmediği son durumları bulacaktır.
  • Geliştiriciler kodlama konusunda iyidir. Onların üstünlüklerine geri dönmelerine izin verin (ve genellikle yine de ne yapmayı tercih ettiklerini.)
  • KG ekibi, birden fazla geliştirici göreviyle ilgili hataları tek seferde bulabilir.

Kod yazdığınızda, buna karşı kaydedilen hataların olacağını kabul edin. Bu yüzden bir QA süreciniz var ve hepsi geliştirici olmanın bir parçası. Elbette bu, son yarı-kolonunuzu yazdığınız anda bir şey gönderdiğiniz anlamına gelmez. Hala çalışmalarında kalitesini sağlamak için gerekir, ancak olabilir aşırıya.

Meslektaş denetimi ve / veya sınavı olmadan işini her zaman doğru bir şekilde yapan kaç meslek adı verebilirsin?


8

Sıfır böcek mi? Lisp'e ihtiyacınız var gibi geliyor (şüpheci yolu izleyin ve müzik videosundan kaçının).

Ana kodlama ortamlarında (Java, C #, PHP, vb.) Hatasız kod elde etmek olağanüstü zordur. Kısa kontrollü yinelemelerde iyi test edilmiş ve hakemli kodlar üretmeye odaklanacağım .

Kodu olabildiğince basit tutmak, hataları önlemek için size yardımcı olacaktır.

Sıkı bir derleyici uyarıları ile birlikte - kodunuzla ilgili her türlü sorunu ortaya çıkaran kod analiz araçlarını ( FindBugs , PMD vb. Gibi) kullandığınızdan emin olun . Size ne söylediklerini not edin, gerçekten hatanın ne olduğunu anlamaya çalışın ve programlama deyiminizi değiştirmek için gerekli adımları izleyin, böylece bu hatayı tekrar tanıtan bir şekilde kodlamak doğal olmayacaktır.


3
Bazen böcekler orada yaşayan gizli canavarlar gibidir, tekrar tekrar test ettiğimde ve öz kod incelemem sırasında saklanırlar ... ama bir kez akran incelemesi yaptığımda, canavarların inanılmaz derecede görünür olduğunu ve aniden bana fırladığını gördüm. Bu gerçekten garip. Sadece insana bağlı 'göz' ve 'beyin' hatasız hatta dokunmak imkansız görünüyor. Ünite testi her durumda işe yaramaz. Kod analizi araçları? Kulağa heyecan verici geliyor, hiç kullanmadım, bu alanda araştırma yapacağım.
Elaine

Ada'ya ihtiyacın olduğunu söyleyebilirim ama Lisp daha eğlenceli. ;-)
Orbling

1
@Elaine Çalıştığım yer bir Java ortamıdır ve kod yalnızca Findbugs ve PMD'den geçtiğinde ekiple paylaşılabilir. Yeni ekip üyeleri beş aşamadan geçiyor: inkar, öfke, pazarlık, depresyon ve sonra kabul. Daha sonra asla arkasına bakmazlar.
Gary Rowe,

@Gary Rowe, bu reaksiyonları anlıyorum, lol, hiç QA borçlu bir şirkette bulundum, çalışanlar haftada her kod satırının kurallara uyup uymadığını görmek için o hafta üretilen tüm kodları kontrol etti. '(Findbugs / PMD gibi bazı araçları kullanıp kullanmadıkları hakkında hiçbir fikrim yok), ancak içinde bulunduğunuz adım gibi biraz geliyor.
Elaine

1
@Gary: Benden tartışma yok, ancak çalıştığım bazı yerler, stil ihlallerini böcek eşdeğeri olarak görüyor. Ve "her sınıfın paket ve sınıf isimlerini içeren CLS_PKG ve CLS_NAME statik alanlarını bildirmesi gerekir" gibi stil kurallarına sahip olma eğilimindeydiler. Kodlama standartlarını genel olarak desteklerim, ancak böyle şeylere geliştikleri zaman olmaz!
TMN

8

Tüm "Hiç kod yazmayın." cevaplar noktayı tamamen kaçırıyor. Ayrıca, patronun kesinlikle bir moron 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şimi philosohpy deneme yanılma gibi görünüyordu (ve ayrıca çoğu zaman kopyala / yapıştır / değiştir). Deneme ve yanılma, bazı sorunların giderilmesi için geçerli bir yol olsa da, genellikle sorun alanını analiz edebilir ve daha sonra kullandığınız araçları anladığınıza ve sahip olamayacağınız biraz disiplin ve titizlikle çok özel bir çözüm uygulayabilirsiniz. sadece sorunu değil, aynı zamanda ilk defa konuşlandırmadan önce çoğu köşe olayını (potansiyel hatalar) çözdü. Kodun hatasız olduğunu garanti eder misiniz? Tabii ki değil. Ancak karşılaştığınız veya okuduğunuz her hatada, bir dahaki sefere bir şeyler yazdığınızda / değiştirdiğinizde hakkında düşünmek isteyebileceğiniz şeyleri ekleyebilirsiniz. Bunu yaparsanız, sonuçta neredeyse hatasız olan kodun yazılması konusunda çok fazla deneyim kazanacaksınız. - Yolculukta size yardımcı olabilecek daha iyi bir programcı olmanın tonları vardır.

Şahsen, her bir satırı açıklayamadığım durumlarda asla kod işlemem. Her çizginin orada olması için bir nedeni vardır, aksi halde kaldırılmalıdır. Elbette bazen, çağırdığınız yöntemlerin içsel çalışmalarına dair varsayımlarda bulunursunuz, aksi takdirde tüm çerçevenin iç mantığını bilmeniz gerekir.

Patronunuz, varolan sistem üzerindeki yazdığınız kodun sonuçlarını ve sonuçlarını anlamanız gerektiğini söylemek konusunda tamamen haklı. Hatalar oluşacak mı? Evet tabi ki. Ancak bu hatalar, birlikte çalıştığınız sistemi / araçları tam olarak anlamanızdan kaynaklanacak ve her hata düzeltmesinde daha iyi bir kapsama alanı olacak.


“Karşılaştığınız veya okuduğunuz her hatayla, bir dahaki sefere bir şey yazdığınızda / değiştirdiğinizde hakkında düşünmek isteyebileceğiniz şeyleri ekleyebilirsiniz” bu harika bir nokta. Gördüğüm veya kodladığım hatalarla ilgili google dokümanı oluşturdum, sadece bu amaçla.
Ben,

7

Diğer yorumlar zaten doğru bir şekilde belirtildiği gibi, böcek içermeyen önemsiz bir yazılım yoktur.

Eğer yazılımı test etmek istiyorsanız, daima aklınızda bulundurun, testler onların yokluğunu değil, sadece böceklerin varlığını ispatlayabilir.

Çalışma alanınıza bağlı olarak, yazılımınızın resmi doğrulamasını deneyebilirsiniz. Resmi yöntemleri kullanarak, yazılımınızın spesifikasyonu tam olarak karşıladığından emin olabilirsiniz.

Elbette ki bu, yazılımın tam olarak istediğinizi yaptığı anlamına gelmez. Tam bir şartname yazmak hemen hemen her durumda da mümkün değildir. Temelde hataların oluşabileceği yeri uygulamadan şartnameye kaydırır.

Bu nedenle, "hata" tanımınıza bağlı olarak, resmi doğrulamayı deneyebilir veya yalnızca yazılımınızda bulabildiğiniz kadar hata bulmaya çalışabilirsiniz.


6

Ya "Merhaba Dünya!" Den daha karmaşık bir şey yazmayın. veya eğer herkese asla kullanmamasını söylersen.

Patronunuzdan, hatasız kod adı verilen bazı örnekler isteyin.


5

Diğerleriyle aynı fikirdeyim. İşte soruna nasıl yaklaşacağımı

  • Bir test cihazı al. Neden için Joel Testine bakınız.
  • Kütüphaneleri yaygın olarak kullanın; Muhtemelen daha iyi hata ayıklandı. Perl için büyük bir CPAN hayranıyım.

1
… Ama kütüphaneleri kullanıyorsanız, böceklerinin sizi aşağı sürükleyemeyeceğinden emin olun (örneğin, kaynağı bulundurarak denetleyebilir veya gerektiğinde kendiniz giderebilirsiniz).
millenomi

5

Sıfır hata programcısı olmak için çaba gösterebilirsiniz. Kod yazarken sıfır hata programcısı olmak için çabalıyorum. Ancak yapmam

  • çoklu test tekniklerini kullanmak (ATDD hariç)
  • Yazılımımızın resmi doğrulamasını oluşturun
  • ayrı bir QA ekibine sahip olmak
  • Kod bazında yapılan her değişiklik üzerinde sıkı analizler yapın
  • güvenlik ve dikkat için daha fazla eğimli bir dil kullanın

Bunları yapmıyorum çünkü yazdığım yazılım için maliyeti düşük. Bunları yapsaydım, muhtemelen sıfır hataya doğru ilerlerdim, ama iş anlamında olmazdı.

Altyapımızın büyük bir kısmının kullandığı iç aletler yaratıyorum. Test ve kodlama için standartlarım yüksek. Ancak, bir denge var. Sıfır böcek beklemiyorum, çünkü insanların böyle bir zamanı bir işe koymalarını sağlayamıyorum. Bir X-Ray makinesini, jet motorlarını vb. Kontrol etmek için bir yazılım yaratıyorsam, işler farklı olabilir. Yazılımım bozulursa hatta hiçbir hayat olmaz, bu yüzden bu güvence seviyesine girmeyiz.

Yazılımın kullanım amacı ile güvence seviyesini eşleştirirdim. NASA mekiğinin kullanacağı kod yazıyorsanız, belki sıfır hata toleransı makul olur. Sadece birkaç ek ve çok pahalı uygulama eklemeniz gerekiyor.


4

Sanırım "sıfır hata" programcısı olma yolunda ilk adım, hatalara karşı tutumunuzu değiştirmek. “Olurlar”, “daha ​​iyi KG ve test uzmanları olsun” veya “geliştiriciler testlerde emilir” demek yerine:

Hatalar kabul edilebilir değildir ve gücüm dahilinde onları ortadan kaldırmak için her şeyi yapacağım.

Bu sizin tavrınız haline geldiğinde, böcekler hızla düşecek. Aramanız, hataları ortadan kaldırmanın yollarını bulmak için teste dayalı geliştirme ile karşılaşacaksınız. Çok sayıda kitap, blog yazısı ve daha iyi teknikler hakkında ücretsiz danışmanlık hizmeti veren insanlar bulacaksınız. Becerilerinizi uygulama yoluyla geliştirmenin önemini göreceksiniz (kataları kodlamak veya evde yeni şeyler denemek gibi). İşyerinde daha iyi performans göstermeye başlayacaksınız çünkü zanaatınız için evde çalışmaya başlayacaksınız . Eğer o gördükten sonra Ve, ümit olan iyi yazılım yazmak mümkün, zanaat için tutku büyüyecektir.


2

Bir anlamda, patronun haklı. Sıfır hataya yaklaşan bir yazılım yazmak mümkündür.

Ancak sorun şu ki (neredeyse) sıfır-hata programları yazma maliyeti oldukça yüksektir . Gibi şeyler yapmanız gerekir:

  • Gereksinimlerinizin resmi özelliklerini kullanın. Formal, Z veya VDM veya diğer bazı matematiksel ses gösterimlerinde kullanıldığı gibi.

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

  • Her bir hatayı test etmek için kapsamlı ünite, regresyon ve sistem test takımları ve donanımları oluşturun. (Ve bu kendi içinde yeterli değil.)

  • birçok kişi (formel ve enformel) gereksinimlerini yazılım (ve deliller) gözden geçirin. sınamalar ve dağıtımlar.

Patronunun bütün bunların parasını ödemeye hazır olması ya da hepsini yapması için harcadığı zamanın son derece düşük olması muhtemel.


1

"Sıfır hata" durumuna ulaştım. Kullanıcılarıma bunun belgelenmemiş bir özellik olduğunu veya yeni bir özellik istediklerini ve bu nedenle bir geliştirme istediklerini söylüyorum. Bunlardan hiçbiri kabul görmüş cevaplar değilse, sadece kendi gereksinimlerini anlamadıklarını söylüyorum. Böylece, hiçbir hata yoktur. Programcılar mükemmel.


1

Hatasız program yapma adımları:

  1. İşlevselliğiniz için UNAMBIGUOUS ÖZELLİKLERİ yoksa asla kodlamaya başlamayın.
  2. TEST ETMEYİN veya veya yazılımdaki kusurları yakalamak için TEST ETMEYİN.
  3. Tüm FEEDBACK'i test, inceleme ve üretim sırasında ortaya çıkan kusurlardan bir prosesi ve ilk etapta kusur ekleyen geliştiricilere uygulayın. Kusur bulunur bulunmaz tüm kusurlu bileşenleri tamamen atın. Denetim listelerinizi güncelleyin ve geliştiricilerinizi yeniden eğitin, böylece bir daha böyle hatalar yapmazlar.

Testler sadece sizin hatalarınızın olduğunu kanıtlayabilir, ancak bunun aksini kanıtlamak genellikle işe yaramaz. Geri bildirim ile ilgili olarak - madeni para yapan para kazanma makineniz varsa ve her 10 madeni parada ortalama bir kusur vardır. Bu bozuk parayı alabilir, düzleştirebilir ve tekrar makineye yerleştirebilirsiniz. geri dönüştürülmüş boş yapılan para, kadar iyi değil, ama belki de kabul edilebilir olacaktır. Her 100'lü jeton 2 defa tekrar damgalanmalıdır. Makineyi tamir etmek daha kolay olur mu?

Maalesef insanlar makine değil. Kusursuz, hatasız bir programcı olmak için, çok fazla zaman harcamanız, yapılan her kusur üzerinde eğitim ve yineleme yapmanız gerekir. Geliştiricilerin, uygulamada öğrenmesi ve uygulaması genellikle zor olan resmi doğrulama yöntemleri konusunda eğitilmeleri gerekir. Yazılım geliştirme ekonomisi de buna karşı çalışıyor - sadece başka bir işverene atlamasını görmek için daha az hata yapan bir programcının eğitilmesine 2 yıl yatırım yapar mısınız? Mükemmel para kazandıran bir makine satın alabilir veya aynı maliyette testler oluşturmak için 10 tane daha kod maymunu 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 bir yazılım geliştirmeyi öğreneceksiniz, ancak muhtemelen yavaş olduğundan, mükemmel kod yapan geliştirici için hiçbir pazar bulunmadığı için basit bir nedenden ötürü asla özgür olamayacaksınız.


Belirsiz özelliklerden bahsetmek için +1. Bunun 2 yıllık bir konu olduğunu biliyorum, ancak bir hatanın bir programlama başarısızlığına eşit olduğunu varsaymanın yanlış olduğunu vurgulamanın tek cevabının sizin olduğunu vurgulamak zorundayım.
Brandon

0

Savunma programı: http://en.wikipedia.org/wiki/Defensive_programming

Birisi programlama kurallarını savunmaya uyarsa, değişiklikler kolayca takip edilebilir. Bunu geliştirme sırasındaki titiz hata raporları ve doxygen gibi katı belgelerle birleştirin ve tüm kodunuzun ne yaptığını tam olarak bilmeniz ve ortaya çıkan hataları çok etkin bir şekilde gidermeniz gerekir.


0

Bu , yalnızca genel bağılmanın değil, iyi bir metodolojinin yanlış anlaşılmasının bir sonucu olabilir mi?

Demek istediğim, patronunuzun "sıfır hata metodolojisi" ni duyması (bkz. Bölüm 5) ve bunun ne anlama geldiğini anlamadığı anlamına mı geliyor?
Yönetim böcek lehine, yeni özelliklerin geliştirilmesini erteleme için Tabii ki, bu rahatsız edici Eğer içinde ... koymak should not have
Ve tabii ki iyi programcıları yok" çünkü sen alışkanlık olsun tabii böylece, o, onun bonusu tehdit böcek var "...

Onları bulabildiğiniz ve düzeltebildiğiniz sürece (tabii ki, elbette) hata yapmak sorun değil .


0

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

Patronunuz "programlama konusunda neyin zor olduğunu anlamayan, sadece yazdığından beri" biri gibi görünüyor.


0

Büyük yazılım şirketlerinin, birinci sınıf geliştiricilerin ( sıfır hata programcısında olduğu gibi) nasıl elde edileceğini bildiğini varsayarsak , Microsoft'un yazılımının hata olmadan olması gerektiğine karar verebiliriz . Oysa bunun gerçeklerden uzak olduğunu biliyoruz.

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

Basit bir hesap makinesinden daha karmaşık bir şey geliştirmiyorsanız, hep birlikte hataları önlemek mümkün değildir. Cehennem NASA'nın araçlarında ve hatalarında da fazlalık var. Her ne kadar felaketle ilgili başarısızlıkları önlemek için çok sıkı testler yapmış olsalar da. Ancak yine de yazılımlarında hatalar var.

Hatalar tıpkı insan doğasında olduğu gibi kaçınılmazdır .

Hata olmaması,% 100 güvenli bir sisteme sahip olmak gibidir. Bir sistem% 100 güvenliyse, artık kesinlikle kullanışsızdır (muhtemelen tonlarca ve tonlarca betonun içinde uzanır ve dışarıya hiç bağlı değildir. Kablolu ya da kablosuz değildir. , karmaşık bir hatasız sistem yoktur.


-1

Sadece insan olduğumuz ve hataya yatkın olduğumuz hakkındaki cevapları görüyorum, bu çok doğru ... ama sorunuzu başka bir bakış açısıyla görüyorum.

Ne düşündüğünü olabilir hata içermeyen programlar yazmak, ancak bu genellikle zaten 10 veya 12 kez yazdım programlardır. Aynı programı sıfırdan yazdığınızda, nasıl yapılacağını zaten biliyorsunuz: problemi biliyorsunuz, teknikleri biliyorsunuz, kütüphaneleri, dili , zihninizi görüyorsunuz . Tüm modeller her seviyede var.

Bu bana çok basit programlarla oluyor çünkü programlamayı öğretiyorum. Onlar benim için basit ama öğrenciler için zor. Ve tahtada birçok kez yaptığım sorunların çözümlerinden bahsetmiyorum. Tabii ki bunları biliyorum. Gerçekten iyi bildiğim kavramları (öğretdiğim kavramları) kullanarak bir şeyi çözen ~ 300 hatlı programlar. Bu programları planlama yapmadan yazıyorum ve sadece çalışıyorlar ve tüm detayları bildiğimi hissediyorum, hiç TDD'ye ihtiyacım yok. Birkaç veya üç derleme hatası alıyorum (çoğunlukla yazım hataları ve benzeri şeyler) ve hepsi bu. Bunu küçük programlar için yapabilirim ve ayrıca bazı insanların daha karmaşık programlar için yapabileceğine inanıyorum. Bence Linus Torvalds veya Daniel J. Bernstein gibi insanlar zihnin bu kadar netliğine sahipler, hatasız bir kodlayıcıya en yakınlar. Eğer senderinlemesine şeyler anlamak , yapabileceğini düşünüyorum. Bunu sadece basit programlar için yapabilirim, dediğim gibi.

Benim inancım, daima seviyenizin çok üstünde olan programlar yapmaya çalışırsanız (yıllarca bunu yaptım), kafanız karışır ve hatalar yaparsınız. Sonunda problemi anladığınızda, çözümünüzün işe yaramayacağını aniden anladığınız gibi büyük hatalar ve probleminizi çözmekten alıkoyacak veya kodu berbat hale getirebilecek kadar karmaşık değişiklikler yapmak zorundasınız. TDD'nin bu durumlar için olduğuna inanıyorum. Başa çıkmakta olduğunuz sorunu aşmadığınızı biliyorsunuz ve bu nedenle güçlü bir temeliniz olduğundan emin olmak için her yere testler yaptınız. TDD, 10.000 fit'lik görüşü çözmüyor. Daima mükemmel temiz kodlarla çevrelerde yürüyebilirsiniz.

Bununla birlikte, yeni bir şey yapmaya çalışırsanız, ancak bu seviyenizin hemen üstünde ise , programınızı mükemmel veya neredeyse mükemmel hale getirebilirsiniz. Bence "bilgi sınırında" hangi programların olduğunu bilmek gerçekten zor, ama teoride öğrenmenin en iyi yolu bu. Aslında programları çok sıfırdan yeniden yazıyorum. Bazı insanlar bunu yapar, ancak çok fazla zamana ve sabra ihtiyacınız vardır, çünkü önemsiz olmayan bir programı üçüncü kez tekrarlarsanız, ilk kez olduğu gibi heyecanlanmazsınız.

Bu yüzden benim tavsiyem: sadece bu şey için hatasız bir program yazana kadar bir şey anladığınızı sanmayın. Ve daha sonra bildiğiniz bu iki kavramı derinlemesine aynı programda birleştirmeye çalışın. Neredeyse ilk seferinde doğru yapacağına eminim. En iyi yollardan biri, önemsiz olmayan yazılımı ilk kez çok fazla çaba harcayan bir şeyi yeniden yazmaktır (şu anda bunu Android uygulamaları ile yapıyorum). Her başladığımda bir şeyi değiştiriyorum ya da bir şeyler ekliyorum, sadece biraz eğlence eklemek için, ve daha iyi, daha iyi ve daha iyi olduğumu söyleyebilirim ... belki de hatasız değil ama gerçekten gurur duyuyorum.


-1

imho böcek ve ani, gizemli algoritma eserler olmalı onlar ilham ve kod evrimini zorlamak: kodlama işlemi sırasında görünür.
bununla birlikte (genellikle bazı testlerden sonra) bildirimden önce kullanılabilecek her değişkeni kontrol etmek, göründüğü her yerde her hatayı idare etmek - programı sıfır hata yapmak ... kabul edilen bir özellik için bir istek alana kadar mümkün program mimarisini tartışırken imkansız;)


1
Bilmiyorum - kulağa gayet mistik olmayan bir çalışma alanı olan programlamaya mistik bir yaklaşım gibi geliyor. Deneme ve yanılma yoluyla veya bir daldırma çubuğu kullanarak etkili bir şekilde programlamıyorsunuz. Sen bilerek dizayn ettin. Ve böcekler hala çoğalacak. Demek onları tamir ediyorsun. Ama her şeyden önce , kodunuzu kasıtlı olarak, böceklere sahip olmamak için tasarlayın .
Craig

-1

Belki de aldığınız böceklerin doğası hakkında daha fazla düşünün. Eğer böcekler genel olarak küçük denetimler ise, daha iyi testlere odaklanmak ve biraz kod prova okuması yardımcı olacaktır.

Hatalar en düşük programlama kararlarından kaynaklanıyorsa, o zaman belki daha iyi tasarıma daha fazla çaba sarf etmek gerekir. Bu durumda, yazılımın kalitesini yükseltmek için teste çok fazla bağımlı olmanın mümkün olduğunu düşünüyorum, çünkü eksik kodlara bir yama uygulamak gelecekteki bakımı daha karmaşık hale getirebilir. Bir yandan onları bulur ve düzeltirken daha az hata alırsınız, diğer yandan gelecekteki hatalar için zemin hazırlarsınız.

Gözetimde bir sorun veya tasarımla ilgili bir sorun yaşamanız durumunda karar vermenin bir yolu, hataları düzeltmek için ne kadar çaba gerektiğini düşünmek olabilir. Düzeltmeler büyük olma eğilimindeyse veya onları iyi anlamadığınızı hissediyorsanız, bu durum kodu tasarımda geliştirilebilecek olanı işaret eder.

Bence, uygulama ve inceleme ile geliştirebileceğiniz ve benzer sorunları olan insanlar hakkında okumak için kod hakkında bir tür güzel tadı var.

Sonuçta, hiç hata beklememek boşunadır, ancak zaten düşük bir seviyeye sahip olmadığınız sürece, böcek sayınızı azaltmaya çalışmanın zararı yoktur; yakalayamadığın böcekler.


-2

Demek istediğim: "kodu yazarken sıfır hata" -> bu güzel bir amaç ama oldukça imkansız.

Ama eğer demek istiyorsan: "teslim edilen kodda sıfır hata" -> bu mümkün ve ben böyle ortamlarda çalıştım.

İhtiyacınız olan tek şey: delicesine yüksek kod kalitesi ve% 100'e yakın test kapsamı (ünite testleri + kabul testleri + entegrasyon testleri).

Bence bunu öğrenmek için en iyi kitap: GOOS . Fakat elbette bir kitap yeterli değildir. Bazı kullanıcı gruplarına gidip bunun hakkında tartışmalısınız. Kurslar, konferanslar vb. Sıfır hata kalitesi kolay değildir.

Her şeyden önce, yüksek kalitede gerçekten ilgilenen ve bunun için para ödemeye istekli bir patrona ihtiyacınız var.


-3

Programcının çözümü:

  • Programlamayı durdur.
  • Mekanik bir bilgisayar oluşturun.
  • Mekanik aşınmanın devreye girmemesi için her 5 yılda bir değiştirin.

Kullanıcının çözümü:

  • Bilgisayarları kullanmayı bırak.
  • Her şeyi manuel olarak yapın.
  • Daima sonuçları ikinci kez kontrol eden ikinci bir kişi bulundurun.

-3

Sıfır hata programcısı olmak için sadece programlama / kodlama yapamayacağınızı kabul ediyorum. Böcekle karşılaşmak ve gelişmek her programcının hayatının bir parçası. Hiçbir tecrübeli geliştirici söyleyemez, yürekten teslim alırlar, kodlarında bir hata ile karşılaşmadılar.


-4

Başka bir mühendisle eşleştirin. Başarısız bir test yazın. Başarısız testi geçmek için yazdığınız her karakterin gerekli olmasını sağlayın. Daha basit hale getirmek için kodunuzu yenileyin. Başka bir başarısızlık testi vb. Yazınız.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.