Saya berbicara tentang 20-30 + jutaan baris kode, perangkat lunak pada skala dan kompleksitas Autodesk Maya misalnya.

Jika Anda membekukan pengembangan selama itu perlu, dapatkah Anda benar-benar memperbaiki semua bug sampai tidak ada satu bug pun, jika hal seperti itu dapat diverifikasi oleh komputer? Apa argumen untuk dan melawan keberadaan sistem bebas bug?

Karena ada beberapa anggapan bahwa setiap perbaikan yang Anda buat menghasilkan lebih banyak bug, tapi saya rasa itu tidak benar.

Dengan bug yang saya maksud dari kesalahan ketik paling sederhana di UI, untuk bug pencegahan yang lebih serius yang tidak ada solusinya. Misalnya fungsi scripting tertentu menghitung normals secara tidak benar. Bahkan ketika ada solusi, masalahnya masih harus diperbaiki. Jadi Anda bisa mengatakan Anda dapat melakukan hal ini secara manual daripada menggunakan fungsi yang disediakan tetapi fungsi itu masih harus diperbaiki.

Seperti yang disebutkan Mikey, menulis kode bugless bukanlah tujuannya. Jika itu yang Anda tuju, maka saya punya kabar buruk untuk Anda.

Poin kuncinya adalah Anda terlalu meremehkan kompleksitas perangkat lunak.

Hal pertama yang pertama - Anda mengabaikan gambaran yang lebih besar tentang bagaimana program Anda berjalan. Itu tidak berjalan dalam isolasi pada sistem yang sempurna. Bahkan program "Hello World" yang paling dasar dijalankan pada sistem operasi, dan karenanya, bahkan program yang paling sederhana pun rentan terhadap bug yang mungkin ada dalam sistem operasi.

Keberadaan perpustakaan membuat ini lebih kompleks. Sementara sistem operasi cenderung cukup stabil, perpustakaan adalah tas campuran ketika datang ke stabilitas. Beberapa sangat bagus. Lainnya ... tidak terlalu banyak ... Jika Anda ingin kode Anda 100% bebas bug, maka Anda juga perlu memastikan bahwa setiap perpustakaan yang Anda hadapi benar-benar bebas bug, dan sering kali ini tidak mungkin dilakukan karena Anda mungkin tidak memiliki kode sumber.

Lalu ada utas untuk dipikirkan. Sebagian besar program skala besar menggunakan utas di semua tempat. Kami mencoba untuk berhati-hati dan menulis utas sedemikian rupa sehingga kondisi balapan dan kebuntuan tidak terjadi, tetapi tidak mungkin untuk menguji setiap kombinasi kode yang mungkin. Untuk menguji ini secara efektif, Anda perlu memeriksa setiap kemungkinan pemesanan perintah melalui CPU. Saya belum melakukan perhitungan matematika untuk yang satu ini, tetapi saya curiga bahwa menghitung semua kemungkinan permainan Catur akan lebih mudah.

Hal-hal berubah dari sulit menjadi tidak mungkin ketika kita melihat mesin itu sendiri. CPU tidak sempurna. RAM tidak sempurna. Hard drive tidak sempurna. Tak satu pun dari komponen dalam mesin yang dirancang untuk menjadi sempurna - mereka dirancang untuk menjadi "cukup baik". Bahkan program yang sempurna pada akhirnya akan gagal karena cegukan oleh mesin. Tidak ada yang bisa Anda lakukan untuk menghentikannya.

Intinya: Dapatkah Anda menulis "Perangkat lunak bebas bug"?

TIDAK

Siapa pun yang memberi tahu Anda sebaliknya tidak tahu apa-apa.

Cobalah untuk menulis perangkat lunak yang mudah dimengerti dan dipelihara. Setelah Anda selesai melakukannya, Anda bisa meneleponnya sehari.

EDIT: Beberapa orang berkomentar tentang hal yang sangat baik yang saya abaikan: kompiler.

Kecuali jika Anda menulis dalam kumpulan, sangat mungkin kompiler akan mengacaukan kode Anda (bahkan jika Anda membuktikan bahwa kode Anda "sempurna").

Daftar bug di GCC, salah satu kompiler yang lebih umum digunakan: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=---

