Bagaimana cara menjadi programmer zero-bug? [Tutup]

Bos saya selalu mengatakan kepada saya bahwa seorang programmer yang baik harus dapat memastikan bahwa kode yang diubahnya dapat diandalkan, benar, dan benar-benar diverifikasi sendiri; Anda harus sepenuhnya memahami semua hasil dan dampak yang akan ditimbulkan oleh perubahan Anda. Saya telah mencoba yang terbaik untuk menjadi programmer semacam ini — dengan menguji berulang kali — tetapi bug masih ada.

Bagaimana saya bisa menjadi programmer zero-bug dan tahu apa yang akan menyebabkan dan mempengaruhi setiap karakter kode saya?

Jangan kode sama sekali.

Itulah satu-satunya cara Anda bisa menjadi programmer zero-bug.

Bug tidak dapat dihindari karena programmer adalah manusia, yang dapat kita lakukan adalah mencoba yang terbaik untuk mencegahnya, bereaksi dengan cepat ketika bug terjadi, belajar dari kesalahan kita dan tetap mengikuti perkembangan.

Tidak ada bug yang mustahil untuk program non-sepele.

Mungkin saja menjadi sangat dekat, tetapi produktivitas menderita. Dan itu hanya bermanfaat untuk perangkat lunak berisiko tinggi tertentu. Perangkat lunak Space Shuttle muncul di benak saya. Tetapi produktivitas mereka berada di urutan beberapa baris sehari. Saya ragu bos Anda menginginkan itu.

Perangkat lunak ini bebas bug. Itu sempurna, sesempurna yang telah dicapai manusia. Pertimbangkan statistik ini: tiga versi terakhir dari program - masing-masing sepanjang 420.000 baris - masing-masing hanya memiliki satu kesalahan. 11 versi terakhir dari perangkat lunak ini memiliki total 17 kesalahan.

Ambil pemutakhiran perangkat lunak untuk mengizinkan antar-jemput bernavigasi dengan Global Positioning Satellites, perubahan yang hanya melibatkan 1,5% dari program, atau 6.366 baris kode. Spesifikasi untuk satu perubahan itu berjalan 2.500 halaman, volume lebih tebal dari buku telepon. Spesifikasi untuk program saat ini mengisi 30 volume dan menjalankan 40.000 halaman.

"Zero-bug programmer" adalah sebuah oxymoron, seperti penyanyi pendiam, tetapi 60 tahun terakhir pemrograman telah menghasilkan beberapa bit kebijaksanaan yang disaring, yang akan menjadikan Anda seorang programmer yang lebih baik, seperti:

• Bersikaplah rendah hati - Anda sedang dan akan membuat kesalahan. Berkali-kali.
• Sadar sepenuhnya akan ukuran tengkorak Anda yang terbatas. Dekati tugas dengan penuh kerendahan hati, dan hindari trik cerdas seperti wabah. [Edsger Dijkstra]
• Perangi ledakan kombinasi
• Singkirkan keadaan yang bisa berubah (jika memungkinkan). Ya, pelajari pemrograman fungsional.
• Kurangi jumlah kemungkinan jalur kode
• Pahami (besarnya) ukuran ruang input & output (fungsi Anda), dan cobalah untuk menguranginya agar semakin mendekati cakupan uji 100%
• Selalu anggap kode Anda tidak berfungsi - buktikan sebaliknya!

TDD

Maksud dari TDD adalah bahwa Anda tidak menulis satu baris kode jika tidak ada tes yang membutuhkan baris kode itu. Dan untuk membawanya ke ekstrim Anda selalu mulai mengembangkan fitur baru dengan menulis tes penerimaan. Di sini saya menemukan bahwa menulis tes gaya mentimun sangat ideal.

Pendekatan TDD memberikan setidaknya dua manfaat.

• Semua kode ditulis untuk menyelesaikan fitur tertentu, sehingga tidak ada kelebihan produksi yang tidak perlu.
• Setiap kali Anda mengubah baris kode yang ada, jika Anda melanggar fitur, Anda akan diberitahu

Itu tidak membuktikan bug nol, karena itu tidak mungkin (telah ditunjukkan oleh banyak jawaban lain). Tetapi setelah mempelajari TDD dan menjadi ahli dalam hal itu (ya, itu juga keterampilan yang perlu latihan), saya memiliki kepercayaan yang jauh lebih tinggi pada kode saya sendiri karena sudah diuji secara menyeluruh. Dan yang lebih penting, saya dapat mengubah kode yang ada yang tidak saya pahami sepenuhnya tanpa khawatir akan merusak fungsionalitas.

