Haruskah saya mencatat perbaikan sepele?


28

Saya di toko kode dua. Dan sementara saya mengerti bahwa pelacak bug berguna di mana jumlah programmer lebih besar atau sama dengan satu, saya tidak begitu yakin bahwa logging bug, perubahan, dan perbaikan sepadan dengan waktu ketika mereka sepele. Ketika saya menemukan bug sederhana, saya memahaminya, memperbaikinya, dan menjalankannya melalui beberapa pengujian. Dan KEMUDIAN aku sadar aku harus mencatatnya.

Saya tahu secara teori bahwa bug logging harus dilakukan di suatu tempat antara menemukan bug dan memperbaiki bug, tetapi jika memperbaikinya lebih cepat daripada logging, sepertinya seperti hambatan. Di toko kode yang lebih besar, bos memperhatikan siapa yang melakukan apa dan senang mengetahui di mana orang lain mengolok-olok.

Saya menemukan diri saya menggambarkan hal-hal yang sudah saya perbaiki dan kemudian langsung menutupnya. Saya ragu siapa pun akan melihat bug yang ditutup ini lagi. Apakah sudah waktunya untuk memangkas proses lemak?


6
Ketika Anda menemukan bug, tuliskan apa bug itu di atas kertas. Ketika Anda memperbaiki bug, tulis file apa yang dimodifikasi. Sebelum Anda mengirim perbaikan, catat bug, lalu kirim perubahan. Jika Anda melakukan ini setiap kali Anda memiliki kebiasaan, saat ini Anda memiliki kebiasaan buruk, bug penebangan bukan buang-buang waktu.
Ramhound

5
Bagaimana Anda bisa yakin bahwa bug ini sepele?

2
@ashansky, apakah Anda bahkan membaca kalimat kedua dari pertanyaan saya?
Philip

1
Tidak mencatat pekerjaan Anda sendiri adalah cara yang pasti untuk a) tidak mendapatkan kredit untuk itu dan b) ditanya 'mengapa X tidak dilakukan dan mengapa Anda mengerjakan Y?'
Michael Durrant

1
Anda tidak dapat mencatat semuanya, itu tidak praktis. Mengapa beberapa orang melompat-lompat berpikir bahwa beberapa bagaimana tidak mencatat beberapa hal kecil SETIAP untuk tidak masuk sama sekali ???
Darknight

Jawaban:


36

Anda harus mencatat setiap perubahan yang Anda lakukan pada sistem Anda. Tidak ada yang salah dengan mencatatnya setelah acara - selama Anda menautkan laporan bug ke nomor perubahan.

Lalu jika ada masalah, Anda dapat melacak kembali ke bug dan mencari tahu mengapa Anda membuat perubahan yang Anda lakukan.

Dalam sebagian besar kasus Anda benar dan tidak ada yang akan melihat ini lagi, tetapi dalam 1 dari 100 ketika ada sesuatu yang salah informasi ini akan sangat berharga - terutama jika masalahnya hanya muncul 6 bulan ke depan.

MEMPERBARUI

Tentunya jika Anda masih mengembangkan fitur baru dan menemukan bug di bagian dari fitur yang Anda pikir sudah selesai, tidak perlu mencatatnya sebagai perubahan terpisah. Dalam kasus ini, saya akan mencatatnya pada item yang meminta fitur utama.

Setelah sistem dengan fitur telah diteruskan ke QA atau pelanggan, maka perlu untuk melakukan apa yang saya uraikan di atas.


Selama fase pengembangan awal, sebelum merilis versi pertama dari tim teknik maka tidak perlu mencatat perubahan dalam pelacak bug. Namun perubahan akan dicatat dalam log kontrol versi terhadap setiap pengiriman.
uɐɪ

@Ian Ini benar, tetapi umumnya selama pengembangan awal (dengan asumsi maksud Anda benar-benar mengembangkan dan bukan prototyping eksplorasi atau semacamnya) Anda biasanya akan bekerja melawan serangkaian fitur semacam. Dalam hal itu, setiap perubahan harus terhubung dengan fitur yang didukungnya. Perbaikan minor bug di baris ke fitur "selesai" masih bisa menautkannya untuk menunjukkan dukungan dari elemen itu. Pikiran Anda ini tergantung pada bagaimana Anda melacak fitur dan spesifikasi.
CodexArcanum

1
@Darknight - tidak mudah! Ini terbantu oleh fakta bahwa kami menggunakan TFS dan telah mengaturnya untuk tidak mengizinkan checkin yang tidak memiliki item pekerjaan terkait. Ya, Anda dapat mengesampingkan aturan, tetapi itu berhenti dan membuat Anda berpikir tentang apa yang Anda lakukan.
ChrisF

