Bayangkan skenario berikut:

Anda mendeteksi bahwa program Anda (atau orang lain) memiliki bug - suatu fungsi menghasilkan hasil yang salah ketika diberi input tertentu. Anda memeriksa kode dan tidak dapat menemukan sesuatu yang salah: itu hanya tampak seperti bog ketika diberi masukan ini.

Sekarang Anda dapat melakukan salah satu dari dua hal: Anda juga memeriksa kode lebih lanjut sampai Anda menemukan penyebab sebenarnya; atau Anda menampar perban dengan menambahkan ifpernyataan memeriksa apakah input adalah input khusus ini - jika ya, kembalikan nilai yang diharapkan.

Bagi saya, menerapkan perban akan benar-benar tidak dapat diterima. Jika kode berperilaku tidak terduga pada input ini, input apa lagi yang Anda lewatkan akan bereaksi aneh? Sepertinya tidak ada perbaikan sama sekali - Anda hanya menyekop masalah di bawah permadani.

Karena saya bahkan tidak akan mempertimbangkan untuk melakukan ini, saya terkejut melihat betapa sering profesor dan buku terus mengingatkan kita tentang bagaimana menerapkan perbaikan "perban" bukan ide yang baik. Jadi ini membuat saya bertanya-tanya: seberapa umumkah "perbaikan" semacam ini?

Tekanan waktu / tenggat waktu adalah salah satu alasannya.

Jika Anda menghadapi tenggat waktu yang ketat dan bos Anda menghembuskan napas (mungkin secara harfiah!) Maka melakukan ini dan berpikir "Aku akan kembali dan memperbaikinya nanti" sangat menggoda dan mungkin satu-satunya hal yang Anda lakukan bisa lakukan.

Tentu saja berapa kali Anda benar-benar kembali dan memperbaikinya sangat sedikit dan jarang karena Anda memiliki masalah baru yang perlu diperbaiki kemarin.

Seperti halnya kita sebagai programmer tidak suka mengakuinya, perangkat lunak kode indah tidak selalu akan diterjemahkan ke nilai lebih bagi perusahaan atau pelanggan. Ini dua kali lipat benar dalam situasi bencana, misalnya perangkat lunak menggandakan kartu kredit orang. Terkadang, seperti perban, Anda hanya perlu menghentikan pendarahan dengan cara apa pun yang diperlukan dan berjanji untuk kembali setelah pasien stabil dan benar-benar memperbaiki masalah inti.

Kuncinya adalah, begitu urgensi hilang, sangat sulit untuk meyakinkan siapa pun untuk memprioritaskan mengganti perban dengan perbaikan yang benar. Terutama mengingat bahwa selalu ada masalah mendesak yang menunggu di belakang yang pertama. Anda hanya harus waspada untuk tetap dengan masalah di luar perbaikan cepat.

Waktu

Apakah alasan # 1 menurut saya. Meskipun jika masalahnya adalah basis kode bijaksana saya mungkin memerlukan waktu lebih banyak untuk menyelidiki itu. Seringkali perbaikan "perban" saya melibatkan tweak CSS atau UI. Saya telah menulis beberapa CSS inline dan JavaScript yang cukup jahat untuk menghadapinya dengan cepat. Kembali dan memperbaikinya selalu menjadi pilihan jika Anda punya waktu.

Kami melakukannya dengan sangat baik.

Untuk perbaikan selama pengembangan, kami memastikan bahwa tidak ada perbaikan yang dilakukan tanpa mengetahui akar masalahnya. Namun:

• Secara khusus pencarian akar penyebabnya akan mulai terlalu lama atau macet DAN ada tenggat waktu yang sulit,
• Perubahan kode yang luar biasa untuk memperbaiki akar permasalahan secara taktik tidak layak (perubahan akan memakan waktu terlalu lama dan batas waktu mendekati)

Dalam kasus tersebut kami memilih perbaikan "perban". Kami kemudian membuka cacat internal untuk mengatasi penyebab utama. Ya, lebih sering daripada tidak, cacat internal ini diperlakukan dengan prioritas sangat rendah.

Untuk perbaikan di aliran pemeliharaan, kami memastikan bahwa tidak ada perbaikan yang dilakukan tanpa mengetahui penyebab dasarnya. Namun:

• Sangat luar biasa pencarian akar penyebabnya akan berhenti,
• Secara luar biasa dapat terjadi bahwa memperbaiki akar permasalahan secara taktik tidak layak (perubahan tidak sepele dan pelanggan membutuhkan perbaikan kemarin).

Dalam kasus-kasus tersebut kami memilih untuk memperbaiki sementara "perban" terlebih dahulu dan begitu pelanggan puas, kami mengerjakan perbaikan yang tepat dan hanya setelah itu kerusakan diselesaikan.

Disambiguasi.

• Mengingat bug tertentu, ada kesulitan yang cukup besar dalam mendefinisikan secara objektif apakah perbaikan tertentu adalah "perban" karena: "solusi yang tepat" seseorang mungkin adalah "perban" orang lain.
• Jadi, saya menggunakan definisi berikut: untuk memperbaiki cacat dengan cara yang kurang elegan dan kurang dipelajari daripada yang saya harapkan bisa saya lakukan secara profesional.

Pertama, mengenai frekuensi perbaikan "perban":

