Bagaimana Anda memprogram secara efektif ketika dibutuhkan waktu lama untuk hanya menguji kode Anda?

16

Alur kerja saya selalu menulis satu langkah logis dan kemudian menjalankan program dan memeriksa hasilnya. Proses ini telah membantu saya dengan sangat baik untuk tugas-tugas di universitas. Namun, ketika saya melakukan lebih banyak pengembangan, sering kali hanya dengan mengkompilasi dan menjalankan kode Anda membutuhkan 1 hingga 2 menit. Contohnya termasuk mengunggah program ke mikrokontroler, memerlukan interaksi dengan server eksternal, dan tidak dapat mengimplementasikan otomatisasi karena otentikasi, arsitektur perangkat lunak, atau kompleksitas.

Jenis tugas ini sangat tidak sesuai dengan cara saya biasanya memprogram, dan saya mengalami kesulitan pengkodean secara efektif. Saya biasanya membuat banyak kesalahan sintaksis dan kesalahan logika, yang sebagian besar mudah saya tangkap dengan pengujian. Namun, dengan waktu tunggu yang lama, metode ini terlalu memakan waktu.

efficiency time

— Anne Nonimus
sumber

Apakah Anda menggunakan IDE?

— Woot4Moo

3

Masalah root Anda tidak dapat dikodekan secara efektif, ini ujian yang terlalu lama untuk dijalankan. Anda mengajukan pertanyaan yang salah.

— Rein Henrichs

Gunakan bahasa yang memiliki REPL.

— Robert Harvey

Apakah Anda memiliki rekan kerja yang dapat Anda tanyakan dan pelajari?

— user985366

25

Pertama, semua jenis debugging interaktif sangat bagus. Anda menginginkan itu di toolkit Anda, karena jika belum, maka suatu hari Anda akan sangat diuntungkan dengan memilikinya. (Detail bervariasi menurut bahasa, platform, dan IDE.)

memerlukan interaksi dengan server eksternal, dan tidak dapat mengimplementasikan otomatisasi karena otentikasi, arsitektur perangkat lunak, atau kompleksitas.

Saya akan melihat beberapa kerangka kerja untuk digunakan benda tiruan . Ini memungkinkan Anda untuk mengelilingi komponen yang sedang diuji dengan ekosistem palsu dari komponen lain, sehingga pengujian Anda lebih spesifik dan Anda dapat menghindari pengujian semuanya secara keseluruhan.

Selain itu, objek tiruan itu sendiri dapat diprogram dengan pernyataan, sehingga Anda dapat memeriksa apakah komponen yang diuji benar-benar melakukan panggilan tertentu.

— Darien
sumber

12

Saya akan bekerja keras untuk mengurangi waktu ujian. Saya telah bekerja di beberapa perusahaan yang mengembangkan kode tertanam, dan pengujiannya menyakitkan, membutuhkan perjalanan ke ruang server dan FTP manual dan reboot dan beberapa perintah ke perangkat keras uji. Kemudian saya bergabung dengan grup yang sangat bagus, di mana saya cukup mengetik 'tes' di meja saya dan mendapatkan hasil kembali dalam waktu kurang dari satu menit. Dalam satu menit itu:

Kode saya dibangun menjadi image kernel baru untuk perangkat keras tertanam.
Server DHCP telah diperbarui untuk menunjuk ke kernel baru.
Papan tes telah dinyalakan kembali.
Papan tes mengambil kernel dari workstation saya melalui mount NFS.
Papan tes reboot ke kernel baru.
Tes unit dijalankan.
Output tes unit dikirim kembali ke workstation saya.

Butuh beberapa waktu untuk menyelesaikan semua ini, tetapi upaya untuk mengotomatiskan semua langkah ini dikembalikan seratus kali lipat ketika staf pengembangan tumbuh.

— kevin cline
sumber

2

+1. Tidak ada masalah yang tidak dapat diselesaikan dengan jumlah skrip shell yang cukup.

— Tom Anderson

1

Saya tidak akan tinggal di tim yang tidak peduli meningkatkan kecepatan.

— kevin cline

@ Tom Kecuali terlalu banyak lapisan abst - er, skrip shell;)

— Darien

Nah, Anda cukup menulis skrip shell yang membungkus skrip shell lainnya. Lalu hanya ada satu skrip shell. PERCAYALAH KEPADAKU.

