Menjadi Pemecah Bug yang Lebih Baik


24

Saya suka menjadi programmer. Di sana, saya mengatakannya. Namun, dengan mengatakan itu, saya menyadari akhir-akhir ini bahwa saya benar-benar tidak tahan dengan perbaikan bug. Sama sekali.

Bahkan, ketika saya sedang mengembangkan sesuatu, produktivitas saya sangat tinggi. Bahkan ketika menulis unit-test dan melakukan pengujian mandiri terhadap perkembangan saya, saya umumnya sangat produktif. Saya bisa fokus dengan baik, dan saya bisa menyelesaikan tugas.

Namun, ketika waktu QA tiba dan saya sedang memperbaiki bug, inspirasi saya menukik tajam. Saya harus memaksakan diri dengan langkah-langkah yang cukup ekstrem (Anda tahu, musik BPM tinggi, kafein dalam jumlah berlebihan, dll) untuk menyelesaikan sesuatu . Pekerjaan saya biasanya terlibat dengan melangkah ke proyek besar yang sudah ada dan menambahkan fitur baru atau memperbaiki bug, jadi saya tidak bisa memberi tahu majikan saya bahwa saya perlu beberapa minggu untuk menulis unit test untuk semua kode mereka :) Selain itu, teknologi server yang sering kita gunakan sangat menghambat pengujian unit dan integrasi, karena memiliki beberapa masalah Java classloader. Saya tidak sepenuhnya menentang perbaikan bug, kadang-kadang bisa menyenangkan, tetapi itu tidak menyenangkan sama sekali ketika Anda harus membuat perubahan kecil dan menunggu 30 detik hingga 3 menit untuk dapat melihat apakah mereka berfungsi atau tidak (karena cara sistem bekerja).

Bagaimana saya bisa meningkatkan produktivitas dan motivasi saya ketika memperbaiki bug? Apakah ini sesuatu yang ditangani sebagian besar programmer?


4
"jadi saya tidak bisa memberi tahu majikan saya bahwa saya perlu beberapa minggu untuk menulis unit test untuk semua kode mereka" . Apakah ada alasan untuk itu? Saya sering melakukan itu, dan itu benar-benar bermanfaat bagi semua orang. Maksud saya, jika Anda mengambil 3 minggu untuk unit test, Anda mungkin hanya menyimpan 3 minggu perbaikan bug. Biasanya saya bahkan menemukan banyak bug yang akhirnya benar-benar berada di bawah radar QA. Tentu, Anda mungkin tidak ingin melakukannya sendiri.
netcoder

10
Jangan menulis bug di kode Anda ... masalah terpecahkan.
Michael Brown

3
Saya hampir lebih suka memperbaiki bug daripada menulis kode baru. Saya terutama lebih suka menulis unit test. Mungkin saya aneh.
Paul Tomblin

1
@ PaulTomblin Saya mengerti apa yang Anda katakan. Saya tahu beberapa pengembang yang menyukai pengembangan frontend ... saya, saya paling suka kode non-UI. Menulis kode baru kadang-kadang sulit karena Anda terkadang mendapat "blok penulis"
Michael Brown

1
Sulit untuk mengukur "produktivitas" perbaikan bug karena Anda mungkin menghabiskan banyak waktu untuk mencari tahu apa yang "bukan masalahnya", sama seperti Edision yang mengaku mengatakan bahwa ia menemukan "1000 cara BUKAN untuk membuat bola lampu ", dan saya pikir bahwa non-fixes sering bersifat instruktif dalam mengajari Anda petunjuk apa yang penting dan tugas perbaikan bug saat ini (dan di masa depan).
Zeke Hansell

Jawaban:


21

sama sekali tidak menyenangkan ketika Anda harus melakukan perubahan kecil dan menunggu 30 detik hingga 3 menit untuk dapat melihat apakah mereka berfungsi atau tidak

Itulah masalah sebenarnya di sini. Anda merasa tidak produktif ketika Anda harus menunggu begitu lama untuk umpan balik, saya tahu perasaan itu. Mungkin dimungkinkan untuk memalsukan lebih banyak layanan dan membuat alat uji yang lebih baik sehingga Anda bisa mendapatkan umpan balik segera.

Unit pengujian kode lama mahal atau bisa melibatkan refactor yang berbahaya. Namun, menciptakan perlengkapan uji yang lebih baik dapat membuat Anda memberikan tes dalam hitungan detik dibandingkan dengan menit dan Anda bisa mendapatkan produktivitas yang hampir sama dengan bekerja dengan kode unit yang baru dapat diuji.

