Seberapa sering Anda menjalankan & menguji kode Anda saat pemrograman? [Tutup]


16

Terutama ketika menulis kode baru dari awal dalam C, saya menemukan diri saya menulis kode selama berjam-jam, bahkan berhari-hari tanpa menjalankan kompiler untuk apa pun kecuali pemeriksaan sintaksis sesekali.

Saya cenderung menulis potongan kode yang lebih besar dengan hati-hati dan menguji secara menyeluruh hanya ketika saya yakin bahwa kode melakukan apa yang seharusnya dilakukan dengan menganalisis aliran di kepala saya. Jangan salah paham - saya tidak akan menulis 1000 baris tanpa pengujian sama sekali (itu akan menjadi judi), tapi saya akan menulis seluruh subrutin dan mengujinya (dan memperbaikinya jika perlu) setelah saya pikir saya sudah selesai.

Di sisi lain, saya telah melihat sebagian besar pemula yang menjalankan & menguji kode mereka setelah setiap baris yang mereka masukkan dalam editor dan berpikir bahwa para penipu bisa menjadi pengganti untuk kehati-hatian dan kewarasan. Saya menganggap ini banyak gangguan setelah Anda mempelajari sintaks bahasa.

Menurut Anda apa keseimbangan yang tepat antara kedua pendekatan tersebut? Tentu saja yang pertama membutuhkan lebih banyak pengalaman, tetapi apakah itu memengaruhi produktivitas secara positif atau negatif? Apakah yang kedua membantu Anda menemukan kesalahan pada tingkat yang lebih baik?


3
Anda perlu berjam-jam atau berhari-hari untuk menulis seluruh subrutin?

1
@ Torbjorn Subrutin sekitar 999 panjang, dan itu dikaburkan: #define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r+z))); goto xkcd)Dan itu hanya satu baris.
Mateen Ulhaq

1
kompiler kadang-kadang bisa memakan waktu lama untuk mengkompilasi program whoch karena itu bukan praktik yang baik untuk mengkompilasi sepanjang waktu. setelah setiap fungsi adalah praktik yang baik. saya mengkompilasi ulang setelah menambahkan fungsionalitas baru atau beberapa bagian kode yang sulit. Saya hanya menggunakannya sebagai pemeriksa sintaksis. tidak ada pengganti untuk memeriksa kode Anda dengan hati-hati dan menghindari kesalahan tersembunyi dan perilaku sembrono.
Ross

Jawaban:


6

Ini BENAR-BENAR tergantung pada aspek proyek yang sedang Anda kerjakan.

  • Ketika saya melakukan sesuatu dengan OpenGL (yang bekerja seperti mesin negara), saya terus-menerus mengkompilasi dan menjalankan untuk memastikan bahwa saya tidak sengaja mengacaukan apa pun. Menyetel satu nilai tanpa mengingat untuk meresetnya di akhir suatu fungsi dapat dengan mudah membuat aplikasi hanya membuat layar hitam.

  • Untuk pengembangan "bawah kap" skala yang lebih besar, saya mencoba untuk mendapatkan sebanyak mungkin tes sebelumnya. Karena tes dapat dengan lebih mudah memberi tahu saya apa yang rusak, saya bisa pergi sebentar tanpa harus menunggu kompilasi yang biasanya panjang.

  • Untuk desain UX, saya menggunakan semacam perancang visual, yang selalu terlihat seperti itu akan berjalan (atau dekat dengan itu). Ini pada dasarnya selalu mengkompilasi kode desain.


63

Secara pribadi, saya harus bekerja dalam potongan-potongan kecil karena saya tidak cukup pintar untuk menjaga jam bernilai coding dalam cache L1 biologis saya. Karena kemampuan saya yang terbatas, saya menulis metode yang kecil dan kohesif dan mendesain objek agar koplingnya sangat longgar. Alat dan bahasa yang lebih kuat membuatnya lebih mudah untuk kode lebih lama tanpa membangun, tetapi masih ada batas bagi saya.

Preferensi saya adalah menulis sepotong kecil, memverifikasi bahwa itu berfungsi seperti yang saya harapkan. Kemudian, secara teori, saya bebas untuk melupakan detail potongan itu dan memperlakukannya sebagai kotak hitam sebanyak mungkin.