— Tom Anderson

3

+1: Meningkatkan kecepatan edit -> kompilasi -> muat -> jalankan -> debug -> edit adalah satu-satunya hal terbaik yang dapat Anda lakukan untuk mempercepat produksi kode. Ketika saya bekerja di Tymshare, kami memiliki seorang pria yang mengklaim (dengan benar) bahwa kode-nya berjalan dengan benar pada percobaan pertama 87% dari waktu. Saya, di sisi lain, berkode seperti saya overdosis pada monyet kafein pada 1 pagi (yang saya). Saya membuat banyak kesalahan ketik, dll., Tetapi saya tidak mengkhawatirkannya karena saya tahu kompiler akan menangkapnya. Pada akhirnya saya mungkin 3 hingga 5 kali lebih produktif daripada dia.

— Peter Rowell

8

Tes otomatis bukan pengganti untuk ditinjau dan dipahami.

Mungkin Anda menggunakan pengujian sebagai penopang. Jika Anda melakukan ini, Anda akan menghambat pembelajaran Anda. Saya tidak menganjurkan Anda tidak menguji. Sebagai gantinya saya akan merekomendasikan Anda bahwa sebelum Anda menjalankan tes Anda memeriksa apa yang Anda tulis. Pahami apa yang Anda tulis, pastikan itu masuk akal dan pastikan sintaksnya terlihat benar.

— dietbuddha
sumber

5

Anda sudah memberikan jawabannya: I usually make a lot of syntax errors and logic errors

Jadi, bekerja keras untuk meningkatkan itu, Anda harus dapat mengurangi waktu pengujian. Kesalahan sintaksis harus menjadi yang pertama yang harus Anda kurangi. Tidak pernah menjalani tes pemrograman dengan kertas dan pensil di ruang belajar Anda?

Saya memiliki hal yang sama ketika saya beralih dari PHP ke Java. Saya harus belajar debug bukan hanya mencetak beberapa variabel dan menekan F5 di browser ...

— Warren Faith
sumber

2

Kita semua membuat kesalahan bodoh dari waktu ke waktu, itu hanya terjadi lebih sedikit dengan waktu dan pengalaman.

— maple_shaft

@maple_shaft itu benar, tetapi ketika dia mengatakan make a lot ofsepertinya dia harus menginvestasikan energinya untuk memperbaikinya

— WarrenFaith

3

Saya melakukan cukup banyak pengkodean di atas kertas dan di papan tulis. Masalahnya sama: kodenya terlihat benar pada inspeksi pertama, tetapi setelah menjalankannya, Anda melihat kesalahan Anda.

— Anne Nonimus

mencatat kesalahan dalam kode dan menulis kode dengan sintaks yang salah adalah perbedaan besar. Yang pertama dapat terjadi pada semua orang, yang kedua menyarankan tingkat pemula. Saya tidak tahu latar belakang Anda, tetapi bahkan sebagai pemula Anda harus meminimalkan masalah sintaksis. Apa IDE dan bahasa Anda? Seharusnya mendukung pemeriksaan sintaks.

— WarrenFaith

@Anne Nonimus: Maksud Anda kesalahan logis? Kesalahan sintaksis harus diambil oleh IDE Anda (idealnya - jika Anda bekerja dengan kode yang dihasilkan secara dinamis maka kesalahan sintaksis tidak akan diambil pada waktu kompilasi).

— FrustratedWithFormsDesigner

4

Anda memerlukan platform tes Unit atau Fungsional yang baik yang dapat secara otomatis menjalankan tes untuk Anda, terutama di latar belakang. Ini akan membutuhkan penggunaan Mock seperti disebutkan di atas dan tergantung pada bahasa yang Anda gunakan semacam suntikan ketergantungan.

Dengan membuat objek Anda sebebas mungkin dan kemudian menggunakan metode injeksi untuk menambahkan kendala luar tidak sulit untuk membuat platform uji untuk kode Anda.

— Bill Leeper
sumber

2

