Haruskah saya merekam bug yang saya temukan dan tambal?


68

Saya kira ini adalah situasi umum: Saya menguji beberapa kode, menemukan bug, memperbaikinya, dan melakukan perbaikan bug ke repositori. Dengan anggapan bahwa banyak orang mengerjakan proyek ini, pertama-tama saya harus membuat laporan bug, menugaskannya sendiri, dan merujuknya dalam pesan komit (mis. "Memperbaiki bug #XYZ. Bug itu disebabkan oleh X dan Y. Memperbaikinya dengan Q dan R ")? Atau, saya dapat melewatkan laporan bug dan melakukan dengan pesan seperti "Memperbaiki bug yang menyebabkan A saat B. Bug tersebut disebabkan oleh X dan Y. Memperbaikinya dengan Q dan R".

Apa yang dianggap praktik yang lebih baik?


4
Tergantung pada ukuran perusahaan dan tim Anda, dan karakteristik bug. Pada tim kecil dan cepat, itu tidak perlu, karena Anda dapat berkomunikasi dengan sesama pengembang hanya dengan meneriaki mereka. Pada tim besar, organisasi besar, lingkungan pengembangan terdistribusi, bagus untuk mencatat pekerjaan Anda, tetapi juga merupakan overhead yang akan menurunkan tingkat produksi Anda jika Anda mengerjakan beberapa bug kecil. Kecuali itu adalah bug serius, yang selalu menyenangkan untuk didokumentasikan, unit-diuji untuk menghindari regresi dan ditutup.
Machado

15
Jangan lupa bahwa beberapa bug tidak tetap tetap - mereka spontan menjelma jika Anda mengabaikan mereka untuk sementara waktu. Mengetahui bagaimana seseorang berusaha memperbaikinya terakhir kali bisa sangat berharga. Paling tidak, harus ada beberapa dokumentasi yang mengatakan apa yang Anda lakukan pada kode dan mengapa, bahkan jika itu hanya dalam komentar dalam kode.
alephzero

5
Selain komentar sebelumnya, itu juga tergantung apakah bug berhasil keluar ke alam liar, tetapi Anda cukup beruntung karena tidak ada pelanggan yang menemukannya, atau jika bug itu diperkenalkan dan diperbaiki dalam satu siklus rilis.
whatsisname

3
Jika ragu, teriaklah. Bagi saya tidak ada salahnya membuka dan menutup laporan bug. Dalam beberapa keadaan, ada baiknya didokumentasikan dan resmi.
phresnel

1
Terkait dengan komentar @ alephzero, sesuatu yang terjadi pada saya baru-baru ini: Memperbaiki bug di salah satu bagian kode mengungkapkan bug di tempat lain. Mereka secara tidak sengaja membatalkan satu sama lain di bagian yang belum saya sentuh, dan naluri pertama pemelihara adalah membatalkan perbaikan saya.
Izkata

Jawaban:


71

Itu tergantung pada siapa pemirsa laporan bug.

Jika hanya dilihat secara internal oleh pengembang, untuk mengetahui apa yang perlu diperbaiki, maka jangan repot-repot. Hanya kebisingan pada saat itu.

Daftar alasan yang tidak lengkap untuk tetap login:

  • Rilis-catatan mencakup informasi tentang bug tetap (sampai batas tertentu yang dipenuhi bug ini) - terutama jika ada kerentanan yang terpapar oleh bug ini
  • Manajemen menginginkan gagasan "Perbaikan bug yang dihabiskan waktu" / "Jumlah bug yang terdeteksi", dll.
  • Pelanggan dapat melihat status bugtracker saat ini (untuk melihat apakah masalah mereka diketahui, dll.)
  • Penguji mendapatkan informasi tentang perubahan yang harus mereka uji.

56
Tempat yang paling mungkin terjadi bug adalah tempat bug sebelumnya terjadi. Saya merekomendasikan untuk merekamnya di hampir setiap skenario.
corsiKa

18
# 4: Penguji menggunakan pelacak bug untuk memandu pengujian mereka. Mereka akan menguji apakah perbaikannya berhasil dan tidak menyebabkan bug atau regresi baru.
jpmc26

2
@corsiKa Kapan obatnya lebih buruk daripada penyakitnya? ;-)
hBy2Py

1
@ hBy2Py Temukan dokter baru, lalu catat.
corsiKa

2
@BradThomas untuk mengulangi apa yang Anda kutip: "Bugtracker digunakan sebagai daftar TODO, dan tidak lebih" + "Fixed bug" -> "no TODO". Saya setuju di hampir semua situasi lain, Anda ingin catatan
Caleth