Menunggu begitu lama untuk umpan balik itu membosankan dan mendemotivasi, bukan tindakan memperbaiki bug itu sendiri.


Pernah membaca Mythical Man-Month? Bayangkan saja menunggu sampai keesokan paginya dan mencoba menganalisis tumpukan tumpukan / daftar isi yang ada pada saat kegagalan ...
sq33G

@ sq33G Atau lebih buruk lagi, memiliki tim pengujian Anda di India yang hanya dapat Anda ajak bicara melalui email (kisah nyata).
Garrett Hall

13

Memperbaiki bug adalah keterampilan yang sangat penting yang harus Anda pelajari. Saya membaca di suatu tempat bahwa, biasanya seseorang menghabiskan 80% waktu untuk memperbaiki 20% masalah dalam suatu aplikasi.

Saya percaya belajar dari kesalahan, dan memperbaiki bug adalah kesempatan untuk belajar dari kesalahan orang lain . Anda bisa belajar dan akan membantu menjadi programmer yang lebih baik di masa depan. Ini adalah motivasi yang saya miliki ketika saya mulai memperbaiki banyak bug dan bergerak maju untuk memfaktorkan ulang kode .


1
Apa yang Anda tulis itu benar; Namun, 80% / 20% Anda hanya benar karena ada begitu banyak kode jelek di alam liar. Maksud saya jelek, kurang dirancang atau over-architected atau salah-architected atau hanya praktek ceroboh (pemrograman crack-head). Yang sedang berkata, tidak ada yang salah dengan pengembang lebih memilih pengembangan daripada memperbaiki bug. Tambahkan fakta bahwa sebagian besar perangkat lunak dirancang dengan buruk sejak awal dan Anda sudah mengatur sebagian besar pemecah bug untuk kegagalan.
Wil Moore III

@wilmoore: Anda benar dengan kode jelek, dan ada juga persyaratan yang berubah.
ManuPK

6

Secara pribadi, saya merasa terbantu untuk berhenti menganggap bug sebagai 'hal kecil' tetapi lebih sebagai penghibur besar yang sama pentingnya dengan fitur besar meskipun mereka hanya melibatkan perubahan beberapa baris kode setelah berjam-jam melakukan debugging. Dengan begitu, menghabiskan satu hari penuh untuk membunuh 3 entri pelacak kutu jauh lebih menyedihkan (pendekatannya sedikit tergantung pada kemampuan pribadi Anda untuk berbicara kepada diri sendiri untuk mempercayainya :-).

Mungkin itu membantu untuk menjadikannya permainan, misalnya bersama dengan rekan kerja Anda ( siapa yang paling banyak memperbaiki bug sehari? Atau, lebih buruk lagi, siapa yang paling sedikit membangun kembali sehari? )


Saya sangat tidak setuju dengan membuatnya menjadi permainan memperbaiki bug paling banyak dalam sehari, atau yang sejenisnya. Beberapa bug sepele untuk diisolasi dan diperbaiki setelah Anda tahu cara memicu mereka: rekatkan nilai tertentu ke dalam bidang ini, dan perhatikan: panjang yang tersisa sekarang salah. (Mungkin Anda menghitung byte alih-alih karakter dan lupa tentang ruang di atas, katakanlah, U + 007F.) Yang lain (terutama bug yang melibatkan berbagai kondisi ras atau multithreading) dapat dengan mudah membutuhkan waktu berhari-hari untuk mereproduksi, tetapi sangat penting ketika mereka melakukannya terjadi di lapangan. Mereka berdua hanya menjamin satu entri di pelacak bug.
CVn

Menghitung bug seperti itu sama artinya bahwa setiap orang hanya akan memperbaiki bug sederhana daripada mengatasi kondisi ras yaitu .. tetapi bukankah demikian halnya dengan perbaikan bug yang tidak termotivasi dan tidak fokus juga? :-) Tidak membiarkan bug 'keras' mendukung hal-hal sederhana adalah topik yang sama sekali berbeda.
Alexander Gessler

Ada juga masalah kualitas perbaikan. Dalam banyak kasus, Anda dapat membuat perbaikan cepat-ish untuk bug tanpa sampai ke penyebabnya, tetapi kemudian kesalahan yang sama muncul baik di tempat lain atau dalam situasi lain. Memahami dan memperbaiki sifat kesalahan seringkali membutuhkan waktu lebih lama, tetapi umumnya mengarah ke perbaikan yang jauh lebih kuat. Kecuali itu "ini gagal sepanjang waktu dalam produksi dan kami harus mempublikasikan perbaikan sekarang ", saya tahu pendekatan mana yang saya lebih suka (dan bahkan jika itu, akan kembali untuk memperbaiki tulang yang patah daripada hanya memotong tulang akan menjadi sebuah ide bagus).
CVn