Tapi TDD tidak membantu Anda sepenuhnya. Anda tidak dapat menulis kode bebas bug jika Anda tidak benar-benar memahami arsitektur sistem, dan perangkap arsitektur itu. Misalnya, jika Anda menulis aplikasi web yang menangani beberapa permintaan secara bersamaan, Anda harus tahu bahwa Anda tidak dapat berbagi data yang dapat diubah di antara beberapa permintaan (jangan masuk ke dalam perangkap pemula untuk menyimpan cache data yang dapat diubah untuk meningkatkan kinerja).

Saya percaya bahwa tim pengembangan yang pandai TDD memberikan kode dengan cacat paling sedikit.

Masalahnya, bug adalah hal-hal yang tidak Anda kenali. Kecuali jika Anda memiliki semacam pengetahuan ensiklopedis dari bahasa pemrograman / kompiler serta semua lingkungan aplikasi Anda akan berjalan di, Anda benar-benar tidak bisa berharap untuk menghasilkan kode bebas bug 100%.

Anda dapat mengurangi jumlah bug Anda melalui banyak pengujian, tetapi pada akhirnya akan ada beberapa kasus pinggiran yang tidak akan diperhitungkan. Joel Spolsky menulis artikel yang sangat bagus tentang perbaikan bug .

Ya, tidak mungkin untuk tidak memiliki bug dalam kode Anda, tetapi bukan tidak mungkin untuk memiliki lebih sedikit bug. Sikap bahwa "Itu bodoh, Anda akan selalu memiliki bug" hanyalah cara untuk menghindari mengurangi jumlah bug dalam kode Anda. Tidak ada yang sempurna tetapi kita bisa dan harus berusaha untuk menjadi lebih baik. Dalam upaya saya sendiri untuk meningkatkan, saya telah menemukan poin-poin berikut bermanfaat.

• Ini tidak mudah. Anda tidak akan membaik dalam semalam. Jadi jangan berkecil hati dan jangan menyerah.
• Menulis lebih sedikit dan menulis lebih pintar. Lebih sedikit kode biasanya kode yang lebih baik. Wajar jika ingin membuat rencana ke depan dan mencoba membuat pola desain yang luar biasa tetapi dalam jangka panjang hanya menulis apa yang Anda butuhkan menghemat waktu dan mencegah bug.
• Kompleksitas adalah musuh. Kurang tidak dihitung jika itu adalah kekacauan rumit yang tidak jelas. Code golf memang menyenangkan tetapi neraka untuk dipahami dan neraka yang lebih buruk untuk di-debug. Setiap kali Anda menulis kode rumit Anda membuka diri Anda ke dunia masalah. Buat hal-hal sederhana dan singkat.
• Kompleksitas itu subyektif. Kode yang dulunya rumit menjadi sederhana begitu Anda menjadi programmer yang lebih baik.
• Pengalaman itu penting. Salah satu dari dua cara untuk menjadi programmer yang lebih baik adalah berlatih. Berlatih BUKAN menulis program yang Anda tahu cara menulis dengan mudah, itu menulis program yang sedikit menyakitkan dan membuat Anda berpikir.
• Cara lain untuk menjadi lebih baik adalah dengan membaca. Ada banyak topik sulit dalam pemrograman untuk dipelajari tetapi Anda tidak akan pernah bisa mempelajarinya hanya dengan pemrograman, Anda perlu mempelajarinya. Anda perlu membaca hal-hal yang sulit. Hal-hal seperti keamanan dan konkurensi tidak mungkin ia pelajari dengan benar hanya dari menulis kode kecuali Anda ingin belajar dengan membersihkan bencana. Jika Anda tidak percaya saya melihat situs masalah keamanan epik seperti gawker miliki. Jika mereka meluangkan waktu untuk mempelajari cara melakukan keamanan dengan benar dan tidak hanya membuat sesuatu yang berhasil, kekacauan tidak akan pernah terjadi.
• Baca blog. Ada banyak blog menarik di luar sana yang akan memberi Anda cara baru dan menarik untuk dilihat dan dipikirkan tentang pemrograman, ini akan membantu Anda ...
• Pelajari detail kotornya. Detail kecil tentang bagaimana bagian-bagian yang tidak jelas dari bahasa dan aplikasi Anda bekerja sangat penting. Mereka bisa menyimpan rahasia yang membantu Anda menghindari penulisan kode rumit atau bisa jadi bagian yang memiliki bug sendiri yang perlu Anda hindari.
• Pelajari cara berpikir pengguna. Terkadang pengguna Anda benar-benar gila dan akan bekerja dengan aplikasi Anda dengan cara yang tidak Anda mengerti dan tidak bisa prediksi. Anda harus masuk ke kepala mereka cukup untuk mengetahui hal-hal asing yang mungkin mereka coba dan pastikan aplikasi Anda dapat menanganinya.