Secara matematis itu MUNGKIN mungkin untuk menulis perangkat lunak 'bugless' kompleksitas tersebut, tergantung pada bagaimana Anda mendefinisikan 'bug'. Membuktikannya MUNGKIN juga dimungkinkan secara matematis, dengan merancang sistem uji yang akan melatih setiap baris kode dengan setiap cara yang mungkin - setiap kasus penggunaan yang mungkin. Tapi saya tidak yakin - jika Anda berurusan dengan sistem yang melakukan perhitungan yang rumit, Anda mungkin mengalami 'masalah tak terhingga' ...

Secara praktis, dalam sistem ukuran dan ruang lingkup yang Anda bicarakan, ini TIDAK MUNGKIN . Mungkin perlu 1000 tahun untuk menulis sistem 'bebas bug', dan menulis sistem untuk membuktikannya akan membutuhkan lebih banyak waktu secara eksponensial: Anda harus membuat setiap kasus penggunaan yang mungkin dan menulis sistem yang akan menguji masing-masing satu - dan saya tidak percaya ada cara untuk menentukan bahwa Anda telah benar-benar menutupi setiap kasus penggunaan dalam sistem ukuran dan ruang lingkup yang Anda bicarakan dalam segala hal yang menyerupai jumlah waktu yang wajar.

IMO pertanyaan Anda agak salah arah: Tujuan kami sebagai pengembang bukan untuk menulis perangkat lunak 'bugless'. Tujuan kami adalah untuk menulis perangkat lunak yang BERGUNA, FLEKSIBEL, MUDAH TERTANGGUNG JAWAB .

Dapat digunakan: Sistem memenuhi persyaratan penting yang dirancang untuknya. Mungkin ada bug - tetapi mereka akan berada dalam 'kasus tepi' - outlier, atau gangguan, bukan bug yang membahayakan dasar-dasar sistem - kuat.

Maintainable: Bugs dapat dengan mudah diisolasi dan diperbaiki dan JANGAN membuat bug baru.

Fleksibel: Sistem Anda mudah diubah dan diperluas tanpa desain ulang dan waktu henti yang signifikan: Sebagian besar perubahan hanya perlu menambahkan kelas atau modul baru yang cocok dengan pola dan kerangka kerja Anda yang sudah dirancang dengan baik.

Praktik desain yang baik, praktik kontrol yang baik, kerja tim yang baik, pengembang yang teliti - itulah formula untuk PERANGKAT LUNAK YANG BAIK . (tidak SEMPURNA - tapi BAIK )

Menurut artikel ini, perangkat lunak on-board untuk Space Shuttle datang sangat dekat - tiga versi terakhir dari program baris 420.000 hanya memiliki satu kesalahan masing-masing. Perangkat lunak ini dikelola oleh sekelompok 260 pria dan wanita. Sebagian besar dari orang-orang ini adalah pengukur, yang tujuan utamanya adalah untuk menemukan kesalahan.

Pembaruan perangkat lunak untuk memungkinkan antar-jemput untuk bernavigasi dengan Global Positioning Satellites berdampak hanya 1,5% dari program, atau 6.366 baris kode. Spesifikasi untuk satu perubahan tersebut mencapai 2.500 halaman. Spesifikasi untuk keseluruhan program mengisi 30 volume dan berlari 40.000 halaman, atau rata-rata sepuluh baris kode per halaman spesifikasi.

Anggaran bukan masalah - $ 35 milli0n per tahun, mereka mampu melakukan hal-hal yang benar.

Intinya, tidak, tetapi Anda harus tetap melakukan yang terbaik. Saya akan menjelaskan alasannya (atau langsung saja ke kesimpulan jika Anda tidak memiliki cukup kesabaran)

Pertimbangkan masalah sepele seperti implementasi pencarian biner. Satu implementasi yang sangat populer memiliki bug yang tidak terdeteksi selama sekitar dua dekade. Jika dua puluh baris membutuhkan waktu dua puluh tahun untuk membuat bebas bug digunakan secara luas dan bahkan terbukti benar, dapatkah kita benar-benar mengharapkan program besar bebas bug?