52

Menurut saya, itu tergantung apakah produk Anda dirilis dengan bug atau tidak.

Jika itu dirilis dengan bug yang Anda temukan, maka ya, buat laporan bug. Siklus rilis sering kali panjang dan Anda tidak ingin bug Anda dilaporkan sebagai masalah baru saat Anda sudah memperbaikinya.

Jika bug Anda belum terkirim, maka saya tidak akan mengikuti jalur yang sama. Anda sekarang akan meminta orang-orang mencoba membuat ulang bug Anda yang tidak dapat mereka lakukan karena bug tersebut belum dirilis, pada dasarnya membuang waktu mereka.


2
Lebih jauh dari ini, jika Anda memeriksa kode terhadap item pekerjaan, pertimbangkan untuk memeriksa perbaikan bug terhadap item kerja asli saat memperbaiki bug yang belum berhasil dirilis ke produk.
wablab

24

Anda harus melakukan ini jika itu adalah bug yang bisa dilaporkan oleh pelanggan. Kasus terburuk: Anda memperbaiki bug, tetapi tidak ada yang tahu. Pelanggan melaporkan bug. Rekan Anda mencoba untuk memperbaiki bug, tetapi tidak dapat memperbanyaknya (karena Anda sudah memperbaikinya). Itu sebabnya Anda ingin catatan bug.

Ini juga berguna jika Anda melakukan tinjauan kode, di mana biasanya kode akan ditulis untuk beberapa tugas dan kemudian ditinjau. Dalam hal ini lebih baik jika bug diperbaiki, yang mungkin memerlukan memasukkan sesuatu ke dalam daftar tugas Anda dan kemudian melakukan semua pekerjaan.


9

Ini tergantung pada beberapa faktor.

Pieter B dan Caleth, keduanya memberikan beberapa jawaban:

  • Apakah bug telah menjadi bagian dari rilis resmi?
  • Apakah jumlah bug / waktu yang dihabiskan untuk mereka dilacak secara khusus?

Ada juga prosedur internal yang harus diikuti, sering kali didukung oleh persyaratan sertifikasi. Untuk sertifikat tertentu, setiap perubahan kode harus dilacak ke catatan dalam pelacak masalah.

Selain itu, kadang-kadang bahkan perbaikan bug yang tampak sepele tidak sepele dan polos seperti yang pertama kali muncul. Jika Anda secara diam-diam bundel perbaikan bug seperti itu untuk pengiriman masalah yang tidak terkait, dan perbaikan bug kemudian ternyata bermasalah, ini akan membuat jauh lebih sulit untuk dilacak, apalagi mengisolasi atau mengembalikan.


2
Tentu saja Anda harus menyebutkan perbaikan bug dalam pesan komit, dan lebih baik buat komit terpisah untuk perubahan yang memperbaiki bug. (Dan mungkin pull-request atau patch-series terpisah, jika itu adalah perubahan yang berdiri sendiri). Satu-satunya pengecualian untuk itu adalah jika bug diperbaiki sebagai efek samping dari mengubah sesuatu untuk alasan yang berbeda (tapi kemudian tetap menyebutkannya dalam pesan komit). Satu-satunya pertanyaan adalah apakah perlu repot dengan pelacak bug, bukan apakah menggabungkan perubahan dengan hal-hal lain dalam satu komit!
Peter Cordes

3

Pertanyaan ini hanya dapat benar-benar dijawab oleh pimpinan proyek Anda, atau siapa pun yang bertanggung jawab atas "proses mencentang".

Tetapi izinkan saya bertanya dengan cara lain: mengapa Anda tidak merekam bug yang Anda tempel?

Satu-satunya alasan yang dapat dipahami yang saya lihat adalah bahwa upaya untuk mengajukan laporan bug, melakukan terhadapnya, dan menutupnya, adalah perintah besarnya lebih besar daripada waktu untuk memperbaiki bug.

Dalam hal ini, masalahnya bukan karena bug itu mudah diperbaiki, tetapi dokumennya terlalu lama. Seharusnya tidak. Bagi saya, overhead untuk membuat tiket Jira menekan c, lalu memasukkan ringkasan 1 baris pendek, dan menekan Enter. Uraiannya bahkan tidak di atas kepala, karena saya dapat memotong & menempelkannya ke pesan komit, bersama dengan nomor masalah. Pada akhirnya, . c <Enter>dan masalah ditutup. Itu bermuara pada 5 penekanan tombol overhead.

