Berapa redundansi / ketahanan yang harus diterapkan oleh perangkat lunak yang kompleks?

Fokus pertanyaan ini: Beberapa perangkat lunak melakukan "kerja ekstra" untuk meningkatkan peluang hasil "akhirnya berhasil / memuaskan", meskipun ada satu atau lebih kesalahan internal dalam perangkat lunak, yang memerlukan waktu eksekusi yang lebih lama ketika kesalahan tersebut terjadi. Semua ini terjadi tanpa sepengetahuan pengguna jika hasilnya berhasil.

Definisi perangkat lunak yang kompleks:

• Berisi kode yang ditulis oleh (disumbangkan dari) lebih dari 10 pengembang selama masa pakainya, dan tidak ditulis dalam kerangka waktu yang sama
• Tergantung pada lebih dari 10 perpustakaan eksternal, masing-masing dengan peringatan
• Tugas perangkat lunak tipikal (untuk menghasilkan hasil yang diinginkan oleh pengguna) memerlukan 10 atau lebih parameter input, di mana kebanyakan dari mereka memiliki nilai default tetapi dapat dikonfigurasi jika pengguna membutuhkan kontrol.
• Yang paling penting, perangkat lunak yang memiliki kompleksitas yang sesuai relatif terhadap tugas yang dilakukan, yaitu tidak perlu rumit .

Diedit: Apa itu kompleks? Silakan lihat Ada perbedaan besar antara Kompleks dan Rumit . (tautan langsung)

Definisi Redundancy / Robustness dalam pertanyaan ini :
(Ditambahkan Robustness berdasarkan komentar)

• Jika tugas perangkat lunak gagal ketika set parameter saat ini digunakan, coba berbagai parameter.
  • Jelas, harus ada pengetahuan di dalam bahwa parameter "berbeda" menggunakan jalur kode yang berbeda, mungkin menghasilkan hasil yang berbeda (semoga lebih baik).
  • Kadang-kadang jalur kode yang berbeda ini dipilih berdasarkan pengamatan dari perpustakaan eksternal.
• Pada akhirnya, jika tugas aktual yang dilakukan sedikit berbeda dari spesifikasi pengguna, pengguna akan menerima laporan yang merinci perbedaan tersebut.
• Akhirnya, seperti 10-parameter yang dapat dikonfigurasi, redundansi dan pelaporan juga dapat dikonfigurasi.

Contoh perangkat lunak tersebut:

• Migrasi Basis Data
  • Database bisnis
  • Basis data kendali sumber, dll.
• Batch mengkonversi antara dokumen Word dan dokumen OpenOffice, PowerPoint dan OpenOffice Draw, dll.
• Terjemahan otomatis seluruh situs web
• Analisis otomatis paket perangkat lunak, seperti Doxygen, tetapi di mana analisis perlu lebih dapat diandalkan (yaitu bukan hanya alat dokumentasi)
• Komunikasi jaringan, di mana paket mungkin hilang dan sejumlah percobaan ulang diharapkan

Pertanyaan ini awalnya terinspirasi dari Bagaimana Anda menangani kode yang sengaja buruk?
tetapi sekarang fokus hanya pada salah satu penyebab software mengasapi. Pertanyaan ini tidak membahas penyebab lain dari mengasapi perangkat lunak, seperti penambahan fitur baru.

Mungkin terkait:

• Cara menangani kode kompleks dalam proyek (besar)
• Bagaimana orang dapat menulis dan memelihara kode yang sangat rumit dan sulit dibaca?

Ini adalah pertanyaan bisnis, bukan pertanyaan teknis.

Terkadang saya mengkode dengan peneliti atau menggunakan prototipe, jadi kami akan membangun sesuatu dengan ketahanan yang sangat rendah. Jika rusak, kami memperbaikinya. Tidak ada gunanya berinvestasi dalam sihir tambahan jika kita akan segera membuang kode itu.