Berapa banyak bug yang bisa kita harapkan dari sebuah program besar? Satu angka yang saya temukan adalah "10 cacat per 1000 baris" (Code Complete 2nd edition, halaman 517 - hanya menggunakan contoh, tidak mengutip data apa pun) Itu memberi kami sekitar 200.000 hingga 300.000 bug dalam perangkat lunak Anda. Untungnya, kami memiliki cara untuk meningkatkan kualitas program. Pengujian unit, ulasan kode, dan pengujian manual biasa diketahui mengurangi jumlah bug. Meski begitu, jumlahnya masih akan tinggi.

Jika kita bisa menyelesaikan 95% dari semua bug itu akan luar biasa. Namun kami masih memiliki 10.000 hingga 15.000 bug dalam perangkat lunak.

Untungnya, karena perangkat lunak ini banyak digunakan (dan, karenanya, diuji secara luas) bug akan ditemukan. Jadi secara bertahap kami akan mendapatkan lebih sedikit bug. Namun, lebih sedikit bug juga berarti bahwa bug yang tersisa lebih sulit ditemukan - jadi jangan berharap kurva linear dalam memperbaiki bug. Beberapa bug terakhir akan sangat sulit ditemukan dan dapat lolos dari deteksi selama beberapa tahun (dengan asumsi mereka pernah ditemukan).

Anda juga keliru berasumsi bahwa jika perangkat lunak tidak berubah, tidak ada bug baru yang akan muncul. Jika perangkat lunak tergantung pada pustaka pihak ketiga, versi baru dapat merusak beberapa fitur - memperkenalkan bug baru meskipun kode aplikasi masih sama. Sistem operasi baru juga dapat merusak aplikasi yang sebelumnya berfungsi sempurna (lihat Windows Vista untuk contoh populer). Pertimbangkan juga bug penyusun, dll.

Tidak jelas apakah alat pembuktian kode benar-benar dapat memecahkan masalah perangkat lunak kereta. Tentu saja tidak mungkin menyelesaikan masalah penghentian untuk program apa pun, tetapi mungkin saja membuktikan bahwa suatu program berperilaku seperti yang ditentukan ... Tetapi kemudian apa? Mungkin program buktinya memiliki bug. Mungkin spesifikasinya sendiri memiliki bug.

Jadi jelas, kita dapat sangat mengurangi jumlah bug, tetapi sangat tidak mungkin kita akan mencapai nol.

Karena ada beberapa anggapan bahwa setiap perbaikan yang Anda buat menghasilkan lebih banyak bug, tapi saya rasa itu tidak benar.

(penekanan ditambahkan)

Anda benar. Pernyataan ini salah. Ini sebuah contoh:

int main() {
    int x[10];
    x[10] = 8; //Buffer overflow here
    return 0;
}

Sekarang, mari kita perbaiki bug ini:

int main() {
    int x[11];
    x[10] = 8; //No buffer overflow here
    return 0;
}

Lihat? Kami memperbaiki bug dan tidak memperkenalkan yang baru.

Namun, sudah pasti benar bahwa setiap kali Anda memperbaiki bug Anda berisiko membuat bug baru, meskipun risiko ini dapat dikurangi (misalnya dengan pengujian unit).

Katakanlah untuk setiap 100 bug yang saya perbaiki, saya tidak sengaja memperkenalkan yang baru. Jadi jika saya memperbaiki 10 000 bug, saya memperkenalkan 100 bug baru. Dan jika saya memperbaiki bug baru itu, saya memperkenalkan satu bug. Tapi lalu bagaimana? Program ini sekarang memiliki 9.999 bug lebih sedikit, jadi mungkin lebih baik daripada sebelumnya (dengan asumsi bug baru tidak 10.000 kali lebih buruk daripada yang sebelumnya).

Selain itu, memperbaiki bug dapat mengekspos bug baru. Tetapi bug-bug itu dapat diperbaiki juga. Jika Anda melakukan hal yang benar, pada akhirnya perangkat lunak akan berada dalam kondisi yang lebih baik daripada yang dimulai.

Saya sudah tua oleh beberapa programmer top bahwa lebih baik tidak memperbaiki banyak bug karena gagasan yang saya sebutkan di OP.

Perilaku ini lalai. Jika ada bug dan Anda bisa memperbaikinya. Lakukan. Tentu saja Anda harus melakukan yang terbaik untuk mencegah penambahan yang baru tetapi jika saya memperkenalkan satu bug kecil untuk setiap 10 bug serius yang saya perbaiki, itu bukan alasan yang sah untuk berhenti memperbaiki bug. Bahkan, itu adalah alasan bagus untuk terus memperbaiki bug .

