Bagaimana cara menghabiskan lebih sedikit waktu untuk debugging? [Tutup]


15

Mengikuti aturan Pareto, seorang programmer menghabiskan hanya 20% dari waktunya untuk hal-hal yang sangat berguna.

Saya menghabiskan 80% dari waktu saya debugging, memperbaiki hal-hal kecil untuk membuat semuanya berfungsi.

Apakah ada cara untuk mengurangi waktu debugging?


9
Saya tidak yakin bagaimana saya akan menafsirkan prinsip Pareto.
c_maker

6
<meme> Lihatlah TDD. </meme>
StuperUser

1
Apa yang sebenarnya Anda lakukan saat debugging?

3
Anda perlu meluangkan lebih banyak waktu untuk memperhatikan detail

1
Ada banyak yang bisa diperoleh dari hanya melihat kode Anda sekarang dan kemudian. Lebih baik lagi, tulis komentar saat Anda merasakan dorongan, jadi akan lebih mudah untuk melihat kesalahan di kemudian hari.
Joey Adams

Jawaban:


5

Kode dalam Agda atau Coq . Setelah kode Anda dikompilasi, itu akan berfungsi. Jika terlalu hardcore, pilih bahasa dengan sistem tipe yang lebih lemah, misalnya, Haskell atau F #.

Tapi tetap saja, dalam kebanyakan kasus Anda akan jauh lebih produktif menghabiskan 20% dari waktu Anda untuk pengkodean dan 80% untuk pengujian dan debugging. 100% seminggu jauh lebih dari 20% dalam satu jam. Jika debugging adalah apa yang Anda butuhkan untuk menyelesaikan sesuatu, daripada debugging bukanlah buang-buang waktu dan Anda tidak perlu repot dengan "meningkatkan" proporsi ini.


1
Hanya karena sesuatu berjalan tidak berarti tidak memiliki bug. Bug sering merupakan hasil dari kode yang melakukan hal yang salah.
HLGEM

3
@HLGEM, sebelum downvoting Anda harus membaca lebih lanjut tentang Agda dan Coq. Jika kode Anda dikompilasi, dijamin dan terbukti melakukan persis apa yang dikatakan spesifikasinya. Tentu saja ada bug dalam spesifikasi juga, tapi saya tidak akan menyebut memperbaiki masalah semacam ini sebagai "debugging".
SK-logic

2
@HLGEM, maka pengertian Anda tentang "debugging" cukup kreatif dan jauh dari arus utama. Lagi pula, dengan pendekatan ini proporsi antara pengkodean dan "debugging" akan jauh dari 20/80. Jadi tolong, tolong jelaskan downvote Anda.
SK-logic

1
@HLGEM, itu tidak ada dalam daftar persyaratan OP. Tidak ada yang diketahui tentang berapa banyak pengembang di sana, siapa yang bertanggung jawab, dll. Satu-satunya pertanyaan adalah "bagaimana mengukur rasio 20/80", dan menggunakan bahasa yang diverifikasi secara statis jelas merupakan jawaban yang paling jelas untuk itu. Tetapi, seperti yang sudah saya katakan, jawaban ini hanya berlaku dalam kasus yang sangat jarang, dan secara umum berpegang pada aturan 20/80 adalah pilihan yang jauh lebih baik.
SK-logic

1
@ uhbif19 Knuth dimaksudkan untuk menjadi lucu ketika mengatakan itu. Kamu tahu apa yang dia maksud?
Phil

44

Pengujian unit.

Setelah saya mulai menerapkan pengujian unit saya menemukan bahwa kode yang saya tulis menjadi lebih terstruktur. Saat itu lebih mudah untuk menghindari dan menemukan bug. Saya menghabiskan lebih sedikit waktu untuk debugging, tetapi lebih banyak waktu dengan menulis unit test.

