Bagaimana Anda melacak bug di proyek pribadi Anda? [Tutup]

Saya mencoba untuk memutuskan apakah saya perlu menilai kembali proses pelacakan cacat saya untuk proyek rumah saya. Selama beberapa tahun terakhir, saya benar-benar melacak kerusakan menggunakan TODOtag dalam kode, dan melacaknya dalam tampilan tertentu (saya menggunakan Eclipse, yang memiliki sistem penandaan yang layak).

Sayangnya, saya mulai bertanya-tanya apakah sistem ini tidak berkelanjutan. Cacat yang saya temukan biasanya terkait dengan potongan kode yang saya kerjakan; bug yang tidak segera dipahami cenderung dilupakan, atau diabaikan. Saya menulis aplikasi untuk istri saya yang memiliki cacat parah selama hampir 9 bulan, dan saya terus lupa memperbaikinya.

Mekanisme apa yang Anda gunakan untuk melacak cacat dalam proyek pribadi Anda? Apakah Anda memiliki sistem khusus, atau proses untuk memprioritaskan dan mengelola mereka?

Fogbugz (lisensi individu gratis) jika proyeknya agak panjang atau daftar yang mudah dilakukan (menggunakan tugas Google)

Saya biasanya menggunakan sistem kontrol revisi berbasis web (Github, Bitbucket, Redmine, Google Code, ...) untuk menyimpan kode sumber dan melacak bug. Jika Anda merasa ada bug dalam kode tertentu, Anda dapat membuat masalah dengan nomor revisi / daftar perubahan / perubahan dan tentukan file mana dan rentang garis yang Anda curigai.

Saya biasa menggunakan spreadsheet / file teks per proyek (komentar ToDo dalam kode tidak skala dengan baik karena alasan Anda daftar; mereka lokal untuk kode, dan jika ada masalah yang tidak, itu cenderung menyelinap melalui retak).

Baru-baru ini saya telah menyiapkan server Redmine di jaringan rumah saya. Ini agak berat untuk "tim" satu, tetapi saya sedang mengerjakan beberapa proyek pada waktu saya sendiri, dan cenderung hanya menggunakan opsi Pelacak Isu + Repositori dengan mungkin halaman wiki aneh di tempat yang lebih kompleks.

Seorang teman saya bersumpah oleh Pivotal Tracker untuk tujuan yang sama, tetapi majikan saya saat ini menggunakan Redmine secara internal, jadi saya pikir ini akan memberi saya beberapa latihan. Itu tidak buruk.

Untuk proyek open source, saya hanya menggunakan pelacakan masalah GitHub.

Saya sebenarnya telah menginstal sistem bugtracker Gratis MANTIS di server web saya yang di-host (yang saya gunakan untuk blog dan hal-hal lain), dan menempatkan semua cacat saya di dalamnya.

Dengan kata lain saya menjalankan barang-barang saya seolah-olah itu profesional dan dibayar.

Saya menemukan itu membantu menjaga pola pikir yang lebih baik (menutup cacat, dll) serta konsisten (ish) dengan praktik lain yang biasa digunakan dalam industri.

Gunakan catatan TODO dalam kode, dll, juga - tetapi hanya untuk catatan atas diri seperti: "suatu hari saya harus membuat ini lebih efisien, semacam gelembung merusak kinerja". Atau untuk catatan lebih lanjut tentang di mana Anda bangun ketika Anda diangkut untuk makan malam :)

Saya menggunakan program ToDo List, kode sumber terbuka dari codeproject

http://www.codeproject.com/KB/applications/todolist2.aspx

Sangat bagus dan dengan banyak fitur.

Kami menggunakan JIRA di tempat kerja saya dan saya sangat menyukainya. Banyak produk dan orang yang terlibat dan mengelola semuanya dengan baik.

Saya datang mencari jawaban untuk ini beberapa waktu yang lalu dan sejak itu mengerjakan sebuah sistem yang sangat rapi dan sederhana, yang memenuhi tujuan-tujuan utama bagi saya:

Sasaran dalam urutan kepentingan:

1. Buatlah mungkin untuk memasukkan tugas / bug baru semudah mungkin, sehingga saya dapat mencatatnya segera setelah saya menemukannya atau memimpikannya, dan kembali ke pengkodean sebelum saya kehilangan tempat saya.
2. Buatlah mudah untuk melihat dan mengelola masalah tanpa banyak mencari, mengklik, menelusuri.
3. Buatlah mudah untuk dikaitkan dengan kontrol versi sehingga nantinya saya bisa mengetahui perubahan apa yang dilakukan untuk menyelesaikan masalah, atau tugas atau bug apa yang mendorong perubahan spesifik dalam kode.
4. Buat pengaturannya relatif mudah: instalasi dan konfigurasi minimal dan harga minimal.