1
@Darknight Maaf, tetapi angka-angka itu tidak ada artinya. Mengatakan itu tidak benar; bahkan jika Anda bisa memvalidasi semua itu, lalu apa? Satu-satunya kesimpulan yang dapat saya tarik dari Anda yang menyajikan angka-angka itu adalah mencoba untuk memposisikan diri Anda di atas yang lain dalam beberapa cara, yang, sejujurnya, tampaknya sia-sia, tidak perlu dan garis batas kasar / ofensif.
casperOne

3
@ Semua Silakan bawa diskusi ini ke obrolan.
maple_shaft

14

Jika Anda menggunakan alat kontrol sumber, maka Anda dapat menjelaskan bug yang Anda perbaiki dalam deskripsi komit dan itu biasanya dokumentasi yang cukup untuk perbaikan bug super kecil, sepele.

Selain itu, jika Anda menggunakan pelacak bug / fitur yang sepenuhnya terintegrasi dengan kontrol sumber dan repositori Anda, seperti FogBugz dan Kiln , Anda akan dapat menggunakan alat pencarian global untuk menemukan perbaikan bug ini dan melihat perubahan kode apa yang telah Anda buat dengan cukup dengan mudah.

Plus, Anda dapat menetapkan ulasan kode untuk mitra pemrograman Anda sehingga dia dapat meninjau perbaikan sepele yang Anda buat, tapi saya ngelantur ...


1
Ya saya lakukan itu. Meskipun kadang-kadang saya menemukan diri saya memperbaiki hal-hal sementara di cabang dan menggabungkannya ke dalam komitmen lain.
Philip


@matthieu Tunggu, Jira terintegrasi dengan SVN? Ya ampun, mengapa kita tidak melakukan itu? Sepertinya ada beberapa plug-in.
Philip

5

Dari sudut pandang metrik, mungkin masih bermanfaat.

Informasi ini dapat digunakan untuk menunjukkan kepada bos sejumlah hal:

  • kami membutuhkan lebih banyak pengembang
  • sesuatu yang lain dalam proses ini rusak (mengapa begitu banyak bug? apakah orang lain menghasilkan sebagian besar bug), mungkin menunjukkan Anda memiliki terlalu banyak bug. Mungkin ada sesuatu yang menyebabkan ini? Apakah Anda melepaskan terlalu dini? Apakah pengujian cukup dilakukan?
  • daftar yang baik dari apa yang telah Anda kerjakan pada waktu bonus datang

Itu semua dikatakan, tergantung seberapa kecil bug yang Anda bicarakan. Satu liner yang Anda temukan saat menambahkan kode baru mungkin tidak ada gunanya untuk login misalnya.


2

Saya mencoba mencatat setiap perubahan yang saya lakukan terlepas dari ukurannya. Anda tidak pernah tahu kapan Anda, atau orang lain (masa depan atau sekarang), perlu kembali dan melihat apakah perubahan itu adalah kemungkinan penyebab sesuatu yang lain.


1

Pelacakan itu penting, tetapi pertimbangkan juga skenario lain: ketika tiba saatnya untuk ulasan Anda. Ini akan terjadi secara langsung, atau tanpa Anda di sana melalui atasan Anda, mengumpulkan laporan dari pelacak bug.

Pertimbangkan mereka 'gimmes' yang pada akhirnya meningkatkan angka Anda. Bagaimanapun, itu adalah bug yang telah Anda perbaiki, dan Anda harus dikenali untuk memperbaikinya, bahkan jika itu adalah perbaikan sepele.

Catat mereka.


Ya, di toko kode yang lebih besar bos memiliki "metrik" berdasarkan ini, jadi itu saran umum yang baik. Ini juga menyebabkan orang menyalahgunakan pelacak bug dan melemparkan metrik-metrik tersebut ke neraka yang tidak berarti. Tapi di sini hanya aku dan yang lainnya. Boss tidak menggunakan pelacak bug.
Philip

1

Untuk menjawab ini sangat tergantung pada di mana Anda berada dalam proses.

Ini dapat berlaku untuk proyek baru atau set fitur baru yang sedang dirancang.

Desain Awal Jika Anda menemukan bug pada kode yang kami buat selama desain awal maka membuat trek bug untuk itu tidak akan diperlukan. Saya akan menyarankan komit terpisah untuk perubahan sehingga Anda dapat dengan mudah melepasnya jika Anda menemukan masalah nanti.

Pengujian