Saya juga berpikir bahwa waktu yang diinvestasikan dalam unit test memiliki pengembalian investasi yang lebih baik daripada debugging. Setelah sesi debug saya baru saja memperbaiki kode. Bug yang sama dapat muncul beberapa minggu kemudian dan saya harus men-debug lagi. Jika saya menulis unit test bug didokumentasikan sebagai unit test dan kemudian bertindak sebagai uji regresi. Jika bug muncul lagi, unit test mengungkapkan ini kepada saya.


Saya menggunakan Tes Unit dan sepenuhnya setuju dengan Anda. Tapi, saya tidak bisa menguji semuanya.
uhbif19

5
Tentu kamu bisa. Yah tidak semuanya , tapi semua yang penting. Dengan menggunakan antarmuka, injeksi dependensi, pemalsuan dan mengejek kelas / metode Anda akan dapat menulis tes untuk hampir semua kode Anda.
Fredrik

8
@Fredrik, Anda tidak dapat dengan benar menguji unit bahkan a + bpotongan kode (kecuali tes Anda mencakup seluruh rentang tipe data aritmatika Anda).
SK-logic

"Setelah sesi debug saya baru saja memperbaiki kode." -- Betulkah? Saya pikir setelah sesi debug saya baru saja memperkenalkan lebih banyak bug - Saya tidak tahu di mana mereka.
B Seven

35
  • Pengujian unit, sehingga Anda tahu apakah kode Anda berfungsi di tempat pertama.
  • Setidaknya sejumlah desain dimuka, sehingga Anda tahu apa yang Anda koding.
  • Ulasan kode, karena dua kepala lebih baik dari satu, dan empat mata lebih baik dari dua. Belum lagi bahwa bahkan mencoba menjelaskan kode Anda kepada orang lain mengungkapkan banyak masalah.
  • Kontrol versi, sehingga Anda dapat dengan cepat mengisolasi perubahan mana yang mungkin menyebabkan bug.
  • Refactoring, sehingga kode Anda tidak berubah menjadi kekacauan yang tidak dapat dipahami.
  • Baca "Kode Bersih" oleh Robert C. Martin, dan lakukan apa yang dia katakan. Anda akan kagum dengan hasilnya.

5
Tepat - tidak ada praktik tunggal (misalnya pengujian unit) akan memberikan urutan peningkatan besar tetapi kombinasi praktik bisa. Dengan kata lain ... tidak ada peluru perak.
Michael

Saya akan menambahkan TDD (jika memungkinkan).
Tom

1
Saya sebenarnya akan mengurutkan kode bersih dan refactoring terlebih dahulu. Unit test baik untuk menemukan dan memperbaiki bug lebih awal, tetapi mereka tidak akan mengurangi jumlahnya (mereka akan mengurangi waktu sedikit, karena Anda akan memperbaiki bug ketika Anda memiliki semua yang baru dalam memori, tetapi masih). Menulis kode bersih di sisi lain mengurangi jumlah bug yang sebenarnya.
Jan Hudec

1
@JanHudec Refactoring + kode bersih + tes = TDD
Tom

1
@ Tom: Ya, tetapi bagian yang berbeda memiliki efek yang berbeda. Belajar menulis kode bersih akan membantu Anda mengurangi waktu debug tanpa tes apa pun. Tes ada di sana sehingga Anda dapat menguji modul sebelum penggunaannya diterapkan dan sehingga Anda dapat memverifikasi Anda tidak mengubah perilaku ketika Anda refactor — yang diperlukan untuk membersihkan kode berantakan yang lama.
Jan Hudec

8

Pengujian unit akan membantu semoga jika Anda memperkenalkan bug mereka akan rusak sebelum kode produksi Anda - tes unit yang ditulis dengan baik juga akan memberi tahu Anda apa yang rusak.