(3 dan 4 kurang penting, dan saya akan baik-baik saja dengan sistem yang tidak menyediakannya, tetapi yang ini tidak).

Langkah 1: Dapatkan proyek di Bitbucket

Saya menggunakan bitbucket untuk pelacakan masalah dan untuk kontrol versi git (untuk proyek iOS di XCode misalnya). Saya melihat FogBUGz (yang telah saya baca selama bertahun-tahun di JoelOnSoftware) dan GitHub dan yang lainnya, tetapi bitbucket tampaknya memiliki fitur gratis terbaik yang ditetapkan untuk tim kecil.

Langkah 2: Gunakan Pelacakan Masalah Bitbucket dalam proyek

Selanjutnya saya mengatur pelacakan masalah dalam proyek bitbucket yang sama. Jadi proyek saya sekarang memiliki repositori git dan pelacakan masalah.

Langkah 3: Buat pelacakan masalah menjadi mudah!

Untuk ini saya menggunakan Kartu Bitbucket yang merupakan ujung depan seperti kanban yang sederhana untuk masalah Bitbucket. Anda hanya perlu masuk ke akun Bitbucket Anda dan mengatur kolom yang Anda inginkan. Saya memiliki empat kolom: Backlog, Next, Bugs, dan Resolved. (Saya berpikir untuk menggabungkan Bug dengan Backlog, tetapi tidak apa-apa untuk saat ini)

(Gambar ini dari blog Kartu Bitbucket, bukan dari proyek saya, maka kolomnya berbeda dari yang saya gunakan)

Kartu Bitbucket memungkinkan Anda mengatur filter yang sangat sederhana untuk setiap daftar tempat Anda memilih status dan jenis masalah yang masuk dalam kolom kartu. Jadi, openmasalah status semacam itu ada bugdi kolom Bug .

(Yang ini dari proyek saya: itulah cara saya memilih apa yang ada di kolom Bug)

Apa yang benar-benar keren adalah ketika Anda menyeret dan menjatuhkan kartu dari satu kolom ke kolom lain, itu akan secara otomatis mengubah status masalah yang diwakili oleh kartu untuk mencocokkan dengan definisi di kolom tujuan.

Hal baik lainnya tentang Kartu Bitbucket adalah tidak mudah habisnya waktu. Ini sangat penting karena tujuan dari seluruh pengaturan ini adalah untuk membuatnya mudah - jadi sistem ini bekerja untuk saya dan bukan saya yang bekerja untuk itu. Saya membuka bookmark halaman kartu saya dan tetap terbuka di tab Chrome sepanjang hari.

Ini menangani tujuan kedua saya.

Langkah 4: Ikat dengan kontrol versi.

Masalah Bitbucket cocok dengan kontrol versi (untuk sebagian besar pesaing) sehingga ketika saya selesai mengerjakan masalah saya komit git dengan pesan seperti "Menambahkan thingo ke whatsit. Perbaikan # 245". Jika saya melakukan ini, lalu dorong, lalu muat ulang halaman Kartu Bitbucket saya, saya akan melihat bahwa masalah telah pindah ke kolom Diselesaikan. Keren.

Ada tujuan ke-3 saya selesai.

Langkah 5: Lebih mudah untuk MENCIPTAKAN masalah.

Anda mungkin berpikir bahwa seluruh pengaturan ini sudah merupakan cara rumit untuk diatur, dan mengapa saya ingin menambahkan aplikasi web lain ke dalam proses. Nah, ingat tujuan utama saya di atas: Saya ingin membuatnya begitu mudah untuk menambahkan tugas sehingga saya tidak kehilangan pemikiran sebelum saya masuk ke area teks untuk mengetiknya, saya juga tidak ingin kehilangan tempat saya di kode pada saat saya selesai.

Sekarang, Kartu Bitbucket memang memungkinkan saya membuat tugas dengan cukup mudah, tetapi itu hanya sedikit untuk klik / scrolly untuk sepenuhnya memenuhi tujuan # 1. Anda harus mengklik Buat Masalah; kemudian muncul editor modal; setelah memasukkan judul masalah Anda, Anda harus menggulir ke bawah untuk menentukan jenis (bug / tugas) dan prioritas; lalu klik buat.

Alih-alih saya memilih untuk menggunakan aplikasi Bitbucket kedua yang disebut taskrd .

Anda dapat mengatur taskrd, dengan memberinya login Bitbucket Anda, dan mengaturnya di bookmark dan tab, dan tetap buka sepanjang hari, seperti halnya kartu Bitbucket. Taskrd memiliki alur kerja yang lebih sederhana untuk menambahkan tugas baru, ketik saja di, opsional mengatur jenis dan prioritas, dan tekan tombol Add.