Jadi semakin sedikit bug yang Anda perbaiki, semakin sedikit bug yang akan kembali kepada Anda di masa mendatang

Semakin sedikit bug yang Anda perbaiki, semakin banyak bug yang tersisa di perangkat lunak Anda, yang mengganggu pengguna Anda. Memang, mereka tidak akan "kembali kepada Anda di masa depan". Mereka tidak akan kembali karena mereka tidak pernah pergi. Gagasan "kembali" terkait dengan regresi. Sekali lagi, adalah mungkin untuk mengurangi risiko regresi.

Beberapa bug tidak dapat diperbaiki karena mereka menjadi sangat banyak digunakan sehingga orang-orang mulai bergantung pada mereka dan memperbaiki bug akan merusak program untuk para pengguna tersebut. Itu terjadi. Namun, dapatkah mereka dianggap bug dalam kasus itu?

Mentalitas "perbaiki bug, buat bug" mungkin terkait dengan Monster yang Mengerikan itu - kode yang sangat tidak dapat dibaca dan tidak dapat dipelihara sehingga hanya dengan menyentuhnya akan menciptakan bug. Jika Anda memiliki monster di basis kode Anda, Anda mungkin perlu membatalkan un-monsterify sebelum menyelesaikan sesuatu.

Akhirnya, jika Anda seorang programmer yang mengerikan, ada risiko apa pun yang Anda sentuh menciptakan bug baru. Ini jelas akan membuat programmer senior gugup. Namun, mengatakan "Jangan lakukan apa-apa. Jangan menyentuh apa pun. Jangan bernafas." mungkin bukan cara yang tepat untuk menciptakan lingkungan kerja yang sehat. Pendidikan lebih baik.

Kesimpulan:

• Perangkat lunak yang terus mendapatkan banyak fitur baru tetapi tidak ada perbaikan bug pasti akan menyedot.
• Perangkat lunak yang mendapatkan cukup banyak fitur baru tetapi memperbaiki bugnya memiliki peluang lebih besar untuk dapat digunakan.
• Mereka yang mencoba memiliki beberapa bug memiliki (rata-rata) lebih sedikit bug daripada mereka yang tidak peduli.
• Tidak masuk akal untuk mengharapkan suatu program pada akhirnya menjadi bebas bug.
• Pemrogram senior belum tentu kompeten.
• Perbaiki bug Anda.
• Adopsi metodologi yang meningkatkan kualitas perangkat lunak Anda.

Alasan untuk tidak menulis program bebas bug sebagian besar ekonomis.

Ada yang metode matematika untuk membuktikan kebenaran program. Dalam kursus Ilmu Komputer berkualitas tinggi mereka akan disebutkan. Ada bahasa pemrograman yang diciptakan khusus untuk tujuan ini. Secara teori, pemrograman tanpa bug adalah mungkin.

Ya, ada perangkat keras yang tidak sempurna yang kadang-kadang dapat mengubah nilai bit karena neutrino yang ditembakkan dari supernova yang jauh jutaan tahun yang lalu kebetulan mengenai prosesor Anda di tempat yang tepat. Oke, setiap teori memiliki asumsi dan abstraksi. Tetapi dengan asumsi bahwa prosesor berfungsi seperti yang diiklankan, ada alat matematis untuk memastikan program bekerja dengan benar juga.

Beberapa jawaban yang sangat dipilih dalam topik ini menyesatkan. Sebagai contoh, teorema ketidaklengkapan Gödel dan menghentikan masalah hanya menyiratkan bahwa Anda tidak dapat memiliki mis. Alat otomatis yang akan menentukan benar atau tidaknya suatu program. Tetapi kami tidak ingin memutuskan kebenaran suatu program, kami hanya ingin bukti kebenaran satu program tertentu .

(Secara analogis, hanya karena Anda tidak dapat menulis sebuah program untuk secara otomatis memutuskan kebenaran teorema matematika apa pun , itu tidak berarti Anda tidak dapat membuktikan satu teorema matematika tertentu .)

Masalahnya, sebaliknya, adalah ini:

Walaupun secara teori dimungkinkan untuk menulis program bebas bug, melakukannya akan sangat mahal . Menulis kode dengan bukti kebenarannya lebih rumit daripada hanya melemparkan sesuatu ke dinding untuk melihat apakah itu menempel. Bahkan jika "melihat apakah itu lengket" dilakukan oleh unit test; dan banyak programmer bahkan tidak repot melakukannya. Sebagian besar programmer bahkan tidak tahu bagaimana melakukan itu, yang berarti bahwa sebagai perusahaan Anda harus menyewa yang lebih mahal.

Mempertimbangkan semua biaya, pelanggan biasanya lebih senang dengan perangkat lunak murah yang bekerja dengan baik 99% dari waktu (dan 99,9% dari waktu setelah menginstal pembaruan tambahan) daripada memiliki mungkin perangkat lunak seribu kali lebih mahal yang bekerja dengan baik 100% dari waktu. Selain itu, pelanggan ingin memiliki perangkat lunak ini sekarang , dan tidak dalam sepuluh atau dua puluh tahun.

Oleh karena itu, orang-orang secara sadar memproduksi perangkat lunak yang memiliki beberapa kemungkinan bug, mencoba mencapai kombinasi optimal di mana bug tidak terlalu sering dan tidak terlalu serius, dan produksinya cukup cepat dan cukup murah. Kombinasi yang memberikan keuntungan paling banyak dalam kehidupan nyata. (Kadang-kadang itu bahkan berarti merilis perangkat lunak yang penuh bug sebelum pesaing Anda merilis sesuatu, dan hanya merilis versi 2.0 yang lebih layak ketika pesaing Anda siap untuk merilis versi layak pertama mereka.)

Jika Anda membekukan pengembangan selama itu perlu, dapatkah Anda benar-benar memperbaiki semua bug sampai tidak ada satu bug pun, jika hal seperti itu dapat diverifikasi oleh komputer?

Secara matematis, Anda bisa. Berbicara secara ekonomi, mengapa ada orang yang melakukan itu? Itu berarti menghabiskan mungkin dua puluh tahun dan beberapa juta dolar. Sementara itu, pelanggan menginginkan fitur baru, dan aplikasi beku Anda tidak dapat menyediakannya. Jadi ketika versi sempurna Anda sudah siap, pasar sudah diambil oleh pesaing Anda.

Penalaran secara ekonomi tidak masalah. Kita hidup di dunia di mana uang dan waktu penting. Tetapi hanya karena kita tidak melakukan sesuatu karena alasan ekonomi, kita tidak boleh berbicara omong kosong tentang bagaimana hal itu tidak dapat dilakukan bahkan dalam teori. Siapa tahu ... mungkin dalam beberapa tahun kita akan memiliki beberapa bahasa dan alat pemrograman baru yang bisa membuat pembuktian kebenaran menjadi mudah .

Tidak.

David Hilbert mengusulkan masalah kedua matematika pada tahun 1900 yang pada dasarnya meminta dunia untuk membuktikan bahwa aritmatika berfungsi sebagaimana dimaksud. Dia kemudian mengajukan " Entscheidungsproblem ", yang menanyakan hal serupa dalam istilah logis. " Teorema ketidaklengkapan pertama " Kurt_Gödel membuktikan pada tahun 1931 bahwa tidak ada teori aritmatika dasar yang konsisten dan lengkap. Representasi Alan Turing tentang Entscheidungsproblem sebagai " masalah terputusnya " memindahkan masalah langsung ke jantung pertanyaan ini, di mana ia membuktikan bahwa tidak mungkin untuk membuktikan apakah suatu program akan berjalan sampai selesai atau tidak. Mengingat bahwa tidak dapat dihargai, juga tidak mungkin untuk membuktikan apakah suatu program memiliki bug atau tidak.

Tidak ada yang membebaskan programmer yang berlatih di antara kita dari berjuang untuk tidak ada bug. Itu hanya berarti bahwa kita tidak dapat berhasil secara umum.

Salah humanum est

Bahkan jika Anda menulis kode dengan bahasa formal, seperti metode B , yang dapat Anda gunakan untuk membuktikan secara matematis bahwa persyaratan terpenuhi,

Bahkan jika Anda menggunakan bahasa spesifikasi formal,