Itu akan membantu Anda, tetapi untuk 99,999% proyek Anda masih perlu melakukan debug dari waktu ke waktu. Hal terbaik yang dapat saya lakukan di sini adalah melakukan 4 hal:

  1. gunakan tipe yang tidak berubah sedapat mungkin - jika sesuatu memiliki nilai yang salah Anda akan tahu persis di mana harus mencari segera (di mana itu sedang dibangun).
  2. menegakkan invarian dalam kode - jika Anda tahu suatu nilai pasti tidak diizinkan maka periksa dan masukkan pengecualian di titik masuk ke metode dan konstruktor. Jika Anda menggabungkan ini dengan tipe yang tidak dapat diubah maka Anda juga dapat mulai membuat asumsi tertentu tentang apa yang valid atau tidak.
  3. pastikan Anda memiliki pencatatan yang memadai - dapatkan ini lebih awal dan ini akan memberi Anda banyak informasi penting tentang ketika ada masalah. AOP bekerja dengan sangat baik di sini. Logging sebagai renungan biasanya sedikit sampah - dapatkan lebih awal sebagai bagian dari pengaturan proyek.
  4. jika basis kode Anda cukup besar / kompleks, hindari menggunakan primitif - mis. memiliki tipe yang disebut 'Usia' daripada hanya menggunakan int. Pada awalnya itu akan tampak tidak ada gunanya, tetapi mampu melacak semua penggunaan sesuatu dalam sekejap adalah kemenangan debugging yang sangat besar.

6

80% saya adalah debug. Saya memperbaiki bug sederhana dan mencoba membuat semuanya berfungsi.

Mulailah dengan menulis tes unit, dan cobalah untuk memiliki cakupan setinggi mungkin. Seseorang menyebutkan TDD, tapi saya akan pergi dengan BDD .

Pada akhirnya, Anda kemungkinan besar akan menghabiskan 80% untuk debug bug kompleks.


6

Bagaimana cara mengurangi waktu debugging? Tulis lebih sedikit kode.

Serius, selama Anda menulis kode, Anda harus melakukan debug. Tes unit dll sangat membantu, tetapi jangan berpikir Anda akan pernah menghilangkan kebutuhan untuk itu sama sekali.


4

Pahami apa dan mengapa sebelum Anda mulai menulis kode. Kemudian gunakan metodologi secara konsisten. Metodologi mana yang Anda pilih tidak sepenting penggunaan berulang metodologi secara konsisten. Jika Anda ingin hasil yang konsisten baik, Anda perlu melakukan pekerjaan yang baik secara konsisten dan memiliki "metode untuk kegilaan Anda" adalah langkah pertama untuk mendapatkan hasil ini. Saat Anda mengidentifikasi masalah, Anda dapat menyesuaikan metodologi sesuai kebutuhan dan seiring waktu Anda akan meningkatkan proses pengembangan, dan semoga lebih sedikit bug dan lebih banyak perkembangan baru yang bermakna.


3

Berikan kode Anda bacaan yang cermat sebelum Anda bahkan mengompilasinya. Bacaan yang sangat hati-hati untuk sintaks dan fungsionalitas. Ini bisa sangat informatif, dan juga merupakan indikator yang baik jika bagian kode terlalu rumit.


Saya sangat setuju. Membaca kode Anda segera setelah Anda menulisnya dapat dengan cepat mengungkapkan beberapa bug yang jelas, seperti kesalahan salin dan tempel (yang terkadang sulit ditemukan setelahnya).
jirkamat

3

