Apa yang Anda anggap sebagai penyebab utama cacat perangkat lunak (dan cara menguranginya) [ditutup]

Saya mendefinisikan cacat sebagai:

"Sesuatu dalam desain aplikasi atau kode yang mencegahnya berfungsi sesuai persyaratan."

Saya mencari ide tentang penyebab cacat, misalnya faktor manusia, kurangnya pengujian, kurangnya prototipe, dan kemungkinan ide untuk mengurangi ini.

Penyebab utama cacat perangkat lunak adalah interpretasi.

Interpretasi pelanggan dari suatu fitur berbeda dari interpretasi desainer.

Interpretasi desainer berbeda dari interpretasi programmer.

Sebagian besar metodologi telah menemukan cara untuk mengatasi efek ini. Tetapi pada akhirnya, kita hanya manusia dan kita tidak sempurna. Selain itu, seringkali ada tekanan waktu dan sebagian besar sihir metodologi sering dilewati saat berada di bawah tekanan.

Pengujian hanya dapat mendeteksi masalah sejak dini. Tetapi bahkan penguji adalah manusia, dan tidak mungkin untuk menguji 100%. Jika Anda ingin melepaskannya sebelum alam semesta berakhir.

Saya menganggap penyebab utama cacat perangkat lunak adalah programmer.

Tidak mengatakan itu hanya untuk menjadi lucu, tetapi karena salah satu masalah besar yang saya amati di pekerjaan saya adalah pengumpulan persyaratan yang buruk, ditambah dengan pemahaman yang buruk tentang domain masalah, menyebabkan masalah utama pada masalah cacat dan kegunaan.

Sebagian dari itu berasal dari tidak mau belajar / memahami terminologi pengguna akhir, menyebabkan kesalahpahaman.

Sebagian dari itu berasal dari berbicara teknologi terlalu dini dalam proses untuk orang-orang yang tidak tahu apa yang Anda bicarakan atau mengapa itu penting.

Contoh terbaik dari itu adalah ketika saya mendengar salah satu programmer mencoba untuk mencari tahu berapa lama pertanyaan / jawaban dalam karakter ... Saya tahu dia sedang mencoba mencari tahu ukuran bidang apa yang akan digunakan dalam database, tetapi departemen yang meminta ini bukan alasan mengapa hal itu penting - atau ruang yang diperhitungkan. Bagi kami itu tampak jelas, tetapi bagi mereka itu adalah wahyu yang nyata.

Penyebab utama cacat adalah manajemen yang buruk ;)

Serius, pengembang yang bekerja dalam kondisi baik, yang tidak diminta untuk bekerja terlalu keras, mengurangi kualitas, memiliki alat yang tepat, kondisi kerja yang tenang dan sebagainya akan menghasilkan lebih sedikit bug daripada seseorang yang bekerja di bawah tekanan keras.

Juga manajemen mempekerjakan pengembang yang buruk juga membantu meningkatkan jumlah bug.

Manajemen yang buruk .

(penafian: Saya seharusnya merekrut & mengelola pengembang)

Saya tidak melihat satu penyebab utama - tetapi satu penyebab yang belum disebutkan adalah kopling yang tidak disengaja dengan kode lain . Menulis kode yang memiliki efek samping yang tidak terlihat, menerobos lapisan abstraksi, membuat asumsi tentang data (variabel tidak akan, konstanta tidak, dan tidak ada input dari pengguna yang aman), berkutat dengan hal-hal yang tidak perlu dikhawatirkan. itu sendiri dengan, dan sebagainya.

Sebagian besar praktik pengembangan yang saya pelajari menjadi berkurang N, karena kompleksitas suatu program setidaknya O(N^2)dan mungkin O(k^N). Mendefinisikan Ndibiarkan sebagai latihan untuk pembaca, tapi saya memikirkan hal-hal seperti kompleksitas siklomatik di sini. Enkapsulasi logika dan data memiliki efek mengurangi N dengan mengelompokkan masalah.

Ketidakmampuan untuk memikirkan segalanya.

Tidak lengkap

Kesenjangan komunikasi. Dalam pengumpulan persyaratan. Sesuai jadwal. Dalam dokumen desain. Dalam spesifikasi fungsional. Dalam kode (kesenjangan antara apa yang diinginkan programmer dan apa yang dia katakan kepada kompiler).

Etika sosial. Secara sosial tidak dapat diterima untuk memanggil seseorang yang tidak mampu.

Bergegas ke dalam hal-hal tanpa sepenuhnya memahaminya. Mulai menulis kode tanpa sepenuhnya memahami persyaratan fungsional atau arsitektur teknis.

Pemrograman harus hampir otomatis, hanya menuliskan apa yang sudah jelas dan sudah dipikirkan. Dalam praktiknya, saya melihat banyak kode menggapai-gapai untuk mencoba menangani apa yang seharusnya dilakukan oleh kode. Saya sendiri sudah bersalah beberapa kali.