Kegembiraan yang sebenarnya datang ketika Anda tidak bisa menguji kode Anda kecuali dengan menggunakannya dalam kemarahan. Ini terjadi cukup banyak pada sistem perdagangan, karena simulator pertukaran yang tersedia seringkali buruk, tidak ada, atau bahkan tidak mematuhi apa yang dikatakan pemasok perangkat lunak pertukaran itu. Ini adalah bagian dari permadani yang kaya dalam hidup. Pendekatan saya adalah memastikan setidaknya sisi transaksi saya ditulis dengan baik dan terdokumentasi dengan baik, sehingga dapat dengan mudah diubah dengan cepat.

— Neil Butterworth
sumber

3

Anda "bertukar" dan "memperdagangkan" insinyur perangkat lunak adalah jenis yang unik. Teman saya mengalami serangkaian gangguan mental yang bekerja untuk satu perusahaan semacam itu. Saya tidak pernah mendengar hal-hal baik keluar dari ceruk industri perangkat lunak itu.

— maple_shaft

@maple Yah, saya sendiri tidak melakukannya lagi. Tapi unik? Nah - siapa pun dapat menulis kode jelek, dan sebagian besar kode perdagangan sangat, sangat jelek. Namun, suka atau tidak suka, adalah dasar bagi masyarakat kita.

— Neil Butterworth

Ya, saya mendengar hal yang sama tentang kode telekomunikasi dan berapa juta baris dalam perangkat lunak kontrol saklar. Kemudian saya bergabung dengan perusahaan Telecom dan menyadari bahwa jika mereka mempekerjakan beberapa programmer, ribuan saluran sudah cukup.

— kevin cline

2

Pengujian Unit; Aplikasi tiruan / simulator.

Ini akan memakan waktu, diberikan, dan Anda mungkin perlu mengumpulkan dan memijat data sampel untuk membuat mock-up yang sesuai, tetapi pada akhirnya akan membuahkan hasil: Anda akan menghemat waktu dan masalah yang Anda temui saat mencoba menguji terhadap eksternal sistem.

Digunakan dengan benar, alat-alat ini akan memastikan bahwa sebelum Anda mendekati sistem eksternal, Anda 99,9% yakin bahwa jika kode Anda gagal, itu adalah sesuatu dalam sistem eksternal / perubahan lingkungan yang menyebabkannya, bukan bug dalam kode Anda sendiri.

Saya bekerja secara profesional selama beberapa waktu seperti yang Anda lakukan di sekolah, dan dalam banyak kasus itu sangat efektif. Akhirnya saya bekerja di bawah beberapa orang yang memaksa saya untuk meninggalkan metodologi itu dan menggunakan pengujian unit dan mock-up sebagai gantinya.

Sekarang, saya tidak memulai proyek apa pun tanpa memikirkan terlebih dahulu pelaksanaan fase pengujian - pengujian unit, mock-up, simulator, data sampel, dll.

— Vektor
sumber

1

Saya biasanya membuat banyak kesalahan sintaks dan kesalahan logika

Mungkin menggunakan Linter dapat sedikit membantu Anda di sini.

Saya berada dalam situasi yang sama dengan majikan saya sebelumnya. Basis kode kami sangat besar dan untuk membuat perubahan apa pun yang saya harus kode, kompilasi kemudian ganti .classfile di server-dev kemudian restart dev-sever dengan skrip restart. Dan yang membuatku cemas, butuh sekitar setengah jam untuk mengaktifkan dev-server lagi.

Kemudian saya mengetahui bahwa Remote debugging dev-server juga memungkinkan.

Jadi, inilah yang saya lakukan untuk mengoptimalkan proses saya

Putaran awal pertama dari debugging jarak jauh, ini memungkinkan saya melihat aliran kode yang tepat dan nilai / status variabel yang tepat.
Merencanakan bagaimana dan perubahan apa yang akan saya buat.
Membuat Perubahan dan kemudian membandingkan perbedaan
Caching kesalahan dengan menggunakan linter atau dengan kompilasi.
Memberikan perbaikan terbaru dengan mengganti .classfile dan memulai kembali.

Kadang-kadang saya juga akan memasukkan banyak sekali pernyataan log untuk memeriksa kembali aliran kode dan memeriksa memeriksa nilai / status. Ini memang banyak membantu saya.

Juga menggunakan IDE dengan komplikasi otomatis yang baik dapat sangat membantu dalam mengurangi kesalahan ketik.

Semoga ini membantu.

— Alaf Azam
sumber