(gambar ini dari blog Taskrd)

Sekarang dapat diperdebatkan bahwa tidak sepadan dengan upaya menyiapkan Taskrd alih-alih menggunakan Kartu Bitbucket atau bahkan sistem entri-bit Bitbucket sendiri. Setelah semua, dengan Taskrd saya harus mengklik tab pada browser saya, dan klik Muat Ulang pada halaman saya dengan Bitbucket Cards untuk itu untuk menyegarkan dan mendapatkan masalah baru yang saya tambahkan di aplikasi Taskrd. Tetapi pada kenyataannya, saya menemukan bahwa saya pada umumnya dalam mode atau yang lain: Entah saya menggunakan Bitbucket Cards untuk mengatur apa yang saya lakukan selanjutnya, atau untuk melihat daftar bug, atau saya sedang sibuk coding dan memasukkan tugas / bug saat mereka terjadi pada saya - semua dalam mode api cepat. Untuk mode kerja ke-2 ini, Taskrd luar biasa: Saya hanya membiarkannya terbuka pada monitor terpisah, dan dengan cepat memasukkan masalah saat saya bekerja.

Sehingga mencakup tujuan # 1.

Tujuan terakhir saya adalah pengaturan yang mudah / murah. Yah murah itu: semua ini gratis. Bitbucket memiliki repositori pribadi gratis untuk hingga lima pengguna dan aplikasi lainnya gratis. Setup tampaknya non-sepele berdasarkan pada di atas, tetapi sebenarnya bagian yang paling rumit adalah menyiapkan git untuk mendorong ke repositori bitbucket yang akan sama di mana saja. Saya tidak perlu menginstal apa pun, dan menghubungkan kedua aplikasi ke repositori bitbucket saya cukup mudah. Menyiapkan kolom kartu bagaimana saya suka mereka butuh sedikit bermain-main tetapi tidak terlalu sulit.

Membaca ini kembali, saya mungkin terlihat sedikit menggigil untuk Bitbucket - tapi saya benar-benar tidak bermaksud demikian. Hanya saja saya telah menggunakan proses ini selama berminggu-minggu - setelah bertahun-tahun mencoba konfigurasi yang berbeda untuk melacak apa yang saya lakukan - dan saya benar-benar menggali itu, jadi saya pikir saya akan meluangkan waktu untuk menjelaskannya kepada orang lain.

Jika Anda terbiasa menggunakan tag TODO di Eclipse, langkah mudahnya adalah menggunakan Mylyn . Pada dasarnya, ini adalah daftar todo sederhana. Tapi, itu juga mengaitkan konteks dengan tugas - klik pada tugas untuk mengaktifkannya, melakukan beberapa hal, dan kemudian saat Anda mengaktifkannya, Eclipse akan membuka kelas yang relevan, dan menunjukkan kepada Anda metode yang relevan. Bahkan lebih kuat, jika Anda akhirnya pindah ke beberapa sistem pelacakan bug lainnya, Mylyn dapat menarik tugas dari sistem tersebut dan menyajikannya dalam IDE Anda.

Sebagian besar unduhan Eclipse akhir-akhir ini memiliki Mylyn yang dibundel sebagai standar. Cukup cari tampilan Daftar Tugas dan mulai menambahkan tugas.

Saya menggunakan lisensi pemula $ 10 untuk Jira. Ini murah dan saya sudah tahu betul dari pekerjaan.

Seperti orang lain di sini, saya menggunakan file teks atau pelacak bug yang dibangun pada layanan hosting dvcs apa pun.

Banyak hal tergantung pada "proyek pribadi" macam apa itu. Apakah itu sesuatu yang akan pernah melihat cahaya hari atau hanya sebuah eksperimen? Apakah proyek ini digunakan oleh publik?

Sebagai contoh, salah satu proyek pribadi saya menjadi cukup populer dan membuat situs Get Satisfaction agar berfungsi dengan sangat baik. Tidak benar-benar "pelacakan bug" tetapi ini berfungsi baik untuk permintaan bug / fitur.

Agak terkejut belum ada yang mengatakan ini, tetapi ada solusi pelacakan bug didistribusikan yang bertindak sebagai bagian dari kontrol sumber didistribusikan Anda yaitu database bug hidup dengan kode Anda di kontrol revisi Anda. Implementasi terkenal termasuk "Bugs Everywhere", Fossil dan Ditz.

Lihat https://stackoverflow.com/questions/773818/distributed-projectmanagement-bug-tracking dan https://stackoverflow.com/questions/1851221/distributed-bug-tracker-to-go-with-dvc?rq=1 untuk diskusi.

Untuk proyek pribadi saya, saya menggunakan Omnifocus.