Tetapi jika pengguna sistem Anda membutuhkannya agar kuat, Anda harus membangunnya seperti itu. Dan Anda harus membuatnya kuat secara khusus dengan cara yang Anda dan mereka perlu memaksimalkan kesuksesan jangka panjang, sambil mengabaikan jenis redundansi / kekokohan yang tidak mereka butuhkan.

Secara umum, saya mulai kasar dan kemudian menambah ketahanan dari waktu ke waktu. Saya sering mengajukan pertanyaan seperti ini bagian dari proses perencanaan normal. Saya biasanya bekerja dengan gaya Extreme Programming, di mana kami membuat daftar panjang fitur yang diinginkan, dan saya juga memasukkan fitur robustness. Misalnya, "Sistem bertahan dari kegagalan setiap kotak tunggal," dicampur dengan hal-hal seperti "Pengguna dapat bergabung menggunakan kredensial Facebook." Apapun yang muncul lebih dulu, saya yang membangun terlebih dahulu.

Software yang kompleks biasanya adalah berlebihan karena Anda mungkin tahu, tapi jelas bukan karena itulah cara terbaik untuk melakukannya tetapi karena pengembang cenderung "taktik pada" kode yang ada daripada upaya untuk memahami secara detail cara kerja perangkat lunak.

Namun, jika Anda bertanya kepada saya berapa banyak redundansi yang dapat diterima, saya tidak akan mengatakan apa pun. Redundansi adalah salah satu dari banyak efek samping kompleksitas, archnemesis of simplicity. Bisa dibilang, kesederhanaan harus mengambil kursi belakang jika waktu lebih penting, meskipun saya menekankan bahwa mereka yang berpendapat bahwa waktu adalah esensi jarang mereka yang benar-benar berhati-hati dalam mengembangkan perangkat lunak. Biasanya manajer proyek Anda meminta Anda untuk menyelesaikan pekerjaan sesegera mungkin sehingga Anda dapat kembali ke masalah yang lebih mendesak, namun tugas Anda sebagai programmer untuk mengetahui kapan pekerjaan itu dilakukan. Saya pikir pekerjaan itu tidak selesai sampai Anda berhasil mengintegrasikannya ke dalam program sebagaimana mestinya. Mungkin programnya rumit,

Namun harus dikatakan bahwa dalam melakukannya, Anda mungkin harus menghasilkan kode yang berlebihan. Jika proyek sudah sangat berlebihan, mungkin sebenarnya lebih mudah untuk melanjutkan pola dengan asumsi tentu saja bos Anda tidak memiliki waktu beberapa minggu untuk membunuh sehingga Anda dapat merestrukturisasi seluruh proyek.

Sunting: Mengingat pengulangan pertanyaan, saya akan menambahkan sedikit tentang ketahanan. Menurut pendapat saya, pemeriksaan parameter harus dilakukan hanya jika A) Anda menerima format yang sangat spesifik seperti nilai tanggal sebagai string atau B) berbagai parameter berpotensi bertentangan satu sama lain atau saling eksklusif.

Dengan A), persyaratan yang cocok dengan parameter format tertentu biasanya penting untuk keperluan metode (seperti konversi ke tanggal dari string). Secara teknis itu masih bisa terjadi dalam program Anda tanpa menjadi keharusan tetapi saya akan sangat menyarankan Anda untuk menghilangkan kemungkinan ini dan hanya menerima parameter yang Anda tahu mewakili jenis data yang Anda cari (Terima tanggal daripada string jika titik bukan untuk mengkonversi misalnya. Jika konversi juga harus dilakukan, gunakan metode utilitas untuk mengubah string sebelum meneruskannya ke metode).

Sedangkan untuk B), parameter yang saling eksklusif mewakili struktur yang buruk. Seharusnya ada dua kelas, satu yang menangani satu kasus dan yang lain yang menanganinya dengan cara lain. Semua operasi umum dapat dilakukan dalam satu kelas dasar untuk menghindari redundansi.

Dalam situasi di mana jumlah parameter untuk suatu metode menjadi 10+, saya mulai mempertimbangkan file properti yang berisi semua parameter ini yang kemungkinan besar tidak akan sering berubah. Jika mereka berubah, Anda dapat menyimpan default di file properti dan menambahkan metode "setPropertyName ()" yang memungkinkan Anda menimpa default saat runtime.

