Perbaiki bug, atau tunggu pelanggan menemukannya?

Apakah orang lain memperbaiki bug ketika mereka melihatnya, atau apakah mereka menunggu sampai ada crash / kehilangan data / orang mati sebelum memperbaikinya?

Contoh 1

 Customer customer = null;
 ...
 customer.Save();

Kode jelas salah, dan tidak ada jalan lain - memanggil metode dengan referensi nol. Kebetulan tidak crash karena Savekebetulan tidak mengakses data instance apa pun; jadi itu seperti memanggil fungsi statis. Tetapi setiap perubahan kecil di mana saja tiba-tiba dapat menyebabkan kode rusak yang tidak macet: untuk mulai macet.

Tapi , itu juga tidak bisa dibayangkan memperbaiki kode:

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

mungkin memperkenalkan kecelakaan; satu tidak ditemukan melalui unit test dengan cakupan lengkap, dan pengujian pengguna manual.

Contoh 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

Orang yang mengetahui fisika akan mengetahui bahwa itu seharusnya R ² dalam penyebutnya.

Kode itu salah, itu benar-benar salah. Dan melebih-lebihkan kecepatan akan menyebabkan roket retro menembak terlalu cepat, menewaskan semua penghuni pesawat ruang angkasa.

Tapi itu juga mungkin mungkin karena perkiraan terlalu tinggi kecepatan menutupi masalah lain: kantong udara tidak dapat digunakan saat pesawat ulang-alik bergerak terlalu cepat. Jika kami tiba-tiba memperbaiki kode:

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

Sekarang kecepatannya akurat, dan tiba-tiba airbag menyebar ketika tidak seharusnya.

Contoh 3

Berikut adalah contoh yang saya miliki baru-baru ini, memeriksa apakah string berisi karakter yang tidak valid:

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

Bagaimana jika ternyata ada bug di Do somethingcabang? Memperbaiki kode yang jelas salah:

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

Memperbaiki kode, tetapi memperkenalkan bug.

Cara saya melihatnya ada dua kemungkinan:

• perbaiki kode, dan disalahkan karena melanggar itu
• tunggu kode mogok, dan disalahkan karena memiliki bug

Apa yang Anda lakukan secara politis?

Contoh 4 - Bug dunia nyata saat ini

Saya membangun objek, tetapi memanggil konstruktor yang salah:

Customer customer = new Customer();

Ternyata konstruktor "tanpa parameter" sebenarnya adalah konstruktor berparameter dari jauh ke belakang dalam rantai pewarisan:

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

Menyebutnya adalah kesalahan, karena melewati semua konstruktor berikutnya.

Saya dapat mengubah garis keturunan objek untuk tidak mengekspos konstruktor berbahaya seperti itu, tetapi sekarang saya harus mengubah kode menjadi:

Customer customer = new Customer(depends);

Tetapi saya tidak dapat menjamin bahwa perubahan ini tidak akan merusak apa pun. Seperti Contoh 1 saya di atas, mungkin seseorang, di suatu tempat, entah bagaimana, dalam beberapa kondisi esoteris, tergantung pada konstruksi yang Customertidak valid dan penuh dengan sampah.

Mungkin Customerobjek, sekarang dibangun dengan benar akan memungkinkan beberapa kode untuk menjalankan yang sebelumnya tidak pernah dilakukan, dan sekarang saya bisa mendapatkan crash.

Saya tidak bisa bertaruh hidup istrimu di atasnya.

Dan saya bisa mengujinya dari sini sampai Selasa, saya tidak bisa bersumpah pada kehidupan putri Anda bahwa saya tidak memperkenalkan regresi.

Apakah saya:

• Perbaiki kode dan disalahkan karena melanggar itu? atau
• Tinggalkan bug, dan disalahkan ketika pelanggan menemukannya?

Ini sangat tergantung pada situasi, bug, pelanggan, dan perusahaan. Selalu ada trade-off untuk dipertimbangkan antara mengoreksi implementasi dan berpotensi memperkenalkan bug baru.

Jika saya memberikan pedoman umum untuk menentukan apa yang harus dilakukan, saya pikir itu akan seperti ini:

1. Catat cacat dalam sistem pelacakan pilihan. Diskusikan dengan manajemen / rekan kerja jika perlu.
2. Jika cacat dengan potensi konsekuensi yang mengerikan (mis. Contoh Anda # 2), lari, berteriak, melompat-lompat sampai seseorang dengan pemberitahuan otoritas dan menentukan tindakan yang tepat yang akan mengurangi risiko yang terkait dengan perbaikan bug. Ini dapat mendorong tanggal rilis Anda kembali, menyelamatkan nyawa, mencuci jendela Anda, dll.
3. Jika cacat tidak putus, atau ada solusi, evaluasi apakah risiko memperbaikinya lebih besar daripada manfaat perbaikan. Dalam beberapa situasi akan lebih baik menunggu pelanggan untuk membawanya, karena Anda tahu Anda tidak menghabiskan waktu memperbaiki / menguji kembali hal-hal ketika tidak diperlukan 100%.

Pikiran Anda, ini hanya berlaku ketika Anda dekat dengan rilis. Jika Anda dalam mode pengembangan penuh, saya hanya akan mencatat cacat sehingga dapat dilacak, memperbaikinya, dan menyebutnya selesai. Jika itu adalah sesuatu yang membutuhkan lebih dari, katakanlah, setengah jam untuk diperbaiki dan diverifikasi, saya akan pergi ke pimpinan manajer / tim dan melihat apakah cacat tersebut harus sesuai dengan siklus rilis saat ini atau dijadwalkan untuk waktu berikutnya.

Pelanggan akan SELALU menemukan bug . Tidak ada bug tersembunyi dari pelanggan, tidak pernah. Pada akhirnya bug yang Anda perkenalkan akan selalu kembali kepada Anda. Tidak memperbaikinya hanyalah praktik profesional yang buruk. Profesional tidak melakukan ini.

Ketika pelanggan menemukan bug, perusahaan terlihat buruk, bukan pengembang individu. Ini jauh lebih buruk bagi perusahaan, jadi ada alasan Anda untuk melakukan perubahan. Jika Anda benar-benar tidak yakin tentang membuat perubahan ini karena takut memperkenalkan bug lain, bicarakan dengan pengembang yang lebih senior, pimpinan teknis proyek, atau siapa pun yang berada dalam posisi untuk membuat keputusan tentang perubahan tersebut dan kemudian menangani konsekuensi.

Perbaiki bug

Kami profesional di sini. Jika Anda menemukan jalur gagal dalam kode yang akan menyebabkan crash atau perilaku yang salah, Anda harus memperbaikinya. Tergantung pada prosedur tim Anda, Anda mungkin perlu mengajukan cacat, mungkin menulis tes regresi, dan memeriksa perbaikan pada waktu yang tepat dari siklus kapal. Jika itu bug prioritas rendah, memeriksa perbaikan di dekat awal tonggak selalu waktu yang baik karena jika Anda menyebabkan regresi Anda tidak akan mempengaruhi siklus rilis tonggak.

Jangan bingung dengan refactoring atau membuat peningkatan kinerja yang tidak terkait dengan bug kinerja.

Sistem kontrol sumber terdistribusi di mana Anda dapat menyimpan repositori terpisah dari 'perbaikan bug kecil' dan kemudian dengan mudah bergabung pada awal tonggak adalah sangat membantu di sini.

Apa yang akan dikatakan pelanggan?

Berikut adalah bagaimana saya membayangkan permainan ini:

Pelanggan: Itu macet ketika saya melakukannya x.

Programmer: Oh yeah! Saya ingat saya melihat itu beberapa waktu yang lalu. Saya pikir itu bukan masalah besar, jadi saya meninggalkannya di sana.

Pelanggan: [meraih objek tumpul]

Iya nih. Perbaiki bug. Anda akan menyelamatkan pelanggan dari pengalaman yang memberatkan, dan Anda bisa memperbaikinya sebelum menjadi darurat.

Dan jika Anda berpikir perbaikan Anda mungkin benar-benar menyebabkan kerusakan, maka Anda belum benar-benar menemukan perbaikan.

Semua contoh yang Anda berikan tampaknya memiliki kesamaan. Anda sepertinya ingin memperbaiki bug yang tidak sepenuhnya Anda mengerti. Saya mengatakan itu karena Anda perhatikan kemungkinan konsekuensi yang tidak diinginkan pada masing-masing.

Saya akan mengatakan itu mungkin kesalahan besar dan sebagai Ben Laurie menulis tidak memperbaiki bug Anda tidak mengerti . Dalam contoh terkenal ini tim Debian memecahkan enkripsi untuk OpenSSL untuk Debian dan turunannya seperti Ubuntu ketika mereka mengikuti hasil dari alat analisis.

Jika Anda yakin ada cacat dengan melihat kode, pastikan Anda dapat mereproduksi cacat sedemikian rupa sehingga pelanggan dapat melihatnya. Jika Anda tidak bisa mengapa tidak menghabiskan sumber daya Anda memperbaiki sesuatu yang lain.

Mulailah memotong utang teknis Anda sesegera mungkin .

Contoh Anda jelas terlihat seperti kode lama , memiliki banyak hutang teknis dan saya rasa ada ketakutan akan perubahan (BTW, ini bukan kritik atau penilaian). Seluruh tim Anda harus mengakui bahwa Anda memiliki hutang teknis ini (jadi Anda sendiri tidak disalahkan untuk itu) dan kemudian Anda dapat memutuskan bagaimana Anda akan menghadapinya.

Dalam Contoh 1, jika Save()tidak mengakses data contoh apa pun, data pelanggan apa yang sebenarnya disimpannya? Mulailah memperbaiki dan mengujinya.

Dalam Contoh 2, mudah untuk menutupi kalkulator kecepatan dengan tes dan memastikan bahwa menghitung hasil yang benar dalam semua contoh utama.

Dalam Contoh 3, ada bahaya menghidupkan kembali kode mati. Haruskah kode itu dihilangkan sama sekali? Apa maksud dari kondisi boolean di bawah itu jika? Apakah ini untuk memastikan string tidak mengandung karakter yang tidak valid? Atau untuk memastikan ada "PO BOX" di dalamnya? Semakin cepat Anda mulai menjawab pertanyaan seperti itu, semakin baik.

Setelah Anda memperbaiki sejumlah masalah seperti itu, lakukan semacam retrospektif / post-mortem dengan tim Anda. Penting untuk belajar dari pengalaman sehingga Anda dapat mengurangi tingkat injeksi cacat di masa mendatang.

Anda sudah memiliki jawaban yang bagus. Saya hanya akan menambahkan sesuatu tentang masalah takut sesuatu crash.

Pertama, dalam situasi ideal, perangkat lunaknya bersifat modular, dirancang dengan benar dan ada pemisahan kekhawatiran yang baik. Dalam hal ini, perubahan yang Anda buat sangat tidak mungkin untuk memecahkan apa pun karena Anda akan mengendalikan semua kode terkait dan tidak ada kejutan tersembunyi.

Sayangnya, situasi ideal itu fiksi. Terlepas dari sejauh mana kopling longgar, akan ada kopling dan karenanya kemungkinan melanggar sesuatu yang lain.

Solusi untuk ini adalah dua kali lipat:

1. Buat kode terstruktur sebaik mungkin.
2. Ketika kode cukup terisolasi sehingga Anda tahu bahwa tidak ada lagi yang akan rusak, perbaiki.

Membuat kode terstruktur dengan baik tidak dilakukan dengan menulis ulang seluruh kode menjadi desain arsitektur baru. Sebaliknya, refactoring yang dipandu oleh tes adalah teman Anda di sini. Pada langkah ini, Anda tidak mengubah fungsi.

Langkah kedua adalah Anda memperbaiki bug.

Beberapa poin relevan:

1. Kontrol Versi sangat diperlukan untuk proses ini.
2. Langkah refactoring dan langkah memperbaiki bug lebih baik berkomitmen untuk kontrol versi sebagai komitmen terpisah, sehingga masing-masing memiliki fungsi historis yang terdefinisi dengan baik.
3. Jangan terpaku pada kemungkinan membuat bug lain, Anda tidak akan menyelesaikan apa pun. Sebaliknya, pikirkan untuk membuat kode Anda lebih baik. Dengan kata lain, kecuali Anda tahu Anda meningkatkan bug daripada mengurangi bug maka Anda harus melakukannya.
4. Terkait dengan poin terakhir: jangan mencoba memprediksi masa depan. Manusia cenderung berpikir bahwa mereka sangat pandai dalam prediksi. Pada kenyataannya kekuatan prediksi kami adalah jangka pendek. Jadi jangan khawatir tentang bug masa depan yang tidak jelas dan tidak jelas. Ini juga prinsip di balik YAGNI .
5. Alat yang sesuai untuk kontrol versi di dunia bug adalah pelacak bug . Anda akan membutuhkannya juga.
6. Anda perlu memperbaiki bug karena dua alasan: untuk memuaskan pelanggan; dan agar dapat berkembang dalam pengembangan Anda. Untuk menggunakan contoh 3 (yang fisika): jika program memuaskan pelanggan dengan persamaan yang rusak, maka ada banyak bagian lain dari perangkat lunak yang salah dikembangkan untuk mengurangi bug ini (misalnya penyebaran airbag). Jika versi 2 (atau 1.1) diperlukan untuk perangkat lunak ini, maka Anda akan semakin sulit mengembangkan kode yang benar berdasarkan yang salah ini. Anda kemudian menuju penulisan ulang besar, atau untuk kegagalan besar. Keduanya harus Anda hindari.

Ini sudah lebih dari beberapa poin, jadi saya kira saya akan berhenti di sini.

Pertama-tama Anda harus mempertimbangkan definisi bug:

1. Kode yang sudah dibaca tidak cocok dengan apa yang Anda anggap benar
2. Perangkat lunak tidak melakukan tugasnya dengan benar

Anda tampaknya berfokus pada # 1, di mana # 2 adalah tempat terbaik untuk duduk. Tentu, kami programmer ingin kode kami benar (# 1), tetapi orang-orang membayar kami agar berfungsi (# 2).

Apa yang Anda mungkin atau mungkin tidak lakukan terhadap basis kode yang secara tidak sengaja dapat memperkenalkan bug baru tidak relevan dengan pandangan # 2 tentang perangkat lunak saat ini. Namun, # 1 penting bagi Anda sendiri atau pemrogram pemeliharaan yang mengikuti. Terkadang sulit untuk memutuskan, tetapi ketika # 2 dan # 1 konflik, Anda harus tahu bahwa # 2 jelas lebih penting.

Tidak juga. Ada cara ketiga: temukan cara untuk membuktikan bahwa "kode bermasalah" sebenarnya menyebabkan masalah dari sudut pandang bisnis. Konfirmasikan apa yang Anda temukan dengan BA / QA atau setidaknya manajer Anda. Kemudian rencanakan perbaikan ketika semua orang menyadari masalah.

Ada beberapa skenario yang mungkin terjadi selain bug yang valid dalam kasus yang Anda sebutkan:

1. Kode yang Anda lihat adalah beberapa kode mati. Mungkin karena seperti kata ysolik: pelanggan selalu menemukan bug. Jika tidak, mungkin kodenya tidak pernah dieksekusi.
2. Ada situasi WTF di mana kesalahan yang jelas memang memiliki tujuannya. (Kita berbicara tentang kode produksi, apa pun bisa terjadi, kan?)
3. Bisnis / pelanggan sudah tahu tentang masalah ini tetapi tidak merasa perlu untuk memperbaikinya.
4. Mungkin lebih...

Dalam kasus apa pun di atas, jika saya seorang manajer, saya tidak ingin pengembang menggunakan penilaiannya dan memperbaiki "kesalahan" yang ada. Memperbaiki kesalahan yang ada dapat membantu sebagian besar waktu, tetapi ketika terjadi kesalahan, itu dapat menyebabkan lebih banyak masalah daripada niat baiknya.

Apakah saya:

• memperbaiki kode dan disalahkan karena melanggar itu? atau
• meninggalkan bug, dan disalahkan ketika pelanggan menemukannya?

Anda memperbaiki bug, memulai pengujian unit , dan ketika mereka berhasil, Anda memeriksa perbaikan Anda.

(Atau, jika pengujian unit Anda memakan waktu sangat lama, Anda memeriksa perbaikan Anda terlebih dahulu, dan kemudian menunggu apakah alat CI Anda mengirimi Anda surat karena komit Anda memecahkan sesuatu.)

Perbaiki jika bug bug / kehilangan data. Mengirim program dengan bug hilangnya data yang diketahui benar-benar berbahaya dan tidak dapat dimaafkan.

Jika bug bersifat kosmetik atau non-kritis (dapat dihindari) maka bug tersebut harus didokumentasikan dan solusinya harus disediakan. Idealnya itu harus diperbaiki, tetapi kadang-kadang terlalu mahal untuk memperbaikinya untuk rilis saat ini.

Perhatikan bagaimana setiap proyek perangkat lunak yang lebih besar memiliki bagian 'Masalah yang Diketahui' di ReadMe yang biasanya mencantumkan dengan tepat: Bug yang diketahui.

Mengetahui Bug dan TIDAK berkomunikasi dengan mereka adalah IMHO hanya dapat diterima untuk bug yang benar-benar minor / kosmetik.

Perbaiki, dan uji. Jika Anda memutuskan untuk tetap menggunakan bug yang diketahui hanya karena Anda takut menemukan lebih banyak bug, program Anda menjadi ladang ranjau bom waktu yang begitu cepat sehingga tidak akan diperbaiki lebih cepat daripada yang Anda pikirkan.

Karena Anda adalah master dan kode tersebut adalah bawahan, Anda mungkin tidak takut mengubahnya ketika Anda melihatnya salah. Takut pada kode ("mungkin membalas dengan melanggar di tempat lain") tidak dapat diterima.

Jika jelas ada crasher, atau ada sesuatu yang salah , maka Anda harus memperbaikinya. Jika ada ambiguitas dalam spec, yaitu jika Anda menemukan diri Anda berpikir "baik pelanggan mungkin mengharapkan ini, tapi kemudian kelihatannya seperti itu mungkin menjadi bug" atau masalah di spec, seperti "kami telah diminta untuk melakukan hal ini tetapi itu menyebalkan "maka Anda perlu mencari tahu apa yang harus dilakukan. Melemparkan kode ke dinding dan menunggu umpan balik pelanggan buruk - Anda mungkin bertanya kepada manajer produk apakah Anda memilikinya, atau bertanya kepada pelanggan sebelum Anda menggunakan produk tersebut.

Ingat, "kami tahu tentang masalah itu dan akan memperbaikinya di rilis mendatang" identik dengan "kami tahu tentang masalah itu tetapi tidak cukup peduli dengan Anda untuk menghindari Anda mengatasinya".

Tindakan yang tepat adalah tidak mengabaikan bug, atau "memperbaiki" bug saat itu juga; untuk alasan yang Anda identifikasi dalam pertanyaan Anda.

Saya pikir, Anda harus mencoba memahami kode terlebih dahulu. Jika kode yang Anda lihat memiliki usia tertentu, dan belum ada yang memperhatikan "bug", ada kemungkinan alasannya. Coba cari alasan ini. Inilah yang ingin saya lihat sebelum mengambil keputusan:

• Riwayat : Gunakan perangkat lunak kontrol versi Anda untuk menjawab pertanyaan: Siapa yang menyentuh kode? Apa yang mereka ubah? Dan dengan pesan komit apa mereka memeriksanya? Bisakah Anda menyimpulkan alasan mengapa kode itu terlihat seperti itu?

• Gunakan : Kode apa yang menggunakan kode yang salah? Dan bagaimana? Apakah kodenya mati? Apakah ada kode lain yang bergantung pada perilaku yang salah?

• Penulis : Jika Anda tidak dapat mencapai kesimpulan dengan cepat menggunakan informasi di atas, tanyakan pembuat kode (setidaknya jika itu mungkin) mengapa kode terlihat seperti itu. Biasanya Anda akan mendapatkan "Oups, itu harus diperbaiki!" atau "Tidak! Jangan mengubahnya !!! Dibutuhkan seperti itu!" segera.