Pembaruan: 25/10/2010 Jika saya menemukan bug yang tidak dapat atau tidak ingin saya perbaiki segera, saya segera menambahkannya ke kotak masuk Omnifocus. Kemudian nanti, ketika saya sedang melakukan review saya akan mengumpulkan semua info yang saya pikir saya perlu untuk memperbaiki bug dan kemudian menambahkannya ke proyek. Posisi itu dalam daftar tugas menunjukkan itu relatif penting.

Saya memperlakukan bug dengan cara yang sama seperti persyaratan / fitur dalam banyak hal.

Untuk proyek pribadi, TODO-komentar dan file teks dengan TODOs dan bug dll biasanya cukup bagi saya.

Saya menggunakan TheKBase saya sendiri (karena saya menggunakan OSX, saya menggunakannya di .Net di mesin virtual atau Mono, tergantung pada suasana hati saya). Hanya untuk satu pengguna secara bersamaan, tetapi: Ini memungkinkan untuk beberapa hierarki, sehingga berpindah dari pengelola tugas ke pengelola informasi yang tidak kehilangan langkah di antaranya. Plus itu open source di Github dan gratis (itu jelas, saya kira).

Bagi yang penasaran, instruksinya ada di sini .

Saya menggunakan ToDoList untuk proyek pribadi saya; ringan, gratis, dan memiliki banyak fitur. Tidak yakin seberapa baik timbangan untuk proyek tim, tetapi bagus untuk saya bekerja sendiri. Saya tidak yakin bagaimana saya bisa bertahan hidup menggunakan daftar tugas built-in Visual Studio begitu lama, itu omong kosong.

Kami menggunakan kombinasi JIRA dan Google Docs dan Spreadsheets. Saya melihat ke alat-alat lain karena instalasi JIRA kami lebih tua dari kotoran dan tidak semudah digunakan seperti antarmuka yang lebih baru, lebih menarik, seret dan jatuhkan.

Saya melihat Manymoon, Proyek Zoho, Insightly, Redmine, dan Assembla. Kita akan bereksperimen dengan alat Stand Up gratis Assembla . Ini adalah antarmuka pelaporan lapangan 3 yang sangat sederhana yang menanyakan setiap anggota tim 3 pertanyaan: Apa yang Anda lakukan minggu lalu? Apa yang akan kamu lakukan minggu ini? Hambatan apa yang menghalangi Anda?

Pada akhirnya, saya pikir saya akan tetap menggunakan JIRA, Google Documents, dan alat Assembla Stand Up, karena kombinasi memberi saya semua yang saya butuhkan.

Saya paling suka Trac, karena ringan, mudah digunakan dan mudah dikonfigurasi. Dan wiki terintegrasi dan browser repositori yang elegan merupakan nilai tambah yang besar.

Di tempat kerja kami menggunakan JIRA, yang juga cukup bagus, tetapi tidak begitu mudah untuk dikelola. Dan saya benar-benar kehilangan wiki (integrasi dengan Confluence tidak begitu bagus) dan browser repositori yang baik (kami hanya memiliki ViewVC).

Saya telah menggunakan Trac selama beberapa tahun terakhir. Saya telah menggunakan Bugzilla dan JIRA juga. Proyek konsultasi pribadi dan pribadi saya melibatkan Trac hanya karena saya sudah terbiasa dan untuk mendapatkan proyek dalam pengaturan dev pribadi saya membutuhkan sedikit usaha karena upaya sudah selesai. Saya memiliki trac yang terhubung dengan semua yang saya butuhkan termasuk SVN atau Git dan Hudson (atau lebih tepatnya Jenkins sekarang).

Pada beberapa proyek klien pada umumnya tidak ada pilihan selain apa yang mereka gunakan, yang cukup sering tidak ada atau sialnya. Saya terkejut ketika mereka memiliki pelacak bug akhir-akhir ini. Namun secara pribadi, saya menantikan penawaran yang lebih baik dari komunitas OSS daripada Trac. Ini bisa menyelesaikan banyak hal tapi belakangan ini seperti tambal sulam.

Saya tidak melihat gunanya menggunakan pelacakan bug formal untuk proyek one-man kecil. Biasanya saya hanya menyimpan daftar mental (sangat singkat) dan memperbaiki bug ketika saya menyadarinya. Tentu saja ini tidak skala untuk proyek besar / multi-orang, tetapi intinya adalah bahwa itu tidak perlu.

Jika Anda menggunakan ReSharper, ia memiliki TODO tracker, yang menunjukkan daftar semua TODOs, NOTEs dan BUGs dalam solusi Anda. Itu juga menyoroti mereka dalam kode Anda dalam warna apa pun yang Anda pilih. Saya menemukan ini sangat berguna pada proyek saya sendiri.