Errare humanum est

Jadwalkan Tekanan merupakan sumber yang kuat.

Pengembang yang tergesa-gesa tidak meluangkan waktu untuk secara penuh menentukan persyaratan, atau sepenuhnya memahami maksud di balik persyaratan, atau menyelidiki sepenuhnya alternatif untuk menemukan solusi terbaik, atau sepenuhnya memikirkan semua kasus tepi dan interaksi dari perubahan yang mereka buat, atau mengembangkan satu set penuh kasus uji, atau sepenuhnya melakukan semua uji unit, atau melakukan uji integrasi penuh, atau sepenuhnya mempertimbangkan ketergantungan platform, atau sepenuhnya menguji installer, atau mendokumentasikan sepenuhnya apa yang telah mereka lakukan sehingga pengembang selanjutnya dapat memahami ....

Hal lain yang harus disebutkan adalah tidak melakukan tes orang luar. Ketika pengembang menulis tes dan menjalankannya, ia hanya menguji interpretasinya bukan persyaratan sebenarnya. Sementara unit test yang ditulis oleh devs berguna untuk menangkap beberapa bug, sebagian besar bug telah lulus tes ini tetapi tidak sesuai dengan keinginan atau kebutuhan pengguna. Perangkat lunak apa pun yang tidak diuji oleh orang lain selain pengembang tidak diuji (Dan maksud saya tidak hanya menjalankan tes pengembang).

Itu karena rekayasa perangkat lunak pada dasarnya rumit. Esai "No Silver Bullet" membahas hal ini.

Ironisnya, banyak jawaban lain di sini menyentuh topik-topik yang "tidak sengaja rumit", dalam bahasa esai itu, sedangkan pada kenyataannya sebagian besar yang dilakukan pengembang perangkat lunak "pada dasarnya kompleks", jadi hanya dalam sifat itulah yang menciptakan perangkat lunak itu sulit, perangkat lunak akan memiliki bug, dan tugas kita adalah menanganinya.

Kegagalan untuk memahami perangkat lunak sebagai jaringan mesin negara, prinsip-prinsip yang mendasari operasi mereka (negara, tekad dan transisi mereka), dan interaksi mesin negara.

Menulis kode yang gagal secara diam-diam vs. kode yang melaporkan semua kesalahan.

Kurangnya memeriksa hal-hal yang "tidak dapat terjadi" atau tidak mungkin terjadi adalah hal yang besar. Terkadang yang sempurna adalah musuh orang baik. Jika tidak layak hierarki pengecualian yang dipikirkan dengan matang, beberapa penanganan cepat dan kotor selalu lebih baik daripada tidak sama sekali. Saya seorang besarpenggemar gagal cepat, menegaskan dan meninggalkan menegaskan yang memiliki dampak diabaikan pada kinerja dalam rilis rilis. Bahkan dalam skrip satu-off cepat dan kotor di mana saya mengontrol semua data input, saya memasukkan beberapa penanganan kesalahan cepat / kotor, biasanya hanya dengan fungsi yang setara dengan menegaskan tetapi tetap di sepanjang waktu. Aturan praktis saya adalah bahwa, jika itu tidak mungkin terjadi atau Anda pikir itu tidak dapat terjadi, itu tidak perlu gagal dengan anggun dengan pesan kesalahan yang ramah pengguna, tetapi setidaknya harus gagal cepat dengan pesan kesalahan yang memberi programmer beberapa petunjuk tentang apa yang salah.

Sunting: Salah satu taktik berguna yang terkait adalah menggunakan asserts sebagai alat debugging utama dan membiarkannya di sana setelah sesi debugging selesai. Sejak saat itu, basis kode Anda akan memiliki beberapa pemeriksaan kewarasan bawaan yang membuatnya sangat sulit untuk bug terkait untuk terjadi lagi. Ini sangat berguna untuk kode yang sulit untuk disatukan.

Penyebab utama cacat perangkat lunak adalah menulis kode.

Tulis lebih sedikit kode dan Anda akan memiliki lebih sedikit bug ;-)

Pada satu tingkat, manajemen. Tapi itu bukan hanya PHB. Ini adalah pengelolaan kode itu sendiri, yang mungkin atau mungkin bukan cerminan dari manajemen perusahaan.

Para peserta di seluruh "siklus hidup" perlu sepenuhnya diinvestasikan dalam kualitas dan membuat produk yang tidak mati . Perangkat lunak itu sendiri memiliki janji untuk tidak pernah putus, mengingat keandalan abstraksi yang tepat. Ini hanya pertanyaan apakah konstruktor perangkat lunak tertarik untuk memiliki operasi yang sempurna.