Perbaiki bug, atau tunggu pelanggan menemukannya?


35

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

33
Jika Anda tidak ingin mengubah apa pun karena dapat merusak sesuatu, dan Anda menganggap diri Anda tidak memenuhi syarat untuk melihat apa yang mungkin terjadi di bagian lain dari kode, apa yang Anda lakukan di sini? Apakah Anda lumpuh di keyboard karena baris kode yang akan Anda tulis mungkin salah?
David Thornley

3
tentu pertanyaan yang diteliti dengan baik
Muhammad Alkarouri

2
"Do Something" sering kali merupakan panggilan ke fungsi lain yang Anda tulis atau fungsi dari perpustakaan, dalam kasus apa pun kode tersebut seharusnya telah diuji unit. Prosedur itu sendiri juga unit yang diuji meninggalkan kemungkinan bug baru akan diperkenalkan ketika Anda memperbaiki yang sangat rendah ... Jika saya membangun jembatan, saya akan mengujinya terlebih dahulu dalam skala yang lebih kecil daripada membiarkan orang yang berjalan di atas jembatan mati . Jika Anda tidak melakukan tes unit saat khawatir tentang bug, Anda salah melakukannya. Dalam kasus apa pun Anda memperbaikinya, Anda disalahkan, jadi alih-alih memperbaikinya, Anda dapat mencegahnya dan tidak disalahkan sama sekali.
Tamara Wijsman

2
'jangan [kamu] tunggu sampai orang mati sebelum memperbaikinya'! Astaga, aku sungguh berharap hanya ada satu jawaban untuk ini ...
Chris Knight

3
Sebagai komentar khusus tentang satu hal yang Anda katakan: Anda tidak tahu jika ada tempat lain dalam kode, mereka bergantung pada perilaku esoteris: jadi? Jika seseorang menyalahgunakan aturan pelingkupan yang jelas tidak benar sebagai peretasan dalam kode mereka, maka kode mereka SALAH. OOP yang baik akan mencegah bug itu, tetapi Anda tidak memperbaikinya karena mereka menggunakan praktik buruk memperburuk masalah, membiarkannya terbuka untuk penyalahgunaan lebih lanjut, dan membuat sistem lebih tidak stabil sepanjang jalan di sekitar. Perbaiki bug, harap pengujian menangkap masalah, perbaiki bug jika tidak. Stabilitas jangka panjang dari produk ini adalah metrik yang vital.
CodexArcanum

Jawaban:


34

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.


Sangat benar. Itu sebabnya (beberapa) perusahaan memiliki manajer teknis, bug crawl, dan sebagainya: untuk memprioritaskan hal-hal. Saya tidak mengatakan jangan mengambil inisiatif - tidak sama sekali - tetapi Anda harus menggunakan penilaian yang baik. Mengambil inisiatif yang salah pada waktu yang salah disebut "menjadi meriam longgar" dan dapat membunuh sebuah perusahaan. Juga, pentingnya bug tertentu bervariasi dari perusahaan ke perusahaan. Untuk beberapa program, kesalahan ketik dalam kotak dialog adalah bug kosmetik prioritas rendah yang harus diperbaiki dalam rilis mendatang, dan pada program lain ini merupakan darurat berhenti-kapal.
Bob Murphy

6
+1 untuk mencatat cacat. Cacat lain mungkin diprioritaskan ...
SHug

35

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.


2
Itu kebenaran yang menyedihkan. Kami harus mengirimkan proyek yang kami uji gila-gilaan, dan tetap saja pelanggan berhasil menghentikannya dalam waktu 3 menit.
Oliver Weiler

4
Metode @Helper: Mungkin jika Anda mengujinya seperti orang waras itu akan lebih baik.
Vinko Vrsalovic

Metode @Helper: Meskipun, lebih serius, jika benar-benar tiga menit ini sepertinya penguji tidak tahu apa kasus penggunaan nyata yang diharapkan oleh pelanggan.
Vinko Vrsalovic

8
Metode @Helper: melibatkan pelanggan dalam pengujian (dengan asumsi pelanggan == klien). Pengembang menulis dan menguji kode adalah masalah pengembang tidak menggunakan perangkat lunak dengan cara yang sama. Pengembang lembut. Ini pekerjaan mereka - karya seni mereka: Pelanggan menggedornya seperti kera di atas pansy. Jika memungkinkan, bagikan upaya pengujian dengan berbagi tanggung jawab. Ini tidak cocok dengan setiap lingkungan, tetapi bekerja dengan pelanggan sebagai sebuah tim, bukan penasihat dapat menghasilkan perangkat lunak yang lebih baik.
brian chandley

Er, worser? (pengisi)
Hello71

24

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.


4
+1. Memperbaikinya. Jika perbaikan merusak sesuatu yang lain, maka itu sesuatu yang lain tetap rusak - perbaiki juga. Jika pengujian Anda tidak mendapatkan istirahat ini, maka pengujian Anda rusak - perbaiki juga. Anda tidak bisa membiarkan diri Anda takut mengubah kode karena takut merusak sesuatu - jalan itu hanya akan menghasilkan kehancuran total.
Tom Anderson

21

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.


8

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.


7

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.


5

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.


3

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.


2

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.


1
Jika Anda hanya ingin merekrut pengembang yang tidak menggunakan penilaian mereka sendiri, ada banyak yang benar-benar biasa-biasa saja di luar sana untuk Anda. Anda akan kesulitan mempekerjakan orang baik yang sebenarnya, yang memiliki kepercayaan diri pada kemampuan mereka.
David Thornley

1
@ David: jangan sampaikan pendapat saya ke tingkat yang tidak pantas. Pengembang tentu membutuhkan penilaian mereka, tetapi harus ada batasan. Dalam hal ini, pengembang menggunakan penilaian mereka untuk mendeteksi bug potensial dan mengambil langkah lebih lanjut untuk mengatasinya.
Codism

2

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


1
Atau jika Anda menggunakan check-in yang terjaga keamanannya, atur itu, sehingga Anda tidak benar-benar memeriksa kode yang rusak.
Adam Lear

3
Membutuhkan waktu lama bukanlah alasan untuk melakukan kode jelek.
Toby

@Toby: Siapa yang berbicara tentang alasan? Saat ini saya bekerja di tim kecil, bahkan tidak sampai setengah pengembang. Tes unit untuk proyek berlangsung 1 jam. Kebijakan kami adalah menjalankan tes yang tampaknya terkait dengan apa pun yang Anda lakukan, dan kemudian check in dan biarkan CI mencari tahu apakah Anda memecahkan sesuatu yang tampaknya tidak berhubungan. Ini tidak akan bekerja di tim besar, tetapi dalam yang kecil ini menghemat banyak waktu.
sbi

1

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.


1

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.


0

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


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.