Menjadi Pemecah Bug yang Lebih Baik

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?

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.

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 .

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 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.

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." :)

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!

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.

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?

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.

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.

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.

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 .

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.