Saya tidak tahu tentang Anda, tetapi itu cukup kecil untuk menjadikannya kebijakan dalam proyek-proyek kecil bahkan untuk merekam setiap perbaikan bug dengan cara ini.

Keuntungannya jelas - ada beberapa orang yang dapat dengan mudah bekerja dengan sistem tiket seperti Jira, tetapi tidak dengan kode sumber; ada juga laporan yang dihasilkan dari sistem tiket, tetapi tidak dari sumber. Anda pasti ingin perbaikan bug Anda di sana, untuk mempelajari tentang perkembangan yang mungkin terjadi, seperti masuknya terus-menerus dari perbaikan bug 1-line kecil, yang dapat memberi Anda wawasan tentang masalah proses atau apa pun. Misalnya, mengapa Anda harus sering melakukan perbaikan bug kecil (dengan asumsi itu sering terjadi)? Mungkinkah tes Anda tidak cukup baik? Apakah perbaikan bug adalah perubahan domain, atau kesalahan kode? Dll


2

Aturan yang saya ikuti adalah bahwa jika bagian yang sedang Anda kerjakan tidak pernah dirilis dan bahkan belum berjalan dan belum ada pengguna yang melihatnya, perbaiki setiap bug kecil yang Anda lihat dengan cepat dan lanjutkan. Setelah perangkat lunak telah dirilis dan dalam produksi dan beberapa pengguna telah melihatnya, setiap bug yang Anda lihat mendapat laporan bug dan ditinjau.

Saya telah menemukan bahwa apa yang saya pikir bug adalah fitur untuk orang lain. Dengan memperbaiki bug tanpa meninjau bug tersebut, saya mungkin membuat bug alih-alih memperbaikinya. Masukkan laporan bug apa baris yang akan Anda ubah untuk memperbaiki bug dan rencana Anda tentang bagaimana bug itu harus diperbaiki.

Singkatnya: Jika modul ini tidak pernah diproduksi, perbaiki setiap bug yang Anda lihat dengan cepat dan ikuti spesifikasi. Jika modul sudah dalam produksi, laporkan setiap bug sebagai laporan bug untuk ditinjau sebelum diperbaiki.


1

Ya .


Ada beberapa jawaban yang telah memaparkan situasi di mana ada baiknya membuat laporan bug. Beberapa jawaban. Dan mereka berbeda.

Satu-satunya jawaban adalah tidak ada yang tahu. Orang yang berbeda, pada waktu yang berbeda , akan memiliki pendapat yang berbeda tentang masalah ini.

Jadi sekarang, ketika menemukan bug, Anda memiliki dua solusi:

  • merenungkan apakah layak membuka laporan bug, atau tidak, mungkin meminta pendapat seorang kolega ... dan kemudian, dalam beberapa kasus, menyesal karena Anda tidak melakukannya karena seseorang menanyakannya dan jika Anda sudah memiliki laporannya Anda bisa arahkan saja mereka ke sana
  • buat saja laporan

Membuat laporan lebih cepat, dan jika tidak ... mengotomatiskannya.


Bagaimana cara mengotomatiskannya? Menganggap pelacak Anda mendukung skrip, buat skrip yang dapat Anda panggil dan yang akan menggunakan pesan komit (judul dan isi) untuk mengirimkan laporan bug dan segera tutup sebagai "diterapkan", dengan revisi komit terkait untuk dilacak.


0

Saya akan menyetujui jawaban lain semua menawarkan aturan praktis yang baik dan beberapa bahkan menyentuh pada titik ini, namun saya pikir hanya ada jawaban yang benar-benar yakin di sini.

Tanyakan saja kepada manajer Anda . Baik manajer Anda atau sebagai alternatif memproyeksikan pemimpin atau scrum master dll tergantung pada bagaimana grup Anda disusun.

Ada banyak sistem praktik baik dan buruk yang berbeda, tetapi satu-satunya cara untuk mengetahui Anda melakukan hal yang benar untuk tim Anda adalah dengan bertanya.

Sesuatu di sepanjang baris percakapan koridor satu menit akan dilakukan: "Hei (bos), jika saya memperbaiki bug kecil yang hanya membutuhkan beberapa menit, apakah layak membuat tiket untuk itu atau haruskah saya menyebutkannya dalam pesan komit saya? " dan Anda akan tahu pasti. Semua praktik baik di dunia tidak berguna jika metode itu mengganggu tim dan manajer Anda.

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.