• Kode baru: hampir tidak ada.
• Kode lama:
  • Anda akan menemukan beberapa, meskipun mereka biasanya ditulis dengan cukup elegan (lihat "mitigasi berbasis data" di bawah) sehingga mereka tidak terlihat seperti perban dan akan bertahan semua tinjauan kode.
  • Perhatikan juga "perban tidak terlihat": jangan panggil fungsi itu. Dengan kurangnya kode, bahkan tidak ada jejak petunjuk bahwa ada bug.
• Kode lama dengan banyak ketergantungan eksternal:
  • Hampir penuh.
  • Itu hampir selalu ditulis untuk versi usang dependensi, dan tidak ada yang benar-benar membaca "catatan rilis" dependensi sebelum memperbarui dependensi ke versi baru.

Kedua, saran saya:

Jika bug terjadi pada kode sumber tim pengembangan sendiri:

• Perbaiki dengan cara profesional. (Jika Anda memperbaikinya, Anda memilikinya.)
• Ketika berada di bawah tekanan waktu, lakukan hal terbaik yang Anda bisa - yang mengharuskan Anda untuk:
  • Lihatlah dampak potensial pada pengguna akhir: dari bug itu sendiri, dan perbaikan yang diusulkan, untuk memutuskan apakah akan menerima perbaikan.
  • Pelajari cuplikan kode terkait (menggunakan info riwayat dari alat manajemen kode sumber Anda), dan diskusikan dengan rekan kerja Anda (tetapi jangan terlalu banyak menghabiskan waktu mereka), sampai Anda memahami dengan baik masalah dan solusinya.
• Selalu lacak bug dengan sistem pelacakan cacat .

Jika bug terjadi pada kode sumber tim lain:

• Dorong tim itu untuk memperbaiki bug mereka.
• Selalu ajukan bug itu dengan sistem pelacakan cacat tim lain .

Jika bug terjadi pada produk perusahaan lain (atau tidak ada perusahaan):

• Dalam hal ini, perbaikan lakban (atau solusi berbasis data ) mungkin merupakan satu-satunya cara untuk memperbaiki bug.
• Jika itu open source, tetap file bug itu dengan beberapa sistem pelacakan cacat (mungkin publik) , sehingga seseorang dapat melihatnya.

Tergantung pada usia basis kode saya pikir. Pada kode lama saya pikir itu sangat umum, menulis ulang bahwa rutin COBOL berusia 20 tahun tidak menyenangkan. Bahkan pada kode baru yang sedang dalam produksi masih cukup umum.

Saya akan mengatakan itu sangat umum.

Lihat posting blog Joel Spolsky: The Duct Tape Programmer

Saya dapat dengan mudah mengatakan bahwa hampir setiap proyek yang pernah saya ikuti saya harus menerapkan semacam perban atau lakban untuk memenuhi tenggat waktu dan menyelesaikan tugas. Ini tidak cantik, tidak bersih, tetapi menyelesaikan pekerjaan sehingga bisnis dapat terus berjalan, dan proyek dapat bergerak maju dalam beberapa cara.

Ada perbedaan antara dunia akademis, dan dunia nyata di mana perangkat lunak benar-benar perlu dikirim di bawah waktu dan hambatan bisnis.

Di satu sisi ia meletakkannya di bawah karpet, untuk menunda perbaikan, sampai semoga, nanti. Sayangnya, terlalu sering, perbaikan yang ditunda tidak pernah terjadi dan kode ini masuk ke dalam produksi.

Sulit untuk mengatakan tanpa lebih banyak konteks - dalam contoh Anda, mengapa menambahkan pernyataan if bukan perbaikan yang benar? Apakah karena seharusnya ada beberapa blok kode lain di sana di suatu tempat yang seharusnya berurusan dengan input itu?

Seberapa sering perbaikan perban digunakan tergantung pada sejumlah hal seperti seberapa kompleks kode tersebut, apakah orang yang paling akrab dengan kode tersebut tersedia (orang yang bertanggung jawab atas rutin COBOL yang berusia 20 tahun dari Craig mungkin telah meninggalkan perusahaan bertahun-tahun yang lalu) ) dan rentang waktu yang terlibat.

Dengan tenggat waktu menatap wajah Anda, kadang-kadang Anda akan memenuhi syarat untuk perbaikan yang lebih aman, bahkan jika itu hanya menampar plester daripada memperbaiki penyebab utama. Tidak apa-apa selama Anda tidak memperburuk keadaan, tetapi penting untuk melacak fakta bahwa itu masih belum benar dan masih perlu diperbaiki dengan benar.

Ada kasus-kasus di mana perbaikan semacam itu benar-benar OK dan mungkin yang ideal (sejauh jumlah waktu yang diperlukan untuk debug terkait).

Bayangkan sebuah skenario di mana Anda memiliki 20 DLL yang seharusnya bertindak sebagai semacam modul untuk executable utama Anda, tetapi juga memerlukan beberapa informasi dari executable utama untuk dijalankan.

Jika Anda pernah ingin menggunakan DLL di luar executable utama, Anda perlu memalsukan beberapa nilai pengembalian dari executable utama karena. A.) Itu tidak ada dalam konteks ini dan B.) Anda tidak ingin itu ada dalam konteks ini.

Yang sedang berkata, Anda lebih baik meletakkan beberapa arahan kompiler dalam kode Anda untuk memastikan Anda menjalankan kode yang sama sekali berbeda ketika Anda menipu hasil vs ketika Anda mendapatkan hasil nyata.

Alih-alih memasukkan fungsi iforang lain ke dalam, saya lebih mengutamakan {$ifdef}fungsi - sehingga tidak ada orang yang bingung dengan sesuatu yang seharusnya ada di sana.