12
Suara positif untuk "... tidak cukup pintar .." Saya sudah merasa seperti itu selama beberapa waktu.
leed25d

4
Bagaimana dengan cache L2 Anda?
Mateen Ulhaq

Saya akan mengungguli ini, tetapi skornya adalah 42 ...
Wayne Werner

Model yang lebih baru memiliki cache L1 yang jauh lebih besar. Kapan kamu membeli milikmu? Anda mungkin ingin melakukan pembaruan perangkat keras.
Peter Ajtai

Yah itu bukan usia model begitu banyak fakta bahwa itu adalah garis "anggaran". :(
dss539

17

Saya suka menulis tes saya sebelum saya menulis kode implementasi saya. Saya suka ini karena tiga alasan:

  1. Menulis kode pengujian saya sebelum tangan membantu saya memikirkan bagaimana kode saya harus digunakan. Ini membantu saya memikirkan kasus tepi yang saya tidak pikirkan ketika saya awalnya merancang program saya.
  2. Saya tahu saya selesai menulis kode implementasi ketika semua kasus uji saya lulus.
  3. Membiasakan diri menulis tes sebelum kode juga memiliki efek tambahan untuk dapat membuktikan bahwa kode Anda belum menambahkan bug baru (dengan asumsi Anda telah menulis kasus uji yang baik).

2
"Saya tahu saya sudah selesai menulis kode implementasi ketika semua test case saya lulus." - Bagaimana Anda menentukan apakah Anda menulis semua kasus uji yang diperlukan?
dss539

1
Itu pertanyaan yang bagus. Menurut pendapat saya, Anda tidak pernah dapat sepenuhnya yakin bahwa kode Anda berfungsi dengan benar kecuali jika Anda memiliki bukti formal yang menyatakan demikian. Saya melihat tes unit sebagai bukti bahwa kode Anda cenderung melakukan apa yang Anda maksud. Tetapi, saat fitur yang Anda tambahkan bertambah, jumlah test case yang Anda tulis mungkin akan bertambah juga. Jika ragu, minta orang lain untuk melihat kasus uji Anda dan minta mereka untuk kasus yang belum Anda pikirkan.
David Weiser

4
@ David - bagaimana Anda membuktikan secara formal bahwa bukti formal Anda tidak memiliki kesalahan? Bagaimana Anda membuktikan secara formal bahwa persyaratan yang dipersepsikan oleh Anda cocok dengan persyaratan dalam kenyataan. Anda dapat secara formal membuktikan bahwa satu deskripsi cocok dengan yang lain, tetapi sangat mungkin kedua deskripsi tersebut salah dengan cara yang sama - terutama jika kedua deskripsi tersebut ditulis oleh orang yang sama. Menulis hal-hal dalam notasi matematika tidak membuat orang sempurna. Sejumlah besar "bukti" matematis telah terbukti (setelah periode pemeriksaan yang sangat terperinci) salah.
Steve314

1
@ Steve314: AFAIK, ketika secara formal membuktikan kebenaran suatu algoritma, Anda menentukan secara tepat dan ringkas apa yang diharapkan kebenarannya. Anda memunculkan poin yang baik, bahwa definisi "benar" mungkin sebenarnya tidak benar.
David Weiser

1
@ dss539, yang berasal dari use case yang ingin diimplementasikan oleh program.

4

Saya menemukan diri saya menulis kode selama berjam-jam, bahkan berhari-hari tanpa menjalankan kompiler untuk apa pun kecuali pemeriksaan sintaksis sesekali.

Jam ke hari - itu pertanda jelas bahwa Anda kehilangan kemampuan untuk memecah kode menjadi potongan-potongan kecil yang dapat diverifikasi dan diuji sendiri. Anda pasti harus mengerjakannya.

Saya cenderung menulis potongan kode yang lebih besar dengan hati-hati dan menguji secara menyeluruh hanya ketika saya yakin bahwa kode melakukan apa yang seharusnya dilakukan dengan menganalisis aliran di kepala saya.

Alih-alih menulis potongan kode yang lebih besar - dan karenanya rumit - yang membutuhkan jam untuk dianalisis di kepala Anda, Anda harus mencoba membuat blok bangunan yang lebih kecil, tidak terlalu besar. Ini disebut membangun abstraksi - dan itulah inti dari pemrograman yang baik, jelas bukan pertanda menjadi pemula.

Pemrograman yang baik seperti bermain Billard yang sangat baik - pemain yang bagus tidak memainkan pukulan keras. Sebaliknya, ia bermain dengan cara di mana setelah setiap pukulan bola berhenti di posisi di mana pukulan berikutnya mudah lagi. Dan seorang programmer tidak baik karena dia dapat menulis kode yang rumit - dia baik karena dia dapat menghindari penulisan kode yang rumit.


3

Saya mengkompilasi & menguji jika salah satu dari kondisi berikut dipenuhi:

  • Kompilasi terakhir adalah 15 menit yang lalu
  • Kompilasi terakhir adalah 25 baris yang lalu
  • Fungsi / subrutin baru telah diterapkan
  • Perubahan besar
  • Fitur baru (atau bug yang disamarkan sebagai fitur)
  • Perbaikan bug (menghapus "fitur")
  • Saya bosan

1

Seberapa sering saya menjalankan dan menguji kode tergantung pada bahasa apa yang saya gunakan saat itu. Jika saya mengkode prosedur tersimpan, saya biasanya akan menunggu sampai semuanya ada di sana.

Di sisi lain, jika saya mengkode dalam Lisp, saya akan mencoba setiap fungsi setelah saya mengetiknya.

Jika saya mengkode di Haskell, saya biasanya akan melakukan kompilasi setelah setiap fungsi untuk menangkap kesalahan tipe apa pun, dan menjalankan kode setelah semuanya selesai.


1

Saya menulis kode yang cukup untuk mendapatkan tes hijau. Itu berarti saya menjalankan tes setiap beberapa menit. Itu gaya C ++ saya. Namun di Ruby saya menggunakan autotest, jadi setiap kali saya menekan save, saya mendapatkan umpan balik tes melalui popup yang bagus. Saya bahkan tidak berhenti menulis kode, itu hanya terjadi di latar belakang.


1

Tiga kali satu jam, apakah itu perlu atau tidak.

Kami melakukan pemrograman pengujian pertama dan hanya mengkomit kode kerja ke VCS. Smolderbot pergi dan memeriksa repo setiap 20 menit dan menjalankan test suite. Setiap kegagalan segera dikirim ke seluruh tim pemrograman untuk segera diperbaiki.


1

Bagi saya ini bukan tentang seberapa banyak saya menulis. Saya dapat menulis ribuan baris kode sederhana tanpa harus mengujinya. Tetapi ketika saya menulis kode yang lebih sulit saya cenderung menguji setiap fungsi secara individual setelah menulis satu set yang kohesif.

Namun kadang-kadang, melihat kode Anda berjalan adalah dorongan motivasi yang sangat besar, ketika Anda belum menjalankan apa-apa dalam beberapa saat, ada baiknya melihatnya berfungsi.


0

Bagi saya; -
Garis waktu pendek (tidak banyak waktu untuk berpikir) - menulis kode, kompilasi, tes. debug
Waktu yang cukup - selagi (selesai) {tulis kode kecil, kompilasi}, tes, debug


Saya menemukan bahwa yang pertama membutuhkan waktu lebih lama dari yang terakhir: Anda memiliki lebih banyak untuk debug itu jika Anda memiliki loop tes / tulis yang sangat kecil.
Frank Shearar

Mungkin. Tapi timeline pendek berarti keledai terbakar, dan manajer perlu laporan yang mengatakan beberapa tugas sudah 100% selesai.
Manoj R

0

Saya menguji untuk setiap konsep pengkodean. Terkadang ini adalah fungsi atau kelas dan terkadang itu tidak lebih dari pernyataan if. Setelah konsep bekerja, lanjutkan ke yang berikutnya.


0

Saya mencoba dan menulis tes sebelum kode. Saya menjalankan tes saya setidaknya dua kali sebelum komit. Kemudian berjalan lagi dengan server Integrasi Berkelanjutan.

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.