Secara pribadi saya berpikir bahwa berjuang untuk pemrograman bebas bug tampaknya lebih mahal (baik dalam waktu dan uang). Untuk mencapai bug nol, atau bahkan bug mendekati nol, Anda perlu menguji pengembang secara menyeluruh. Ini berarti menguji segala sesuatu sebelum mengirimkan kode apa pun untuk tinjauan patch. Model ini menurut saya tidak efektif dari segi biaya. Sebaiknya Anda meminta pengembang melakukan uji tuntas dan membiarkan pengujian mendalam sampai ke tim QA. Inilah alasannya:

• Pengembang payah dalam pengujian. Itu benar dan Anda tahu itu. (Saya seorang pengembang!) Tim QA yang baik akan selalu menemukan kasus tepi yang tidak pernah dipikirkan oleh pengembang.
• Pengembang pandai coding. Biarkan mereka kembali ke apa yang mereka kuasai (dan biasanya apa yang mereka sukai untuk dilakukan.)
• Tim QA dapat menemukan bug yang terkait dengan beberapa tugas pengembang dalam satu pass.

Terima bahwa ketika Anda menulis kode, akan ada bug yang dicatat. Itu sebabnya Anda memiliki proses QA, dan itu semua adalah bagian dari menjadi pengembang. Tentu saja ini tidak berarti Anda mengirimkan sesuatu segera setelah Anda menulis semi-colon terakhir Anda. Anda masih perlu memastikan kualitas dalam pekerjaan Anda, tetapi Anda bisa melakukannya secara berlebihan.

Berapa banyak profesi yang dapat Anda sebutkan yang selalu menyelesaikan tugas mereka dengan benar pertama kali tanpa peer review dan / atau pengujian?

Tidak ada bug? Sepertinya Anda memerlukan Lisp (ikuti jalur skeptis dan hindari video musik).