Selalu ada langkah manusia yang terdiri dalam mengekstraksi kebutuhan pengguna dari satu atau lebih otak ke komputer.

Langkah manusia ini rawan kesalahan, dan cacing ada di dalam apel.

Proporsi "bug" yang saya temui mungkin lebih tepat digambarkan sebagai ketidakcocokan antara desain sistem dan harapan pelanggan.

Sekarang, apakah kita menyebut bug ini atau tidak itu bersifat akademis, tetapi faktanya tetap bahwa banyak pekerjaan pemeliharaan muncul sebagai akibat langsung dari komunikasi yang tidak sempurna dan menggeser harapan pelanggan.

Bahkan jika suatu sistem secara teknis, terbukti "benar" dalam arti memenuhi spesifikasi, (betapapun mustahil yang mungkin untuk perangkat lunak komersial dunia nyata), maka Anda masih akan memiliki masalah mencocokkan fungsi perangkat lunak dengan pelanggan Anda selamanya. harapan yang berubah dan tidak jelas.

Pendeknya:

Tidak.

Jika Anda memiliki spesifikasi yang cukup ketat dan terbatas, Anda mungkin dapat membuktikan program bebas bug, tetapi hanya didasarkan pada asumsi yang tidak dapat dibuktikan tentang berfungsinya segala sesuatu dengan benar dalam sistem. Ini berarti bahwa tidak ada cara untuk membuktikan bahwa spesifikasi akan dianggap benar oleh siapa pun yang mengajukan masalah asli, atau oleh siapa pun yang menggunakan layanan ini.

Saya menemukan bagian Jim Shore No Bugs bacaan yang sangat berguna tentang topik ini. Bentuk singkat: Tidak mungkin dikembangkan tanpa menghasilkan bug - tetapi kami dapat bekerja sedemikian rupa sehingga kami dapat mendeteksinya sedini mungkin.

Selama produksi kode itu sendiri. Misalnya dengan menulis dan menjalankan Tes Unit sering selama pengembangan, kami selalu memastikan kode melakukan apa yang seharusnya dilakukan. Juga, berguna untuk menulis ulang kode yang ada secara terus-menerus sedemikian rupa sehingga paling jelas mengungkapkan perilaku sistem yang dimaksud.

Namun, dalam kasus Anda, Anda berbicara tentang basis kode yang sudah ada dengan jutaan baris kode. Jika Anda ingin mendapatkan bug sistem gratis, pertama-tama Anda harus tahu apa "bug" untuk sistem ini. Anda dapat menulis serangkaian tes post-hoc yang memastikan fungsionalitas sistem (jika belum ada). Web pengujian tersebut dapat berfungsi sebagai perkiraan perkiraan untuk perilaku sistem yang benar. Tetapi semakin banyak kode yang Anda miliki, semakin banyak upaya yang dilakukan dalam latihan semacam itu. Oleh karena itu, sebagian besar perusahaan membuat kompromi: mereka hidup dengan yang tidak sempurna, bekerja dengan daftar bug dan pemeliharaan untuk mengeluarkan bug yang paling menyebalkan dari sistem.

Tentang verifikasi oleh bagian komputer.

Ada dua cara untuk memverifikasi suatu program menggunakan komputer. Salah satunya adalah pengujian, yang lain menggunakan sistem bukti.

Segera setelah pengujian menyeluruh tidak memungkinkan, pengujian menjadi tidak dapat menunjukkan bahwa suatu program tidak memiliki bug, hanya saja ada beberapa. (Dan Anda memiliki masalah untuk menunjukkan bahwa pengujian Anda sendiri tidak menguji keberadaan bug).

Untuk menggunakan sistem bukti, Anda mulai dari persyaratan formal (dan mereka sendiri mungkin memiliki bug, semoga bahasa yang digunakan untuk persyaratan akan lebih cocok untuk meyakinkan diri sendiri bahwa tidak ada bug di sana daripada dengan bahasa pemrograman) dan membangun / membuktikan dengan bantuan sistem pembuktian bahwa program ini bebas bug (dan ada pertanyaan tentang bug dalam sistem pembuktian, tetapi mereka membuktikan diri mereka benar). Keadaan saat ini adalah kompiler untuk himpunan bagian C (dan himpunan itu tidak akademis, "CompCert mendukung semua himpunan bagian MISRA-C 2004 dari C, ditambah banyak fitur yang dikecualikan oleh MISRA").