5

Saya sudah di sepatu Anda. Buat tes otomatis kapan dan di mana Anda bisa. Tidak harus sekaligus. Ketika Anda menemukan bug, luangkan waktu sebentar untuk mencoba memprogram kasus uji. Jika Anda tidak dapat memprogram kasus uji, tulis uraian singkat tentang cara mengujinya secara manual, misalnya klik di sini, ketik ini, dll. Dan masukkan ke dalam semacam Basis Pengetahuan.

Debugging bisa sangat melelahkan, terutama dengan kode rumit yang tidak Anda tulis. Datang dengan tujuan, "Perbaiki Bug 13533 pada hari Jumat". Kemudian siapkan hadiah jika Anda memenuhi tujuan, "Ambil satu gelas bir dengan teman-teman saya Jumat malam". Ini akan membantu membuatnya lebih bermanfaat.

Selain itu, terkadang kerja hanya itu ... pekerjaan.


Untuk proyek saat ini, saya sudah, pada kenyataannya, tes unit tertulis. Satu-satunya masalah adalah bahwa tidak peduli apa yang saya bisa buktikan menggunakan unit test saya, semuanya masuk neraka dalam produksi / kehidupan nyata, karena masalah dengan teknologi server. Sayangnya, tidak ada alternatif lain dan saya tidak ada di tempat untuk mengganti mesin, sehingga untuk berbicara.
Naftuli Kay

Anda perlu menulis rutin "pengendali kesalahan tak terduga" untuk membantu Anda menangkap mereka ;-)
Zeke Hansell

2

Dalam situasi seperti ini, Anda membutuhkan semacam tantangan kreatif. Biasanya, ini menulis kode, tapi ini bukan.

Tapi, semua tidak hilang. Berusahalah memecahkan masalah meta Anda dan tuangkan energi Anda ke dalamnya. Mengapa butuh 30 detik hingga 3 menit untuk mendapatkan umpan balik? Bagaimana Anda bisa mempersingkat waktu itu? (Mungkin Anda dapat menulis semacam skrip atau aplikasi utilitas yang tidak Anda periksa yang membantu Anda melakukan ini). Itu domain masalah baru Anda - tantangan kreatif baru Anda.

Secara pribadi, setiap kali saya dalam fase memperbaiki cacat, saya mengidentifikasi hambatan terbesar saya untuk menyelesaikannya dengan cepat dan tanpa rasa sakit, dan saya mengotomatiskan apa yang saya butuhkan untuk mengotomatiskan untuk menghilangkan hambatan itu. Ini sering menghasilkan peningkatan produktivitas dan penambahan pada portofolio pribadi saya untuk di-boot.

Jadi, singkatnya, saya akan mengatakan "selalu berkembang." :)


Aku mendengarmu. Saya berharap bisa melakukan sesuatu untuk mengotomatisasi sesuatu. Saya punya server dan klien, dan saya tidak bisa mengotomatiskan klien dengan mudah. Ada beberapa tahap dalam alur kerja hal ini dan banyak bug muncul di antara tahap, jadi saya harus melakukan tahap kedua 30, kemudian tahap 3 menit, atau secara terbalik. Intinya, ini mimpi buruk> :)
Naftuli Kay

2

Apakah masalah Anda debugging atau memperbaiki bug? Jika Anda dapat men-debug cukup untuk mengisolasi komponen yang menyebabkan masalah, maka lihat itu sebagai tugas pengembangan baru.

  1. Tulis beberapa tes unit hanya untuk sepotong kode yang melanggar. Pastikan Anda memiliki tes yang memvalidasi semua fungsi yang diinginkan, ditambah beberapa yang secara khusus mengisolasi perilaku buggy.
  2. Tulis kode baru yang lulus semua tes yang baru saja Anda tulis.
  3. Ganti kode lama dengan yang baru.
  4. Jalankan beberapa tes integrasi. Di sinilah Anda akan mengalami reboot server tiga menit, tetapi harus diminimalkan jika Anda melakukan langkah 1-3 dengan baik.
  5. Voila!

2

Mungkin Anda harus melihat Debugging Myself karya Brian Hayes , sebuah artikel yang muncul di American Scientist pada 1995. Anda bisa mengambil langkah-langkah (seperti kebiasaan menggunakan Kondisi Yoda ) untuk mengurangi atau menghilangkan jenis bug yang paling dibenci yang Anda hasilkan.