Sangat sulit untuk mencapai kode bebas bug di lingkungan pengkodean utama (Java, C #, PHP, dll.). Saya akan fokus pada pembuatan kode yang diuji dengan baik dan ditinjau sejawat dalam iterasi yang terkontrol pendek.

Menjaga kode sesederhana mungkin akan membantu Anda menghindari bug.

Pastikan Anda menggunakan alat analisis kode (seperti FindBugs , PMD , dan sebagainya) yang - digabung dengan peringatan kompilator yang ketat - akan mengungkap segala macam masalah dengan kode Anda. Perhatikan apa yang mereka katakan kepada Anda, benar-benar berusaha untuk memahami apa sifat bug itu, dan kemudian mengambil langkah-langkah untuk mengubah idiom pemrograman Anda sehingga terasa tidak wajar untuk kode dengan cara yang memperkenalkan bug itu lagi.

Semua "Jangan kode sama sekali." jawaban benar-benar hilang intinya. Juga, bos Anda tampaknya tidak bodoh!

Saya tidak ingat seberapa sering saya melihat programmer yang tidak tahu apa kode mereka. Philosohpy perkembangan tunggal mereka tampaknya trial and error (dan cukup sering juga menyalin / menempel / memodifikasi). Meskipun coba-coba adalah cara yang valid untuk menyelesaikan beberapa masalah, sering kali Anda dapat menganalisis domain masalah dan kemudian menerapkan solusi yang sangat spesifik berdasarkan pemahaman Anda tentang alat yang Anda gunakan dan dengan sedikit disiplin dan ketekunan Anda tidak akan memiliki hanya menyelesaikan masalah tetapi juga sebagian besar kasus sudut (bug potensial) sebelum Anda menyebarkannya untuk pertama kalinya. Bisakah Anda menjamin bahwa kode tersebut bebas bug? Tentu saja tidak. Tetapi dengan setiap bug yang Anda temui atau baca tentang Anda dapat menambahkannya ke hal-hal yang mungkin ingin Anda pikirkan saat berikutnya Anda menulis / mengubah sesuatu. Jika Anda melakukan ini, akibatnya Anda akan mendapatkan banyak pengalaman tentang cara menulis kode yang hampir bebas bug. - Ada banyak sumber daya yang tersedia tentang cara menjadi programmer yang lebih baik yang dapat membantu Anda dalam perjalanan ...

Secara pribadi, saya tidak akan pernah melakukan kode di mana saya tidak bisa menjelaskan setiap baris. Setiap baris memiliki alasan untuk berada di sana, jika tidak maka harus dihapus. Tentu saja kadang-kadang Anda akan membuat asumsi tentang cara kerja bagian dalam metode yang Anda panggil, jika tidak, Anda perlu mengetahui logika bagian dalam dari keseluruhan kerangka kerja.

Bos Anda sepenuhnya benar untuk mengatakan bahwa Anda harus memahami hasil dan dampak dari kode yang Anda tulis pada sistem yang ada. Akankah bug muncul? Ya tentu saja. Tetapi bug ini disebabkan oleh pemahaman Anda yang tidak lengkap tentang sistem / alat yang Anda gunakan dan dengan setiap perbaikan bug Anda akan memiliki cakupan yang lebih baik.

Seperti komentar lain sudah menunjukkan dengan benar, tidak ada perangkat lunak non-sepele tanpa bug.

Jika Anda ingin menguji perangkat lunak selalu diingat, tes itu hanya dapat membuktikan keberadaan bug bukan ketidakhadiran mereka.

Tergantung pada domain kerja Anda, Anda dapat mencoba verifikasi formal perangkat lunak Anda. Dengan menggunakan metode formal Anda dapat menjadi sangat yakin bahwa perangkat lunak Anda benar-benar memenuhi spesifikasi.

Tentu itu tidak berarti bahwa perangkat lunak persis melakukan apa yang Anda inginkan. Menulis spesifikasi yang lengkap dalam hampir semua kasus juga tidak mungkin. Ini pada dasarnya menggeser tempat di mana kesalahan dapat terjadi dari implementasi ke spesifikasi.

Jadi, tergantung pada definisi Anda tentang "bug" Anda dapat mencoba verifikasi formal atau hanya mencoba menemukan bug sebanyak yang Anda bisa dalam perangkat lunak Anda.

Jangan menulis apa pun yang lebih rumit dari "Hello World!" atau jika Anda memberi tahu semua orang untuk tidak menggunakannya.

Tanyakan kepada bos Anda untuk beberapa contoh kode bebas bug ini.

Saya setuju dengan yang lain. Inilah cara saya mendekati masalah

• Dapatkan tester. Lihat Tes Joel untuk alasannya.
• Gunakan perpustakaan secara luas; mungkin telah di debug lebih baik. Saya penggemar berat CPAN untuk Perl.

Anda bisa berusaha menjadi pemrogram bug nol. Saya berusaha untuk menjadi programmer bug nol setiap kali saya menulis kode. Namun, saya tidak melakukannya

• menggunakan beberapa teknik pengujian (selain ATDD)
• buat verifikasi formal perangkat lunak kami
• memiliki tim QA yang terpisah
• lakukan analisis keras pada setiap perubahan yang dilakukan pada basis kode
• gunakan bahasa yang lebih condong ke arah keamanan dan kehati-hatian

Saya tidak melakukan hal-hal ini karena biayanya mahal untuk perangkat lunak yang saya tulis. Jika saya melakukan hal-hal ini saya mungkin akan lebih jauh menuju nol bug, tetapi itu tidak masuk akal secara bisnis.

Saya membuat alat internal yang sebagian besar dari infrastruktur kami gunakan. Standar saya untuk pengujian dan pengkodean tinggi. Namun, ada keseimbangan. Saya tidak mengharapkan bug nol karena saya tidak bisa membuat orang menaruh waktu semacam itu dalam satu pekerjaan. Segalanya mungkin berbeda jika saya membuat perangkat lunak untuk mengendalikan mesin X-Ray, mesin jet, dll. Tidak ada nyawa di jalur itu jika perangkat lunak saya rusak, jadi kami tidak terlibat dalam tingkat jaminan itu.

Saya akan mencocokkan tingkat jaminan dengan tujuan penggunaan perangkat lunak. Jika Anda menulis kode yang akan digunakan pesawat ulang-alik NASA, mungkin toleransi nol bug masuk akal. Anda hanya perlu menambahkan banyak praktik tambahan dan sangat mahal.

Saya pikir langkah pertama yang baik untuk menjadi programmer "zero-bug" adalah mengubah sikap Anda terhadap bug. Alih-alih mengatakan hal-hal "itu terjadi," "dapatkan QA dan penguji yang lebih baik," atau "pengembang payah dalam pengujian," katakan:

Bug tidak dapat diterima, dan saya akan melakukan segala daya saya untuk menghilangkannya.

Setelah ini menjadi sikap Anda, bug akan cepat turun. Dalam pencarian Anda untuk menemukan cara menghilangkan bug, Anda akan menemukan pengembangan yang digerakkan oleh pengujian. Anda akan menemukan banyak buku, posting blog, dan orang-orang yang menawarkan saran gratis tentang teknik yang lebih baik. Anda akan melihat pentingnya meningkatkan keterampilan Anda melalui latihan (seperti coding katas, atau mencoba hal-hal baru di rumah). Anda akan mulai tampil lebih baik di tempat kerja karena Anda akan mulai mengerjakan kerajinan Anda di rumah. Dan, semoga, setelah Anda melihat bahwa adalah mungkin untuk menulis perangkat lunak yang baik, hasrat Anda untuk kerajinan Anda akan tumbuh.

Dalam arti tertentu, bos Anda benar. Dimungkinkan untuk menulis perangkat lunak yang mendekati nol bug.

Tetapi masalahnya adalah bahwa biaya melakukan penulisan (hampir) program zero-bug sangat tinggi . Anda perlu melakukan hal-hal seperti:

• Gunakan spesifikasi formal persyaratan Anda. Formal, seperti dalam penggunaan Z atau VDM atau notasi suara lainnya secara matematis.

• Gunakan teknik pembuktian teorema untuk membuktikan secara formal bahwa program Anda mengimplementasikan spesifikasi.

• Buat unit, regresi, dan suite uji sistem yang lengkap dan memanfaatkan untuk menguji segala cara untuk bug. (Dan ini saja tidak cukup.)

• Mintalah banyak orang meninjau persyaratan (formal dan informal), perangkat lunak (dan bukti). tes, dan penyebaran.

Sangat tidak mungkin bos Anda siap untuk membayar semua ini ... atau tahan dengan waktu yang diperlukan untuk melakukan semuanya.

Saya telah mencapai status "zero bug". Saya memberi tahu pengguna saya bahwa ini adalah fitur yang tidak didokumentasikan, atau mereka meminta fitur baru dan karena itu merupakan peningkatan. Jika tidak satu pun dari tanggapan ini diterima, saya hanya mengatakan kepada mereka bahwa mereka belum memahami persyaratan mereka sendiri. Dengan demikian, tidak ada bug. Programmer sempurna.

Berikut adalah langkah-langkah untuk membuat program bebas bug:

1. Jangan pernah memulai pengkodean kecuali Anda memiliki SPESIFIKASI YANG LUAR BIASA untuk fungsionalitas Anda.
2. JANGAN MENGUJI atau atau jika Anda JANGAN RELY ON TESTING untuk menangkap cacat pada perangkat lunak.
3. Terapkan semua UMPAN BALIK dari cacat yang ditemukan selama pengujian, ulasan dan produksi untuk proses dan pengembang yang memasukkan cacat di tempat pertama. Buang semua komponen yang rusak sepenuhnya begitu ditemukan kerusakan. Perbarui daftar periksa Anda dan latih kembali pengembang Anda sehingga mereka tidak membuat kesalahan seperti itu lagi.

Pengujian hanya dapat membuktikan bahwa Anda memiliki bug, tetapi biasanya tidak berguna untuk membuktikan sebaliknya. Mengenai umpan balik - jika Anda memiliki mesin pembuat koin yang membuat koin dan setiap koin 10s rata-rata memiliki cacat. Anda dapat mengambil koin itu, ratakan dan masukkan kembali ke dalam mesin. koin yang menghasilkan kosong daur ulang tidak akan sebaik, tetapi mungkin dapat diterima. setiap koin 100-an harus dicap ulang 2 kali dan seterusnya. Apakah akan lebih mudah untuk memperbaiki mesin?

Sayangnya orang bukan mesin. Untuk membuat programmer yang baik dan bebas cacat, Anda harus menginvestasikan banyak waktu, pelatihan, dan iterasi setiap cacat yang dibuat. Pengembang perlu dilatih dalam metode verifikasi formal yang seringkali sulit dipelajari dan diterapkan dalam praktik. Ekonomi pengembangan perangkat lunak juga bekerja melawannya - akankah Anda berinvestasi 2 tahun untuk melatih seorang programmer yang dapat membuat lebih sedikit cacat hanya untuk melihatnya melompat ke perusahaan lain? Anda dapat membeli mesin yang menghasilkan koin sempurna, atau menyewa 10 monyet kode tambahan untuk membuat banyak tes dengan biaya yang sama. Anda dapat menganggap proses yang melelahkan ini sebagai "mesin" Anda, aset Anda - berinvestasi dalam pelatihan ekstensif pengembang yang hebat tidak membuahkan hasil.

Sebentar lagi Anda akan belajar bagaimana mengembangkan perangkat lunak dengan kualitas yang dapat diterima, tetapi mungkin Anda tidak akan pernah menjadi cacat gratis karena alasan sederhana bahwa tidak ada pasar untuk pengembang yang membuat kode sempurna karena lambat.

Program defensif: http://en.wikipedia.org/wiki/Defensive_programming

Jika seseorang mengikuti konvensi pemrograman secara defensif, maka perubahan akan mudah dilacak. Kombinasikan ini dengan laporan bug yang ketat selama pengembangan, dan dokumentasi yang solid, seperti dengan doxygen, dan Anda harus dapat mengetahui dengan tepat apa yang dilakukan semua kode Anda dan memperbaiki bug yang muncul, sangat efisien.

Mungkinkah ini hasil dari kesalahpahaman tentang metodologi yang baik , dan bukan hanya kekepalan generik?

Maksud saya adalah bahwa mungkin saja bos Anda mendengar "metodologi tanpa cacat" (lihat bagian no.5), dan tidak repot-repot memahami apa artinya itu?
Tentu saja, manajemen tidak nyaman untuk menunda pengembangan fitur baru, mendukung bug yang seharusnya tidak Anda masukkan ...
Dan tentu saja, itu mengancam bonusnya, jadi tentu saja Anda tidak akan mendapatkannya karena "programmer yang baik tidak punya bug "...

Tidak masalah untuk membuat bug, selama Anda dapat menemukannya dan memperbaikinya (tentu saja dengan alasan).

Salah satu konsep dasar pengujian perangkat lunak adalah bahwa Anda TIDAK PERNAH benar-benar yakin bahwa programnya sempurna. Anda dapat memvalidasinya selamanya, tetapi itu tidak pernah membuktikan bahwa program tersebut selesai karena dengan cepat menjadi tidak layak bahkan untuk menguji semua kombinasi input / variabel.

Bos Anda sepertinya salah satu dari mereka yang "tidak mengerti apa yang sulit tentang pemrograman, karena hanya mengetik"

Jika kita menganggap rumah perangkat lunak besar tahu cara mendapatkan pengembang terbaik (seperti pada programmer zero bug ) kita dapat menyimpulkan bahwa perangkat lunak Microsoft harus tanpa bug. Namun kita tahu itu jauh dari kebenaran.

Mengembangkan perangkat lunak mereka dan ketika mereka mencapai tingkat tertentu bug prioritas rendah mereka hanya merilis produk dan menyelesaikannya nanti.

Kecuali jika Anda mengembangkan sesuatu yang lebih kompleks daripada kalkulator sederhana, itu tidak mungkin untuk menghindari bug secara bersamaan. Neraka bahkan NASA memiliki redundansi pada kendaraan dan bug mereka juga. Meskipun mereka memiliki banyak pengujian yang ketat untuk menghindari kegagalan bencana. Namun demikian bahkan mereka memiliki bug dalam perangkat lunak mereka.

Bug tidak bisa dihindari sama seperti sifat manusia untuk berbuat salah.

Tidak memiliki bug seperti memiliki sistem yang 100% aman. Jika suatu sistem 100% aman itu pasti tidak berguna lagi (mungkin terletak di dalam berton-ton beton dan tidak terhubung ke luar sama sekali. Tidak kabel atau nirkabel. Jadi sama seperti tidak ada sistem yang benar-benar aman , tidak ada sistem bug-less yang kompleks.

Saya hanya melihat jawaban tentang kami sebagai manusia dan cenderung salah, yang sangat benar ... tetapi saya melihat pertanyaan Anda dari sudut pandang lain.

Saya pikir Anda dapat menulis program bebas bug, tetapi biasanya itu adalah program yang sudah Anda tulis 10 atau 12 kali. Kali ke-13 Anda menulis program yang sama dari awal, Anda sudah tahu bagaimana melakukannya: Anda tahu masalahnya, Anda tahu tekniknya, Anda tahu perpustakaan, bahasa ... Anda melihatnya dalam pikiran Anda. Semua pola ada di sana, di semua tingkatan.

Ini terjadi pada saya dengan program yang sangat sederhana karena saya mengajar pemrograman. Mereka sederhana bagi saya, tetapi sulit bagi para siswa. Dan saya tidak berbicara tentang solusi untuk masalah yang telah saya lakukan berkali-kali di papan tulis. Tentu saja saya tahu itu. Maksud saya ~ 300-line program yang memecahkan sesuatu menggunakan konsep yang saya kenal dengan baik (konsep yang saya ajarkan). Saya menulis program ini tanpa perencanaan dan hanya berfungsi, dan saya merasa saya tahu semua detailnya, saya tidak perlu TDD sama sekali. Saya mendapatkan beberapa atau tiga kesalahan kompilasi (kebanyakan kesalahan ketik dan hal-hal lain seperti itu) dan hanya itu. Saya dapat melakukan ini untuk program kecil, dan saya juga percaya bahwa beberapa orang dapat melakukannya untuk program yang lebih rumit. Saya pikir orang-orang seperti Linus Torvalds atau Daniel J. Bernstein memiliki kejernihan pikiran, mereka adalah yang paling dekat dengan pembuat kode bebas bug. Jika kamuMemahami hal-hal secara mendalam, saya pikir Anda bisa melakukannya. Saya hanya bisa melakukan ini untuk program sederhana, seperti yang saya katakan.

Keyakinan saya adalah bahwa jika Anda selalu mencoba melakukan program yang jauh di atas level Anda (saya telah menghabiskan waktu bertahun-tahun melakukan hal itu), Anda akan bingung dan membuat kesalahan. Kesalahan besar seperti ketika Anda tiba-tiba menyadari bahwa solusi Anda tidak dapat bekerja, ketika Anda akhirnya memahami masalahnya, dan harus membuat perubahan yang begitu rumit sehingga mereka mungkin menghentikan Anda dari menyelesaikan masalah Anda atau membuat kode menjadi buruk. TDD untuk kasus ini, saya percaya. Anda tahu bahwa Anda tidak mengalami masalah yang sedang Anda hadapi dan karenanya melakukan tes di mana-mana untuk memastikan bahwa Anda memiliki basis yang kuat. TDD tidak menyelesaikan visi 10.000 kaki. Anda mungkin berjalan berputar-putar dengan kode bersih sempurna sepanjang waktu.

Namun, jika Anda mencoba melakukan sesuatu yang baru tetapi itu hanya di atas level Anda, Anda mungkin mendapatkan program Anda sempurna atau hampir sempurna. Saya pikir sangat sulit untuk mengetahui program apa yang ada di "batas pengetahuan" Anda, tetapi secara teori itu adalah cara terbaik untuk belajar. Saya menulis ulang banyak program dari awal, sebenarnya. Beberapa orang melakukannya, tetapi Anda membutuhkan banyak waktu dan kesabaran karena ketiga kalinya Anda mengulangi program yang tidak sepele, Anda tidak menjadi bersemangat seperti yang pertama kali.

Jadi saran saya adalah: jangan berpikir Anda mengerti sesuatu sampai Anda dapat menulis program bebas bug hanya untuk hal itu. Dan kemudian cobalah untuk menggabungkan dua konsep yang Anda ketahui secara mendalam ke dalam program yang sama. Saya hampir yakin Anda akan melakukannya dengan benar pertama kali. Salah satu cara terbaik adalah menulis ulang perangkat lunak non-sepele, sesuatu yang membutuhkan banyak upaya pertama kali (saya melakukan ini dengan aplikasi Android sekarang). Setiap kali saya mulai lagi saya mengubah sesuatu atau menambahkan barang, hanya untuk menambahkan sedikit kesenangan, dan saya dapat memberitahu Anda bahwa saya menjadi lebih baik dan lebih baik dan lebih baik ... mungkin tidak bebas bug tetapi sangat bangga.

bug imho dan artefak algoritma misterius yang tiba-tiba harus muncul selama proses pengkodean: mereka menginspirasi dan memaksa evolusi kode.
namun dimungkinkan (biasanya setelah beberapa pengujian) untuk memeriksa setiap variabel yang mungkin digunakan sebelum deklarasi, untuk menangani setiap kesalahan di mana pun ia muncul - untuk membuat program zero-bug ... sampai Anda menerima permintaan untuk fitur yang dianggap tidak mungkin ketika Anda mendiskusikan arsitektur program;)

Mungkin pikirkan lebih lanjut tentang sifat bug yang Anda dapatkan. Jika bug umumnya pengawasan kecil maka fokus pada pengujian yang lebih baik dan sedikit pembacaan kode akan membantu.

Namun, jika bug cenderung disebabkan oleh keputusan pemrograman yang tidak optimal, maka mungkin diperlukan lebih banyak upaya dalam desain yang lebih baik. Dalam hal ini, saya pikir mungkin terlalu bergantung pada pengujian untuk meningkatkan kualitas perangkat lunak, karena menerapkan tambalan ke kode yang kurang dapat membuat perawatan di masa mendatang lebih rumit. Di satu sisi Anda mendapatkan lebih sedikit bug saat Anda menemukan dan memperbaikinya, tetapi di sisi lain Anda menyiapkan tanah untuk bug di masa depan.

Salah satu cara untuk menilai apakah Anda memiliki masalah dengan pengawasan atau masalah dengan desain mungkin dengan mempertimbangkan berapa banyak upaya yang diperlukan untuk memperbaiki bug. Jika perbaikan cenderung besar, atau Anda merasa tidak memahaminya dengan baik, itu menunjukkan angka pada desain kode yang dapat ditingkatkan.

Yang saya pikir turun ke semacam selera yang baik tentang kode, yang dapat Anda kembangkan dengan latihan dan ulasan, dan membaca tentang orang-orang dengan masalah serupa.

Pada akhirnya, sia-sia mengharapkan tidak ada bug sama sekali, tetapi tidak ada salahnya mencoba mengurangi jumlah bug Anda kecuali Anda sudah memilikinya pada level rendah, dan kemudian menjadi trade-off antara waktu Anda dan waktu siapa pun yang menemukan bug yang tidak Anda tangkap.

Jika saya maksud Anda: "nol bug saat menulis kode" -> itu tujuan yang bagus tapi sangat tidak mungkin.

Tetapi jika Anda maksud: "nol bug pada kode yang dikirim" -> itu mungkin, dan saya bekerja di lingkungan seperti itu.

Yang Anda butuhkan adalah: kualitas kode sangat tinggi dan cakupan tes hampir 100% (tes unit + tes penerimaan + tes integrasi).

Menurut pendapat saya, buku terbaik untuk dipelajari adalah: GOOS . Tetapi tentu saja sebuah buku tidak cukup. Anda perlu pergi ke beberapa grup pengguna dan mendiskusikan hal ini. Kursus, konferensi, dll. Kualitas zero-bug tidak mudah.

Pertama-tama Anda membutuhkan bos yang benar-benar tertarik dengan kualitas tinggi dan bersedia membayar untuk itu.

Solusi Programmer:

• Hentikan pemrograman.
• Bangun komputer mekanik.
• Ganti setiap 5 tahun sehingga pemakaian mekanis tidak ikut berperan.

Solusi pengguna:

• Berhenti menggunakan komputer.
• Lakukan semuanya secara manual.
• Selalu minta orang kedua untuk memeriksa hasilnya.

Saya setuju bahwa untuk menjadi programmer zero-bug Anda tidak dapat memprogram / kode. Itu bagian dari kehidupan setiap programmer untuk menemukan dan mengembangkan bug. Tidak ada pengembang berpengalaman yang bisa mengatakan, secara langsung, mereka tidak pernah menemukan bug dalam kode mereka.

Padukan dengan insinyur lain. Tulis tes yang gagal. Suruh setiap karakter yang Anda ketik diperlukan untuk membuat lulus ujian yang gagal. Perbaiki kode Anda untuk membuatnya lebih sederhana. Tulis tes gagal yang lain, dan seterusnya.