Kode biasanya masih dianggap imatur selama pengujian unit jadi kecuali jika dilakukan oleh kelompok yang berbeda saya akan mengatakan tidak. Jika pengujian unit dilakukan oleh grup yang berbeda dari bug tracker adalah cara yang baik untuk memformalkan prosedur pengujian.

Pengujian CSCI tergantung. Apakah itu dilakukan oleh kelompok lain? Jika demikian maka ya (lihat di atas). Apakah ini langkah terakhir pengujian sebelum dirilis? Maka ya, karena pada titik ini perangkat lunak Anda harus dianggap matang. Jika Anda tertarik pada metrik maka akan lebih baik untuk mulai melacak bug pada titik ini.

Untuk setiap tingkat pengujian yang lebih tinggi maka Anda harus menggunakan pelacakan bug. Pada titik ini, perangkat lunak Anda harus dianggap matang dan pelacakan bug penting.

Melepaskan

Anda harus selalu melacak bug pada kode yang dirilis. Ini penting untuk akuntabilitas.

Memperlancar proses yang sesuai dengan kebutuhan Anda juga penting. Apakah Anda benar-benar membutuhkan sistem pelacakan kutu besar? Apakah semua bidang benar-benar penting bagi tim yang terdiri dari 2 orang?


1

Mungkinkah orang lain dapat menemukan bug, mungkin dalam versi yang lebih lama dari perangkat lunak yang telah dirilis ke dunia luar? Jika demikian, maka pencatatan bug dan perbaikannya dapat bermanfaat.

Yang lain menyarankan bahwa jika perlu waktu lebih lama untuk mencatat bug daripada memperbaikinya, maka itu tidak layak untuk dicatat. Saya menyarankan rentang waktu yang relevan bukan antara menemukan bug dan memperbaikinya, itu antara waktu bug diperkenalkan dan waktu perbaikan dilepaskan.

Jika perubahan dan lepaskan riwayat menunjukkan bahwa bug tidak pernah melihat cahaya hari ini, maka masuk perbaikan ketika Anda memeriksa ke dalam kontrol sumber harus memadai.

Ini cukup dekat dengan pertanyaan ini , tapi saya tidak yakin itu duplikat, karena yang satu ini berfokus pada perbaikan sepele .


1

Mengapa Anda tidak harus melacak bug, oleh Jon Arid Torresdal - perbaiki saja.

  1. Selama pengembangan: Anda menemukan bug untuk fitur; Anda menambahkan test case yang merusak build , lalu memeriksa perbaikan terhadap fitur tersebut.

  2. Setelah rilis: dokumentasikan perilaku tersebut . Jika Anda berencana untuk merilis pembaruan, goto 1. Jika Anda tidak bertanggung jawab atas rilis itu, pertahankan tes + fix yang disimpan di cabang pribadi.

Setelah kode dirilis, mungkin ada prioritas lain, dan sementara memperbaiki bug mungkin sepele, distribusi perbaikan mungkin tidak ekonomis sendiri, kecuali jika Anda melakukan penyebaran berkelanjutan.


-6

Tergantung seberapa sepele, saya menggunakan ukuran ini:

Jika butuh waktu lebih lama untuk login daripada yang dibutuhkan untuk memperbaikinya , itu tidak layak untuk dicatat.


3
Hanya karena butuh waktu lebih lama untuk log daripada memperbaiki tidak cukup pembenaran. Ha! yang ini punya penjelasan :)
uɐɪ

2
Saya tidak mengundurkan diri, tetapi jika saya harus menebak mengapa seseorang melakukannya, itu karena mereka percaya akan mencatat semua perbaikan bug, atau mereka pikir jawaban Anda tidak sangat membantu / wawasan.
CFL_Jeff

3
Saya tidak akan memilihnya tapi saya tidak setuju dengan ini sebagai aturan umum (walaupun dalam banyak kasus saya bisa melihatnya masuk akal!). Bagaimana jika Anda memiliki "kesalahan satu kali" yang dikirimkan, tetapi lolos dari jaringan QA? Butuh waktu lebih lama untuk login daripada memperbaiki ....
PhillC

2
Jika tidak dicatat maka tidak dapat diverifikasi diperbaiki oleh QA
17 of 26

3
-1 Ini hanya kesombongan pemrogram (' Saya tidak membuat kesalahan') dan ketidaktahuan (Saya tidak melihat sesuatu yang buruk terjadi dengan perbaikan kecil). Satu crash dan burn yang sangat bagus dari perbaikan 'minor' biasanya membantu dengan itu (juga dikenal sebagai pengalaman).
Michael Durrant
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.