Sebagian besar jawaban tampaknya terfokus pada cara mengurangi jumlah masalah yang harus Anda debug dan itu sangat berharga. Namun, debugging akan selalu diperlukan sehingga berguna untuk mencari cara mempercepat debugging.

  • Ketahui cara menggunakan perangkat lunak kontrol versi Anda.

    • Menggunakan cabang akan membantu Anda memisahkan area pengembangan dan Anda akan dapat melihat area pengembangan mana yang memiliki bug dan mana yang tidak.
    • Pelajari cara menggunakan pembagian dua di VCS Anda, Git memiliki built in ini. Jika Anda menggunakan VCS berbeda yang tidak memiliki pembagian dua dibangun untuk mencari alat yang bekerja seperti git bisect tetapi untuk VCS Anda (saya tahu ini ada untuk SVN dan seharusnya tidak terlalu sulit untuk dibuat untuk VCS lainnya). Ini akan membantu Anda mempersempit perubahan kode yang memperkenalkan bug, yang akan membantu mengetahui ke mana harus mengarahkan debugger Anda. Proses membagi dua ini akan lebih cepat jika Anda memiliki tes untuk bug dan mengetahui komit mana yang berisi perubahan menyinggung akan lebih berguna jika Anda mempraktikkan komitmen atom.
  • Tingkatkan pemahaman Anda tentang bahasa pemrograman yang Anda gunakan.

    • Baca buku, blog, dan kode tentang bahasa pemrograman.
    • Setiap kali Anda memperbaiki bug pastikan Anda benar-benar memahami mengapa kode tidak bekerja dan mengapa perbaikan Anda berhasil. Seiring waktu Anda akan belajar banyak gotcha dalam bahasa Anda yang akan membantu Anda menghindari masalah mereka dan menemukan gejala-gejala mereka jika mereka muncul kembali.
  • Bersikaplah logis

    • Jangan mengubah lebih dari satu hal sekaligus jika perilaku berubah Anda tidak akan tahu perubahan mana yang menyebabkan perubahan perilaku.
    • Verifikasi asumsi Anda.

2

Menambahkan ke komentar untuk Unit Testing tetapi hanya sangat bagus jika kode Anda telah dipisahkan untuk mendukungnya (mis. MVC). Jika Anda tidak dapat mengimplementasikan MVC (atau yang serupa) (proyek lawas), pengujian unit tidak berfungsi sama sekali untuk UI Anda. Saya kemudian akan menambahkan pengujian UI otomatis (Microsoft Coded UI Tests, WaitN) karena ini akan mengurangi kesalahan pada bagian kode Anda.

Saya juga sangat merekomendasikan menjalankan alat analisis statis (mis. FxCop / Analisis Kode Microsoft, Resharper, JustCode untuk dunia MS). Ini dapat menemukan semua jenis masalah pengkodean umum yang dapat mengurangi tugas debugging konyol dan lebih fokus pada debugging logika bisnis.


2

Buat itu bekerja, lalu buatlah cepat, kemudian buatlah itu cantik. Sebagian besar bug berasal dari optimasi awal atau re-factoring pada baris kode yang benar-benar baik. Jika Anda pergi dengan orientasi objek jangan ulangi diri Anda sendiri, tetap sederhana dan selalu melakukan pemeriksaan kewajaran rentang nilai terutama jika metode Anda masih akan bekerja pada kendala. Ini tidak akan membantu Anda membuat lebih sedikit kesalahan tetapi kemungkinan akan membantu Anda menemukan bug lebih cepat dan karenanya debug membutuhkan waktu lebih sedikit.


1
Pernyataan "Sebagian besar bug berasal dari ..." Anda kedengarannya bagus, tetapi apakah Anda memiliki bukti untuk mendukungnya? Saya pikir itu akan terdengar sama meyakinkannya jika saya mengatakan "sebagian besar bug berasal dari persyaratan yang tidak ditentukan atau kurangnya desain yang jelas." Anda harus menambahkan tautan atau kutipan ke penelitian yang mendukung pernyataan Anda.
Caleb

2

Saya telah diberi banyak pemikiran untuk masalah ini baru-baru ini - jawabannya yang sederhana adalah baca Don Donan's The Design of Everyday Things; Tulis kode seperti Anda akan merancang suatu produk.

Untuk parafrase, desain yang baik meminimalkan kesalahan. Itu berarti, beberapa hal, sebagian besar sudah Anda lakukan (walaupun Anda mungkin tidak tahu persis mengapa ).

