it-swarm-id.com

Bagaimana cara menjadi programmer zero-bug?

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 benar-benar 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?

168
Elaine

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.

365
wildpeaks

Tidak ada bug yang mustahil untuk program non-sepele.

Dimungkinkan untuk menjadi sangat dekat, tetapi produktivitas menderita. Dan itu hanya bermanfaat untuk perangkat lunak berisiko tinggi tertentu. Perangkat Antar-Jemput Antariksa 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 melibatkan hanya 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.

124
CodesInChaos

"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 pintar seperti wabah. [Edsger Dijkstra]
  • Fight 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!
98
Maglob

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 telah menemukan bahwa menulis mentimun tes gaya 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 sudah ada yang tidak saya pahami sepenuhnya tanpa khawatir 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 jebakan pemula ke cache data yang dapat diubah untuk meningkatkan kinerja).

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

25
Pete

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

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

19
user7007

Ya, tidak mungkin untuk tidak pernah 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. Kode kurang 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 masuk hitungan jika ini adalah kekacauan rumit yang tidak jelas. Code golf memang menyenangkan tapi itu 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, 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 harus 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.
17
AmaDaden

Tidak ada bug? Kedengarannya seperti Anda perlu LISP (ikuti jalur skeptis dan hindari video musik).

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

Menjaga kode sesederhana mungkin akan membantu Anda menghindari bug.

Pastikan Anda menggunakan alat analisis kode (seperti FindBugs , PMD dan seterusnya) yang - digabung dengan peringatan compiler 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 membuat kode dengan cara yang memperkenalkan bug itu lagi.

8
Gary Rowe

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 Edge yang tidak pernah dipikirkan oleh pengembang.
  • Pengembang pandai coding. Biarkan mereka kembali ke apa yang mereka Excel (dan biasanya apa yang mereka suka lakukan.)
  • 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 dapat melakukannya secara berlebihan.

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

8
Sebastien Martin

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

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 trial and error adalah cara yang valid untuk menyelesaikan beberapa masalah, seringkali 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 kode yang Anda tulis pada sistem yang ada. Akankah bug muncul? Ya tentu saja. Tetapi bug ini akan 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.

8
Patrick Klug

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 adanya 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.

7
FabianB

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.

6
JeffO

Saya setuju dengan yang lain. Begini cara saya mendekati masalah

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

Anda dapat 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.

5
dietbuddha

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 apapun yang saya bisa untuk menghilangkannya.

Setelah ini menjadi sikap Anda, bug akan turun dengan cepat. 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, begitu Anda melihatnya adalah mungkin untuk menulis perangkat lunak yang baik, hasrat Anda untuk kerajinan Anda akan tumbuh.

4
Darren

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 adalah 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.)

  • Memiliki 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.

2
Stephen C

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

1
angryITguy

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 ke 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.

1
Alexei Polkhanov

Jika kita mengasumsikan rumah perangkat lunak besar ketahui cara mendapatkan pengembang terbaik (seperti pada programmer nol bug ) kita dapat mengurangi 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 bersama-sama. 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 aman sempurna , tidak ada sistem bug-less yang kompleks.

0
Robert Koritnik

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 oksigen, dan Anda harus dapat mengetahui dengan tepat apa yang dilakukan semua kode Anda dan memperbaiki bug yang muncul, sangat efisien.

0
Jason McCarrell

Mungkinkah ini akibat dari kesalahpahaman tentang metodologi baik , dan bukan hanya keketatan generik?

Maksud saya adalah bahwa mungkin bos Anda mendengar tentang "metodologi nol cacat" (lihat bagian no.5), dan tidak repot-repot memahami apa artinya itu?
Tentu saja, tidak nyaman bagi manajemen untuk menunda pengembangan fitur baru, lebih menyukai bug yang Anda tidak boleh dimasukkan ...
Dan tentu saja, itu mengancam bonusnya, jadi tentu saja Anda tidak akan mendapatkannya karena "programmer yang baik tidak memiliki bug" ...

Tidak masalah untuk membuat bug, selama Anda dapat menemukan mereka dan perbaiki mereka (tentu saja dengan alasan).

0
AviD

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"

0
SpacePrez