Memperbaiki bug yang tidak pernah menyebabkan masalah sampai sekarang


20

Baru-baru ini saya membuat perubahan yang menyebabkan beberapa kode dijalankan jauh lebih sering daripada biasanya. Ini mengarah pada penemuan bug. Bug ini berpotensi terjadi kapan saja kode dijalankan tetapi karena dijalankan sangat jarang sehingga tidak pernah muncul.

Ketika saya membawa ini ke perhatian pengembang utama dia ingin saya membatalkan perubahan yang mengekspos bug daripada memperbaiki bug mengutip pepatah, "Jika tidak rusak, jangan memperbaikinya".

Jelas bagi saya bahwa kami hanya beruntung sampai sekarang tetapi dia tidak mau mendengarkan alasan.

Haruskah saya memperbaikinya?

Memperbarui

Pimpinan secara teknis tidak memiliki wewenang atas saya. Hanya masa jabatan. Dia telah menjadi satu-satunya pengembang di proyek ini selama beberapa tahun hingga setahun yang lalu dan saya pikir dia tidak menerima kritik yang membangun dengan baik. Untuk apa nilainya, saya tidak mengkritiknya. Saya hanya menunjukkan bahwa hanya karena bug tidak pernah muncul tidak berarti itu tidak ada.


Apakah ini terkait dengan threading bug atau sesuatu yang lain?
TheLQ

3
Dia bos karena suatu alasan. Saat kotoran menghantam kipas, dia akan menjadi orang yang mereka bakar. Jika dia dipanggang karena Anda tidak melakukan apa yang dia minta maka Anda akan membutuhkan dayung besar.
Martin York

3
Bisakah Anda membuat kasus di mana bug terjadi bahkan dengan perubahan Anda dibatalkan? Jika tidak, mungkin itu bukan bug, itu adalah fea ^ H ^ H ^ H ^ Hn pembatasan tidak berdokumen.
Steve314

3
Hmm, "Jika rusak, perbaiki sesuatu yang lain." - baik itu interpretasi baru, saya akan memberinya.
Orbling

1
"Jika tidak rusak, jangan memperbaikinya"? Tapi itu rusak.
StuperUser

Jawaban:


26

Saya menyarankan jika Anda memiliki pelacakan bug, kemudian kirimkan. Jika itu penting, maka angkat dan bawa ke perhatiannya. Biarkan atasan Anda menurunkannya di pelacak. Ketika ada masalah, Anda akan memiliki jejak kertas.


9
Ingat: Tutupi Ass Anda :-)
gruszczy

1
Tidak seberuntung itu. Semuanya kursi-of-the-celana. Tidak ada pelacakan bug, tidak ada pengumpulan persyaratan, tidak ada pengujian. Mungkin bahkan tidak akan memiliki kontrol versi jika manajemen tidak bersikeras.
Kenneth Cochran

18
Berdasarkan deskripsi Anda tentang lingkungan kerja Anda, Anda seharusnya mengangguk dan tersenyum ketika pemimpin dev mengatakan kepada Anda untuk tidak memperbaikinya, dan kemudian melanjutkan dan melakukan apa yang ingin Anda lakukan.
Carson63000

2
Dan jangan mengajukan pertanyaan seperti itu lain kali :-)
gruszczy

2
@codeelegance: "Tidak ada pelacakan bug, tidak ada persyaratan, tidak ada pengujian. Mungkin bahkan tidak akan memiliki kontrol versi jika manajemen tidak bersikeras itu." - Sweet Maria Bunda Allah !! 1 !! Lingkungan itu sangat ironis bagi nama pengguna Anda. :)
Bobby Tables

8

Secara pribadi saya akan memperbaikinya, kecuali jika diperlukan usaha yang lebih besar daripada nilainya. "Jika tidak rusak, jangan diperbaiki" mengerikan untuk diterapkan pada perangkat lunak.

Jika pengembang utama Anda adalah bos Anda dan dia berkata jangan menyentuhnya, dalam hal ini saya tidak akan melakukannya.


2
Seberapa terlambat siklus mereka? Ini bisa menjadi potensi bunuh diri.
Pekerjaan

8
"Jika tidak rusak jangan memperbaikinya" adalah aturan yang sangat baik untuk diterapkan ke perangkat lunak - hanya saja tidak ketika perangkat lunak rusak.
Steve314

Jika tidak rusak jangan memperbaikinya berlaku untuk perangkat lunak tergantung pada apa definisi kode rusak. Saat Anda duduk dan menatap kode yang jelas perlu diperbaiki, itu menjadi rusak. Saat Anda mulai menerapkan solusi untuk kode yang rusak, Anda benar-benar bekerja mundur dan seiring waktu kode yang rusak akan semakin sulit untuk diperbaiki ...
Ernelli

2

Sebagian besar jawaban dan komentar menyarankan pengurangan tanggung jawab atas keputusan dengan membuat laporan bug dan membiarkan orang lain menelepon.