Fungsi -Nama secara intuitif. Ini secara resmi dikenal sebagai keterjangkauan. Artinya, sebuah tombol memungkinkan untuk ditekan, tuas memungkinkan untuk diaktifkan, pegangan untuk ditarik, dll.

-Membuat sulit untuk menulis kode yang buruk. Periksa input buruk dan lontarkan kesalahan lebih cepat daripada nanti, gunakan aplikasi hungarian bila perlu, dll. Ini disebut fungsi lockout.

-Gunakan abstraksi jika perlu. Memori jangka pendek lemah.

-Dokumentasi jelas penting, tetapi ini adalah yang paling tidak efektif untuk memastikan kode digunakan dengan benar. Singkatnya, produk yang dirancang dengan baik tidak memerlukan dokumentasi apa pun. (Cara paling jelas untuk melihat ini adalah dengan melihat contoh-contoh buruk: yaitu, pintu dengan pegangan yang seharusnya Anda dorong.)

Tes -Unit. Ini tidak benar-benar mencegah kesalahan, seperti memperjelas di mana bug berada, dan memberikan kewarasan.

Saya yakin saya kehilangan banyak prinsip lagi, tetapi intinya adalah, bacalah tentang merancang kesalahan.


1

Cara terbaik untuk mengurangi debugging, IMO, adalah dengan berkonsentrasi dan memperlambat ketika coding. Ini memaksa Anda untuk melihat kesalahan yang mungkin Anda lakukan!


1

Sementara saya benar-benar mendukung pengujian unit yang disarankan di atas, TDD atau BDD akan sangat berguna karena Anda harus terlebih dahulu memikirkan masalah dan solusinya.

Tetapi secara pribadi bagi saya, mengambil beberapa menit hanya untuk duduk dengan tenang dan memikirkan masalah dan bagaimana cara mengatasinya dan pro dan kontra dengan setiap pendekatan, melakukan keajaiban untuk kualitas kode saya dan membantu menjernihkan pikiran saya dari kekacauan.

Terkadang coretan cepat pada selembar kertas membantu Anda melihat potongan-potongan teka-teki yang lebih besar.

Saya menulis kode terburuk ketika saya menyelam lebih dulu dan memukul keyboard. Sedikit pemikiran dan kontemplasi membuat dunia berbeda.

PS. Maksud saya 5 mungkin sepuluh menit, bukan jam menulis spec besar.


1

Beberapa jawaban yang baik sudah, hanya beberapa makanan untuk meskipun selain apa yang dikatakan orang lain.

Belajar dari kesalahanmu. Jangan terus membuat yang sama berulang-ulang.

Pastikan untuk menutup kasus tepi saat pemrograman - itu adalah tempat di mana sering ada bug.

Perhatikan persyaratannya. Bahkan jika itu berfungsi tetapi tidak melakukan apa yang ditentukan oleh persyaratan, itu adalah bug.

Log pengecualian bisa sangat membantu ketika ada masalah enam bulan dari sekarang. Biasakan merekam pengecualian.


0

Dua pemikiran utama saya adalah 1) Menulis kode yang lebih baik yang akan gagal ketika Anda melakukan sesuatu yang tidak terduga 2) Menjadi lebih baik dalam debugging

Kode saya dikotori

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

Setiap kali saya mengeksekusi potongan kode tersebut pengecualian dilemparkan yang menyebabkan debugger berhenti yang memungkinkan saya kode dalam fitur-fitur baru atau menghindari persyaratan daripada bingung tentang apa yang terjadi / memiliki bug

Untuk menjadi lebih baik dalam debugging main-main dengan tumpukan panggilan, breakpoints (dengan kondisi), jendela langsung (juga dikenal sebagai jendela prompt atau repl), variabel 'menonton' dan apa pun.

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.