Perangkat lunak harus memaafkan kesalahan pengguna, dan sepenuhnya tidak toleran terhadap kesalahan programmer.

Artinya, perangkat lunak harus sangat kuat dan memungkinkan pemulihan yang mulus untuk hal-hal seperti kesalahan input pengguna, dan kesalahan konfigurasi sistem. Paling tidak sebuah pesan kesalahan ramah yang menyatakan di mana kesalahan terjadi (kotak input, file konfigurasi, argumen baris perintah, dll ...) dan kendala apa yang dilanggar ("harus kurang dari X karakter," "pilihan yang valid adalah [X , Y, Z] ", dll ...) Untuk kekokohan tambahan, perangkat lunak dapat menyarankan alternatif, atau menggunakan default yang wajar (tetapi harus selalu menunjukkan bahwa itu tidak menggunakan persis apa yang ditentukan pengguna).

Saya tidak dapat memikirkan banyak situasi di mana coba ulang otomatis dengan standar yang berbeda diperlukan, tetapi ada beberapa (coba ulang otomatis untuk membuat tautan komunikasi tampaknya masuk akal). Saya setuju dengan @ William bahwa tingkat 'redundansi' ini adalah keputusan bisnis.

Di sisi lain, seharusnya tidak ada ketahanan run-time terhadap kesalahan programmer. Jika ada pra-kondisi untuk parameter fungsi, mereka harus diperiksa dengan menegaskan, bukan pemeriksaan run-time. Ini adalah kesalahan besar saya untuk melihat pengecekan dan pelaporan kesalahan eror berlebihan pada parameter yang sama tiga atau empat tingkat ke dalam tumpukan panggilan:

 int A(int x)
 {
   if (x==0) return -1
   ...
 }
 int B(int x)
 {
   if (x==0) return -1
   err = A(x)
   if (err) return err;
   ...
 }
 // and so on and so on....

Ini hanya kompleksitas tambahan yang tidak dibutuhkan. Anda tidak harus menghabiskan waktu mencari tahu bagaimana satu fungsi harus menangani kesalahan yang diperkenalkan dengan menyalahgunakan yang lain. Jika ini adalah jenis 'ketahanan' yang Anda maksud - Anda tidak membutuhkannya. Ganti dengan konfirmasi dan pengujian integrasi menyeluruh.

Itu persyaratan.

Apakah ada persyaratan untuk ketahanan?

"Ketika tautan komunikasi gagal, paket yang salah dibuang" "Ketika tautan melanjutkan operasi, tidak ada transaksi yang diproses dua kali"

harus ada kasus penggunaan untuk pemulihan kesalahan (jika tidak, bagaimana Anda tahu bagaimana itu akan terjadi?)

Membiarkannya ke programer untuk menemukan ketahanan ketika mereka pergi (jika diperlukan) menghasilkan sistem "ajaib".

Semua sistem ajaib menjadi sihir yang buruk seiring waktu. Koreksi kesalahan di latar belakang menyembunyikan terjadinya kesalahan, sehingga kesalahan tidak akan diperbaiki, sehingga sistem pada akhirnya akan menurun ke keadaan entropi yang lebih besar; dan jalankan seperti omong kosong, karena mengoreksi kesalahan sepanjang waktu. Anda harus memiliki batas untuk menghentikan sistem memasuki kondisi terdegradasi secara permanen.

Beberapa operasi mungkin memerlukan pendekatan "coba lagi", terutama jika mereka bergantung pada sumber daya eksternal seperti database. Misalnya, jika database tidak dapat terhubung atau kueri gagal, operasi mungkin akan dicoba beberapa kali sebelum menyerah dan melempar kesalahan ke tingkat yang lebih tinggi. Namun, dalam beberapa logika, mencoba hal yang sama berkali-kali sering merupakan gejala kode buruk dan pemikiran magis yang menyembunyikan masalah nyata.