Karena saya tidak memiliki pelacak bug (dan saya ragu orang lain selain saya akan menggunakannya jika kami melakukannya) saya melakukan hal terbaik berikutnya. Saya pergi ke kepala pengembang utama. Setelah menjelaskan situasinya kepada manajemen, mereka melihat semuanya dengan cara saya. Mereka mengatakan kepada saya untuk memperbaikinya dengan baik dan mengabaikan permintaan permintaan pemimpin . Mereka mengatakan akan menghaluskan bulu-bulu yang mengacak-acak jika dia menemukan dalih dan mengeluh.

Bukan solusi yang ideal tetapi setidaknya bug diperbaiki dengan benar.


Anda bekerja dalam rantai komando, dan dengan demikian menutupi pantat Anda. Menggunakan perangkat lunak pelacakan bug adalah sesuatu yang harus dipertimbangkan oleh perusahaan Anda , setidaknya membantu untuk melacak hal-hal seperti ini, dan permintaan fitur, dll.
Berin Loritsch

2

Ingatkan dia frasa adalah, "Jika tidak rusak, jangan memperbaikinya" dan tidak "Jika klien belum menyadarinya, jangan memperbaikinya".


1

Pembenaran apa yang Anda miliki untuk perubahan yang Anda buat? Jika Anda tidak dapat menunjukkan perubahan apa yang akan dialami pengguna atau utang teknis telah dihapus, saya akan berpihak pada pengembang utama dalam hal mengatakan mundur saja perubahan karena ini hanya memperburuk keadaan.


Anda memiliki setidaknya beberapa opsi berbeda di sini dalam pikiran saya:

Jika Anda hanya melanjutkan dan memperbaiki bug, Anda berisiko menambahkan lebih banyak bug ke dalam campuran yang dapat menjadi bumerang bagi saya. Tergantung pada seberapa banyak pengalaman yang Anda miliki dan kepercayaan diri untuk menghindari kejutan tidak menyenangkan yang mungkin akan menjadi panduan saya di sini.

Jika Anda melakukan apa yang diperintahkan kepada Anda, apakah hanya rasa bersalah yang akan menjadi masalah atau lebih dari itu? Saya bertanya-tanya apa yang salah di sini selain hal-hal yang dikenal sebagai prinsip dan nilai. Maksud saya itu sebagai sedikit lelucon tetapi juga titik jujur ​​tentang apa yang salah dengan ide ini?


Perubahan itu diperlukan untuk memperbaiki bug lain. Petunjuk menyarankan saya meletakkan persyaratan yang membatasi seberapa sering kode dijalankan daripada memperbaiki penyebab bug. Kedua bug yang saya perbaiki dan yang saya temukan adalah show stopper.
Kenneth Cochran

3
Dalam hal ini perlu diperbaiki dengan benar. Menggunakan kondisi yang melilit masalah hanya akan mencegah malapetaka, DAN itu menambah lebih banyak kode baru yang lebih salah. Ini solusi yang buruk (bahkan konyol).
cepat

1

Sementara insting saya yang luar biasa adalah untuk memperbaiki bug tidak menyembunyikan masalah, ada skenario ketika saya akan menahan hidung dan menyembunyikan masalah.

  1. Kode digunakan secara internal, dan kadang-kadang, sehingga konsekuensi dari bug dapat dikelola di dalam perusahaan.
  2. Pertimbangan komersial luar biasa yang menuntut pengiriman hari ini, dan perbaikan bug dapat diluncurkan 2 minggu kemudian dengan konsekuensi minimal.

Secara profesional, saya tidak suka jawaban ini, dan akan menjelaskan secara internal bahwa eter dari situasi ini terjadi.


0

Pada akhirnya, Anda tidak boleh melakukan apa pun yang atasan Anda katakan tidak dilakukan. Saya percaya bahwa hal terbaik untuk dilakukan di posisi Anda adalah membuat laporan bug di basis data pelacakan bug apa pun yang Anda miliki. dengan cara ini setidaknya setiap orang menyadari masalah ini dan seseorang dengan wewenang lebih dapat memutuskan apa yang harus dilakukan dengannya.


0

Salin fungsi buggy, terapkan perbaikannya, ganti namanya, mungkin menyamarkannya sedikit, dan panggil saja.

Berdasarkan dua komentar bug showstopper Anda, pilihan terbaik Anda mungkin mengikuti surat hukum, tetapi abaikan semangatnya.

Jelas ada kelemahan kode cut-and-paste, tapi sepertinya itu akan menjadi masalah Anda yang paling kecil.


1
ide yang buruk, jika saya menangkap salah satu programmer saya melakukan sesuatu seperti itu, saya akan memecatnya di tempat, itu adalah cara yang dijamin untuk menyebabkan kerusakan pada kode dan bagi siapa saja yang harus menjaga kode itu.
Miki Watts

@Miki - dalam hal ini, beri tahu saya apa yang bukan ide yang buruk? Tolong jelaskan bagaimana memasukkan bug kembali karena membuat bug lain (yang ada di sana) lebih terlihat adalah hal yang baik. Adapun penembakan di tempat, saya berpendapat pemecatan konstruktif, karena pengembang tidak punya banyak pilihan.
Steve314
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.