Saya berpendapat bahwa debugging adalah keterampilan yang berbeda dari pemrograman, meskipun terkait. Secara khusus, debugging program multi-utas hampir seluruhnya berbeda dari menulisnya.


1

Jika pengembangan perangkat lunak membosankan, Anda salah melakukannya. Dengan kata lain, itu bukan masalah dengan Anda, tetapi masalah dengan platform dan proses Anda. Sudahkah Anda mempertimbangkan untuk mencari posisi menggunakan bahasa dinamis (mis. Python, Ruby, JavaScript), di mana Anda tidak harus menunggu server restart?


Sayangnya, ini bukan opsi pada tahap ini. Plus, alur kerja, sebagaimana disebutkan di atas, membutuhkan beberapa tahap dan langkah dan bug muncul di antara tahap-tahap ini. Jika saya menulis ini dari awal, saya pasti akan melihat menggunakan bahasa scripting, tapi kami terjebak dengan apa yang kami miliki untuk saat ini.
Naftuli Kay

1
@TK: Di perusahaan terakhir saya, kami berhasil mengintegrasikan Groovy ke proses pengembangan Java kami untuk mengotomatiskan proses manual sebelumnya. Ini bukan Java, tetapi cukup dekat, dan sangat efektif sehingga kami memiliki sedikit push-back.
kevin cline

1

Itu bagian dari pekerjaan, sayangnya. Anda akan memiliki proyek-proyek jelek dan majikan-majikan yang jelek (saya tidak mengatakan demikian halnya di sini, hanya menggeneralisasi).

Anda dapat menulis tes unit terhadap kode mereka. Menyerapnya sebanyak mungkin. Setelah Anda memiliki sesuatu yang dapat Anda tunjukkan kepada bos, Anda mungkin dapat membalikkan keadaan.

Gunakan alat debugging untuk memperbaiki kelambatan, gunakan unit test untuk menguji kode baru dan gunakan mereka untuk memperbaiki masalah kode yang ada serta memecah kode yang ada menjadi potongan-potongan yang lebih kecil.

Anda bisa menjadikannya tantangan dan menjadi pahlawan peningkatan proses. Dan, jika itu tidak berhasil, Anda akan memiliki pengalaman yang baik untuk dibawa ke majikan berikutnya.


1

Sebagian besar programmer harus berurusan dengan masalah pribadi memperbaiki bug di beberapa titik dalam karir mereka.

Perasaan jarak orang-ke-kerja yang tepat sangat penting untuk motivasi Anda. Jangan melebih-lebihkan atau tidak mengidentifikasi pekerjaan Anda. Jika Anda terlalu mengidentifikasi diri Anda dengan pekerjaan Anda, masalah seperti yang telah Anda uraikan dapat muncul: Anda mungkin sangat enggan untuk memperbaiki bug karena Anda separuh waktu menyalahkan diri sendiri. Dapatkan jarak batin dan cari tahu bagaimana Anda bisa mengerjakan masalah Anda secara rasional.

Mengenai masalah khusus pada platform Anda, ada beberapa cara untuk mengurangi waktu penggunaan dan pengujian yang lama (dan, di samping itu, masalah Anda tidak terlalu lama).

Pertama, semakin lama waktu pengujian Anda, semakin Anda tidak suka kultus kargo. Jika Anda melakukan perubahan, pikirkan tentang hal itu sampai Anda yakin itu akan memperbaiki bug . Tentu saja, seberapa percaya diri Anda tergantung pada lamanya siklus tes Anda. Tetapi jika siklus tes Anda menjadi lebih lama, dan tes panjang tidak dapat dihindari, habiskan lebih banyak waktu untuk berpikir, dan Anda akan dihargai dan lebih senang dalam debugging karena lebih cepat dan memiliki efek yang memuaskan dari saat yang baik dari "fiat lux ".

Kedua, lebih condong ke arah tes unit dan lebih sedikit ke arah tes integrasi. Hapus setiap titik kegagalan dari platform sulit untuk debug yang Anda bisa.


1

Memperbaiki bug bisa "mengagumkan" atau "membosankan". Saya memiliki beberapa kredit game yang sepenuhnya karena memperbaiki satu bug - bug kerusakan yang tidak bisa diperbaiki oleh orang lain. Tetapi perawatan bugzilla sehari-hari sangat melelahkan. Bug kecil itu membosankan. Bug utama layak.

Inilah realisasinya: Fakta bahwa Anda memiliki daftar bug minor raksasa itu sendiri adalah satu bug utama. Itu bukan bug kode. Ini adalah bug proses atau manajemen.

Temukan bug itu, dan perbaiki.


1