Tidak, karena lingkungan komputer dan perangkat lunak tempat aplikasi berjalan akan terus berubah walaupun kode dibekukan. Sistem operasi terus berkembang dengan tambalan dan perbaikan, serta perangkat dan driver. Hanya ketika Anda berpikir bahwa Anda telah mencapai titik tidak ada bug yang diketahui, AMD atau nVidia akan merilis pembaruan driver video yang berdampak pada bagaimana Anda berinteraksi dengan subsistem video. Sekarang aplikasi Anda memiliki cacat visual (seperti berkedip, berkedip, atau pengurangan laju bingkai) untuk pelanggan yang memiliki kartu video atau konfigurasi tertentu (SLI? LOL).

Selain perangkat keras dan OS, ada juga sejumlah produk middleware di bawah sebagian besar aplikasi signifikan yang juga akan berkembang di luar kendali Anda, dan sama seperti Anda mendapatkan kode Anda ke keadaan cacat nol, lapisan di bawahnya Anda mendapatkan EOL'ed.

Teknologi berkembang, juga bisnis yang memanfaatkan teknologi, dan gagasan "membebaskan" kode tidak mungkin atau tidak mungkin dilakukan. Bisnis yang meminta set fitur baru tidak akan merespons dengan baik "kami memiliki kode yang dikunci sementara kami mengejar semua bug yang dikenal dan tidak ada yang melaporkan cacat perangkat lunak yang valid dalam X bulan". Bahkan jika bisnis membeli garis itu, setelah X bulan mereka akan bertanya bagaimana fitur baru datang, dan jawabannya tidak bisa "kami memutuskan untuk memperpanjang pembekuan karena Oracle hanya merilis tambalan dan kami perlu mengambil X bulan lagi untuk menyatakan itu ".

Tidak, pada titik tertentu bisnis akan mencari tim pengembangan yang lebih fleksibel yang mendukung kebutuhan untuk bergerak maju dengan kecepatan teknologi. Ini adalah masalah mendasar yang dihadapi oleh tim pengembangan modern.

Ya tapi Anda tidak akan pernah tahu pasti. Semakin keras Anda mencari, semakin banyak yang akan Anda temukan. Semakin berat sistem yang digunakan dan semakin banyak kasus tepi yang digunakan, semakin Anda akan menemukan ketidakcocokan lain dengan maksud atau spesifikasi asli. Ini menyiratkan bug itu sendiri bukanlah hal yang tepat dan akan sering tergantung pada interpretasi, pada seberapa buruk beberapa individu menilai suatu anomali yang dirasakan.

Itu hal yang kabur. Beberapa sistem ditentukan hingga bit terakhir. Jika suatu sistem berfungsi dengan baik dan pengguna tidak memiliki keluhan (mereka tidak disadap oleh apa pun) dan mereka benar-benar beradaptasi dengannya, Anda dapat menyebutnya bebas bug.

Dimungkinkan untuk secara konsisten memberikan perangkat lunak bebas-bug, mengingat disiplin yang memadai dan budaya tim bersama. (Dan kode modular yang diperhitungkan dengan baik, serangkaian pengujian otomatis yang komprehensif, memeriksa cacat dan mengadaptasi proses Anda, dan banyak hal lain yang membutuhkan upaya dan kerendahan hati tetapi membayar kembali ribuan kali lipat)

Tetapi melakukan ini, Anda biasanya tidak memulai untuk membangun sistem 20 MLOC. Jika menulis kode bebas bug bukanlah tujuan Anda, tidak juga harus membangun banyak sistem MLOC.

Alasan saya sendiri adalah sebagai berikut:

Beberapa orang memiliki kebutuhan untuk dipenuhi. Beberapa orang (mungkin sama, mungkin berbeda) memiliki anggaran untuk memenuhi kebutuhan melalui perangkat lunak penulisan. Semua orang ini berharap mendapat manfaat untuk uang mereka.

Orang dengan anggaran akan membayar sejumlah orang (mungkin sama, mungkin berbeda) disebut pemrogram , sehingga pemrogram ini akan mengubah sejumlah waktu yang disepakati menjadi perangkat lunak yang memenuhi kebutuhan.