Satu hal yang saya temukan di antara kolega dan pembebasan yang baik "debuggers / bug fixer / pemecah masalah" adalah bahwa mereka umumnya suka memecahkan teka-teki. Itu mungkin berarti teka-teki silang, permainan angka (seperti Sudoku), dan teka-teki logika, dll ...

Jadi salah satu cara Anda mungkin menjadi pemecah bug yang lebih baik adalah dengan meluangkan waktu untuk mengerjakan keterampilan memecahkan masalah atau memecahkan teka-teki.

Berikut adalah tautan Wikipedia yang mungkin merupakan titik awal yang baik untuk berbagai hal untuk membantu Anda menjadi pemecah masalah yang lebih baik.

Pikiran Anda, beberapa orang hanya lebih baik dalam pemecahan masalah, atau mereka hanya lebih menikmatinya. Beberapa orang tidak menyukainya sama sekali, yang membuatnya sulit untuk memaksa diri Anda untuk melakukan - tetapi jangan membuat kesalahan - jika Anda memaksa diri Anda untuk belajar menjadi pemecah teka-teki, itu akan membuatnya lebih mudah untuk menjadi pemecah bug yang baik di masa depan .


0

Memperbaiki bug biasanya terasa seperti tugas karena bisa membuat Anda merasa bug menghabiskan seluruh waktu Anda dan menjauhkan Anda dari hal-hal baru yang menyenangkan. Namun kenyataannya adalah bahwa memperbaiki bug adalah bagian yang sangat besar dari apa yang kita lakukan, dan itu dimulai sejak menulis baris pertama kode dan menjalankan kompiler. Saat Anda merilis kode untuk pertama kalinya, Anda mungkin telah menghabiskan waktu berjam-jam memperbaiki bug, hanya saja sepertinya tidak begitu karena Anda telah memperbaikinya sebagai bagian dari proses penerapan fitur. Secara realistis, tidak peduli seberapa bagus programmer Anda, bug akan masuk ke sistem Anda.

Jadi bagaimana Anda membuatnya menyenangkan? Yah, saya tidak bisa menjawabnya untuk Anda karena saya benar-benar tidak bisa membayangkan apa yang mengapung perahu pribadi Anda. Bagi saya, saya sedikit pecandu alat, jadi jawabannya adalah memiliki rantai alat yang sangat andal, dan proses pengembangan yang fleksibel yang semuanya berkontribusi untuk membuat perbaikan bug lebih sedikit dari tugas, dan lebih sederhana masalah untuk dipecahkan segera. Saat ini saya mengembangkan sebagian besar dalam C #, dan saya selalu mencari alat yang akan menghilangkan waktu yang membosankan membuang-buang bagian dari perangkat lunak penulisan. Saya menggunakan pendekatan pengembangan pengujian pertama yang didukung dengan API BDD yang sangat bagus yang disebut StoryQ . Saya menggunakan Resharper untuk mengotomatiskan sebagian besar refactoring saya dan StyleCop untuk menjaga hal-hal seperti gaya pengkodean. Tambahan terbaru saya ke rantai alat telah disertakanNCrunch yang menjalankan tes saya secara terus menerus dan bersamaan di latar belakang saat saya kode, dan itu benar-benar NCrunch yang telah terbukti menjadi pengubah permainan.

Kombinasi dari semua alat ini telah melihat produktivitas saya menembus atap akhir-akhir ini, karena saya hanya membuang sedikit waktu menunggu hal-hal untuk dikompilasi atau dieksekusi. Saya mendapatkan umpan balik instan secara visual dalam IDE saya untuk memberi tahu saya bahwa saya memiliki masalah untuk diperbaiki, dan saya menjabarkan kode pengujian saya sedemikian rupa sehingga saya dapat menunjukkan dalam hanya beberapa baris kode tempat yang tepat di mana tidak hanya kegagalan terjadi, tetapi ke tempat penyebab kegagalan terjadi karena laporan verbose indah yang saya dapatkan StoryQyang memberitahu saya persis bagian mana dari tes saya lulus, yang gagal, dan di mana dalam kode kegagalan tersebut. Dengan semua pemborosan waktu dihapus dari waktu pengembangan saya, saya menghabiskan sangat sedikit waktu aktif debugging, dan lebih banyak waktu menyelesaikan masalah dan menulis tes dan kode. Masalah turnover tinggi membuat saya sibuk, dan membawa banyak variasi dalam tugas saya. Ini juga memberi saya banyak waktu untuk mengejar bidang minat lain selama hari kerja saya sehingga saya dapat menyuntikkan ide-ide baru dan inovatif ke dalam lini produk kami, dan proses kami.

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.