Oleh karena itu programmer ini bekerja mengubah uang orang lain menjadi perangkat lunak yang memenuhi kebutuhan. Adalah tanggung jawab mereka untuk memanfaatkan uang ini dengan baik.

Ini memiliki implikasi berikut sehubungan dengan pertanyaan Anda:

• Mengingat ada bug dalam perangkat lunak, apakah Anda akan memperbaikinya sama sekali? Anda memerlukan programmer untuk memperbaiki bug, dan programmer akan membutuhkan biaya. Seorang programmer tidak dapat memutuskan apakah akan menghabiskan uang untuk melakukannya. Ini adalah peran orang yang memegang anggaran.
• Bisakah saya membuat perangkat lunak 20MLOC dari awal tanpa meninggalkan bug yang tidak diperbaiki pada akhirnya? Nah, berangkat untuk membangun 20MLOC diperlukan dengan niat menghabiskan banyak uang. Ini bodoh secara finansial. Dan itu tidak dibangun dalam satu hari. Tetapi perangkat lunak adalah untuk kebutuhan saat ini, bukan besok. Akan ada upaya yang salah arah dalam memparalelkan pengembangan dengan merekrut banyak programmer. Tapi kemudian, kemungkinan besar Anda tidak akan mendapatkan budaya bersama dan bug akan terjadi, pemborosan dan penundaan akan terjadi, dan uang akan habis untuk memperbaikinya. Saya belum melihat sistem bebas bug sebesar ini. (Saya telah melihat sistem bebas bug dan sistem 20MLOC, tetapi tidak sama)
• Saya bertanggung jawab untuk memelihara sistem 20MLOC yang tidak saya tulis. Apakah saya dapat mencapai nol bug yang dikenal? Ini tidak tergantung pada programmer. Mereka tidak dapat memutuskan untuk memperbaiki bug karena itu bukan uang mereka. Apakah ada cukup ROI untuk memperbaiki bug yang tersisa? Nah, sistem telah ada selama beberapa waktu sekarang, dan pengguna sudah terbiasa, dan menggunakan kebiasaan sistem untuk keuntungan mereka dalam pekerjaan sehari-hari mereka. Jika Anda memperbaiki bug pada prinsipnya, orang dengan uang itu mungkin harus membayar untuk membangun kembali beberapa fitur yang tidak ditentukan yang menghilang dari sistem, bahkan menghabiskan lebih banyak uang.

Ini semua tentang uang, dan memang begitu.

Iya.

Tapi seperti yang Anda tahu, itu membutuhkan terlalu banyak upaya untuk menjadi layak.

Sebelum saya dapat mempertahankan jawaban saya, pertama-tama kita harus mendefinisikan apa itu bug:

• Bug adalah perilaku yang bertentangan dengan spesifikasi.
• Namun, gangguan dalam spesifikasi (misalnya hukum robot ke-0) tidak dihitung sebagai bug perangkat lunak.
• Fitur tambahan tidak dihitung sebagai bug, kecuali dilarang oleh spesifikasi.
• Demi argumen, kontradiksi dalam spesifikasi tidak dihitung sebagai bug perangkat lunak.

Sekarang, semoga Anda sudah tahu, arsitektur perangkat lunak yang baik bersifat modular, sehingga setiap modul dapat diuji unit (atau diuji secara manual, atau apa pun) secara terpisah. Melalui pengujian disiplin dan hati-hati, dimungkinkan untuk menulis modul individual yang tidak memiliki bug di dalamnya.

"Tapi tunggu!" Saya mendengar Anda protes, "Bagaimana jika perilaku yang tidak terduga (tetapi tetap benar) dari satu modul menyebabkan bug di modul lain?" Kemudian bug ada di modul kedua. Modul bebas bug dapat diperlakukan sebagai API, dan API, seperti yang Anda ketahui, memerlukan perhatian agar dapat digunakan dengan benar.

Menulis kode anti peluru membutuhkan pengetahuan luas tentang kasus tepi dan logika aliran pada bagian pengembang, dan sebagian besar pengembang perangkat lunak tidak cukup pintar untuk belajar atau tidak peduli. Atau lebih sering, mereka berada di tenggat waktu.

"Tapi beri aku tempat untuk berdiri, dan aku akan memindahkan dunia." - Archimedes