Apakah ada manfaat dalam mengkompilasi kode Anda saat Anda melanjutkan?


183

Baru-baru ini saya melakukan wawancara kerja di mana mereka memberi saya waktu satu jam untuk menulis beberapa kode nyata. Itu bukan jumlah yang besar, mungkin kurang dari 100 baris. Setelah sekitar 45 menit, saya menyusun, menjalankannya, dan mulai bekerja. Saya mungkin telah menghabiskan 5-10 menit mengerjakan kesalahan kompilasi dan beberapa bug kecil, tetapi secara keseluruhan sangat lancar. (Kebetulan, aku memang mendapat tawaran dari mereka.)

Namun, yang membingungkan saya adalah bahwa setelah saya menyerahkan kode yang lengkap, pewawancara mengatakan kepada saya bahwa satu-satunya hal yang saya lakukan salah adalah "tidak mengkompilasi saat saya melanjutkan". Saya bertanya kepadanya apa bedanya, dan dia berkata, "apa yang akan Anda lakukan jika Anda menyelesaikan kode dan tidak dapat dikompilasi tepat waktu".

Dalam pemahaman saya itu argumen yang tidak valid, karena "mendapatkan kode untuk dikompilasi" untuk panjang kode tertentu umumnya melibatkan memperbaiki jumlah kesalahan kompilasi yang konstan dan membutuhkan waktu yang cukup konstan, yang harus sama apakah Anda melakukannya setelah Anda selesai menulis kode, atau jika Anda interleave dengan waktu pengkodean Anda. Jika ada, menginterupsi kode Anda untuk mencari titik koma yang hilang mungkin akan merugikan efisiensi Anda. Kecuali dalam keadaan ekstrim ketika saya bereksperimen dengan ketidakjelasan di sekitar kasus tepi pada hal-hal seperti fungsi virtual di kelas turunan, dll. Tampaknya masuk akal untuk mengharapkan bahwa kode yang ditulis oleh pengembang yang berpengalaman akan dikompilasi, dikurangi kesalahan pengetikan sesekali, dan bahkan jika tidak, itu

Dalam kejadian serupa lainnya, saya diberi basis kode tidak lengkap dalam sebuah wawancara, dan diminta untuk menyelesaikannya dan membuat modifikasi yang diperlukan untuk membuatnya berjalan. Saya mulai dengan membaca kode yang ada, dan kemudian setelah beberapa menit (bahkan sebelum saya selesai melihat kode), pewawancara mengatakan itu sudah cukup. Ketika saya bertanya kepadanya apa yang akan dia lakukan (yaitu "apa yang saya lakukan salah"), dia mengatakan kepada saya bahwa dia akan mulai dengan segera mendapatkan kode untuk dikompilasi.

Mengapa itu bahkan relevan? Menurut pendapat saya dan pengalaman saya, apakah kompilasi kode atau tidak pada dasarnya acak, melibatkan hal-hal seperti apakah titik koma hilang atau tidak, dan tidak ada hubungannya dengan kebenaran dari program yang mendasarinya. (Bagi saya, fokus pada kompilasi adalah seperti menjalankan artikel melalui pemeriksa ejaan tanpa proofreading untuk memeriksa tata bahasa.)

Jika Anda memberi saya sepotong kode tidak lengkap, hal pertama yang saya lakukan adalah membacanya. Saya bahkan tidak akan mencoba untuk mengkompilasinya sampai saya tahu apa yang dilakukan kode dan saya tahu algoritma itu benar.

Bagaimanapun, ini hanya beberapa insiden baru-baru ini, tetapi secara umum saya telah mendengar banyak pengembang berbicara tentang mengkompilasi kode mereka, tetapi belum ada yang bisa memberi tahu saya manfaat dari melakukannya. Saya mengerti manfaat menguji kode Anda saat Anda mulai, tetapi mengapa mengkompilasi?

Jadi pertanyaan saya adalah ini: Apakah ada sesuatu yang saya lewatkan? Apakah sebenarnya ada manfaat untuk kompilasi saat Anda melanjutkan? Atau apakah ini semacam mitos yang disebarkan oleh komunitas perangkat lunak bahwa Anda harus sering mengkompilasi kode Anda?


54
Entah itu, atau kebiasaan saya disebut kebiasaan buruk oleh orang-orang yang memiliki kebiasaan berbeda.
CaptainCodeman

9
@DocBrown Perbandingan ini valid jika tujuan akhirnya memiliki produk yang benar. Program yang "berjalan" tidak lebih baik dari program yang berjalan tidak benar. Anda tidak dapat mengharapkan kompilasi untuk memeriksa kode Anda untuk Anda lebih dari yang Anda harapkan pemeriksaan ejaan untuk memperbaiki kesalahan tata bahasa Anda.
CaptainCodeman

7
Apakah kompilasi mengganggu alur kerja Anda sangat subyektif dan tergantung pada bahasa, membangun lingkungan, ukuran / kompleksitas proyek, dll. IMO lebih cenderung menjadi masalah pada proyek lawas yang besar.
pjc50

64
Saya sepenuhnya setuju dengan OP. Saya tidak bisa mengerti bagaimana seseorang bisa menilai tentang kebiasaan kerja seseorang, misalnya ketika dia menggunakan untuk memulai kompilator. Satu-satunya hal yang diperhitungkan, adalah hasil dari upaya. Apakah itu benar? Apakah bisa dirawat? Apakah itu berjalan dalam jangka waktu yang diharapkan? Berapa lama untuk mengimplementasikannya? Ini adalah pertanyaan menarik. Yang lainnya adalah BS sewenang-wenang. Jika orang yang diwawancarai menulis kode sempurna 2 jam yang mengkompilasi pada percobaan pertama, di mana masalahnya? Hanya karena pewawancara melakukannya secara berbeda? Ya Tuhan.
JensG

9
Juga harus disebutkan bahwa untuk bahasa dan IDE tertentu (Java / [Eclipse | NetBeans | etc], C # / Visual Studio, ...), IDE sudah mengkompilasi semua yang ada di latar belakang secara real time, saat Anda mengetik, di efek memberi Anda loop umpan balik langsung, apakah Anda telah melakukan kesalahan. Orang berharap para pengembang IDE melakukan riset untuk mendukung pendekatan compile-as-you go ini.
Ogre Psalm33

Jawaban:


223

Apakah sebenarnya ada manfaat untuk kompilasi saat Anda melanjutkan?

Ada. Ini memberi Anda loop umpan balik yang lebih pendek - yang secara umum, ketika mendesain (UI, menulis perangkat lunak, desain visual dll ...) adalah hal yang baik.

Umpan balik singkat berarti Anda dapat dengan cepat memperbaiki kesalahan sejak dini, sebelum menjadi lebih mahal untuk diperbaiki.

Untuk meminjam contoh Anda, katakan Anda mengode dalam bahasa seperti-C dan lupa suatu }tempat di tengah-tengah program.

Jika Anda mengkompilasi tepat setelah Anda selesai menulis pernyataan, Anda bisa yakin Anda baru saja memperkenalkan kesalahan kompilasi dan dapat memperbaikinya di sana dan kemudian, dalam hitungan detik.

Namun, jika Anda tidak melakukannya, Anda harus menghabiskan banyak waktu untuk membaca kode, mencari posisi yang tepat }dan memastikan, setelah Anda menemukan kesalahan bahwa perbaikan memang memang dimaksudkan. Ini akan berlangsung beberapa saat setelah Anda meninggalkan sedikit kode itu. Tidak akan sejernih saat Anda menulisnya.


Sekarang, ya, hasil akhirnya sama, tetapi Anda menyia-nyiakan banyak waktu untuk masalah sintaksis bahwa kompiler ada untuk membantu Anda dengan - jumlah waktu yang bisa jauh lebih singkat jika Anda dikompilasi saat Anda melanjutkan.


72
Memang, untuk kesalahan sintaksis seperti itu, IDE modern pada dasarnya mengkompilasi dan mengkompilasi ulang setiap saat untuk membuat umpan balik Anda sesingkat mungkin, dan itu sangat membantu untuk menangkap kesalahan kecil.
Phoshi

12
@ KaptenCodeman - Saya akan mengatakan bahwa ada beberapa kesalahan kompilasi yang mengharuskan Anda untuk menggali cukup banyak kode. Ini lebih benar untuk basis kode yang lebih besar dan set perubahan yang lebih besar.
Oded

29
Terkadang kompiler memberi Anda teka-teki alih-alih petunjuk, seperti kesalahan template gcc.
pjc50

14
@ pjc50: benar-benar (yang lebih mudah ditangani dengan tidak mengubah terlalu banyak hal sekaligus sebelum kompilasi berikutnya, sehingga Anda tahu persis apa yang telah Anda ubah pada akhirnya).
Doc Brown

21
Idenya bukan untuk hanya mengkompilasi secara acak. Ini untuk dikompilasi pada setiap langkah penting, untuk dikompilasi ketika Anda berharap itu masih berfungsi dengan baik. Sebagai contoh, saya akan mengkompilasi untuk menguji untuk memastikan bahwa objek dibuat / dihapus dengan benar, atau untuk memastikan bahwa peristiwa dipecat dengan benar ke kelas baru yang saya buat. Jika saya membuat kelas dan mengaitkannya ke program saya dengan beberapa cara, saya ingin memastikan saya melakukannya dengan benar sebelum melanjutkan mengaitkan lebih banyak barang ke aplikasi saya. Kurang penting dengan aplikasi kecil, penting untuk aplikasi besar.
Thebluefish

108

Kompilasi adalah bentuk tes, terutama dalam bahasa yang menggunakan banyak jenis seperti Haskell atau ML . Dalam bahasa lain ini adalah pemindaian sintaksis yang memberi tahu Anda sedikit.

Karena itu, "kompilasi saat Anda pergi" menurut saya kebiasaan yang sangat situasional. Anda juga bisa dianggap "gugup" karena menyusun lebih sering daripada prasangka pribadi pewawancara. Kedengarannya seperti nitpicking; tidak ada yang suka mengakui bahwa orang yang diwawancarai telah lulus ujian; itu tips skala negosiasi gaji.

Tidak semua sistem build cepat. Saya bekerja pada sebuah proyek (C ++) di mana Membuat akan menghabiskan 30 detik hanya Stat 'ting segalanya untuk menentukan apakah diperlukan untuk membangun atau tidak, dan sebagian besar file akan mengambil beberapa menit untuk membangun jika Anda telah membuat perubahan. Kami enggan melakukan ini lebih sering daripada setiap 10-15 menit. Seseorang pasti akan memberikan anekdot ketika kompilasi melibatkan mengambil setumpuk kartu punch Anda dan membawanya ke gedung yang berbeda ...

Kompilasi ketika Anda merasa telah melakukan unit konseptual yang lengkap di kepala Anda dan siap untuk memvalidasinya. Satu menit atau seminggu sekali tergantung pada alur kerja.


25
ketika Anda mengambil kartu punch Anda untuk memuat, pastikan Anda tidak pernah menjatuhkannya karena menempatkannya kembali dalam urutan yang benar adalah PitA nyata! Ah, untuk hari-hari ketika alat debugging penting adalah pita elastis.
gbjbaanb

3
Ketika saya pertama kali memulai pemrograman saya mengukur kemajuan saya dengan berapa banyak kode yang bisa saya tulis tanpa kompilasi — pada dasarnya oleh kualitas kompiler mental saya. Pada awalnya itu beberapa karakter, lalu beberapa baris. Sekarang saya tidak peduli. Saya mengkompilasi banyak untuk perubahan kecil. Saya hanya ingin melihat efeknya, saya mengkompilasi sangat sedikit ketika melakukan tata letak struktural proyek.
Phil

Hmm. Hanya ingin mengatakan bahwa file C ++ yang ditulis dengan baik tidak perlu lebih dari beberapa detik untuk kompilasi. Jika lebih lama, ini bau untuk kode yang buruk. Dan jika begitu besar yang membuat memiliki masalah, saya berpendapat bahwa aplikasi tersebut terlalu monolitik. "My" make tidak pernah mengalami masalah, dan bahkan tidak ketika kompilasi Linux.
phresnel

2
Itu 1,5 juta LOC ketika saya pergi. Perhatikan bahwa Linux adalah C bukan C ++; templat tampaknya lambat dalam gcc, dan jika Anda telah melakukan sesuatu yang pintar dan berguna yang lambat dikompilasi, tidak ada cara mudah untuk membuat profil kompiler untuk mengetahui apa itu.
pjc50

21
@ gbjbaanb Saya pikir akan lebih baik untuk mengatakan "hari-hari ketika kontrol sumber adalah pita elastis." ;)
JasonMArcher

35

Jadi pertanyaan saya adalah ini: Apakah ada sesuatu yang saya lewatkan?

Ya: pikiran Anda bukan kompiler. Sementara kompiler dapat membuat n konteks beralih per detik, pikiran Anda tidak bisa. Jumlah konteks yang dapat diubah oleh pikiran Anda dalam sehari tergantung pada sejumlah faktor seperti pengalaman / keakraban dengan basis kode, seberapa dalam Anda tenggelam dalam kode, seberapa bersih kode, seberapa rumit masalah yang Anda tangani, seberapa lelah Anda, jika Anda sering terganggu atau di lingkungan yang bising dan sebagainya.

Mengkompilasi basis kode (semua pada saat yang bersamaan), untuk pertama kalinya (pikirkan "proyek dengan 20 file") akan memaksa Anda untuk mengubah konteks dari apa yang Anda pikirkan (mis. "Nilai ini diatur ke 5 di sini, kemudian di for loop blablabla, dan algoritma kompleks menghasilkan nilai yang benar pada pengembalian ") ke masalah kompilasi yang sama sekali tidak terkait dengan apa yang Anda pikirkan (file / modul / fungsi / pra-kondisi / sintaks / nama variabel yang berbeda, prekondisi dll ).

Semakin banyak kode yang Anda kompilasi sekaligus, semakin banyak konteks yang harus Anda ubah. Ini bukan masalah untuk basis kode kecil, ketika semua kode yang Anda tulis adalah apa pun yang Anda tulis dalam satu jam. Ini adalah masalah besar, ketika bekerja di basis kode yang ada, dengan saling ketergantungan ganda (dan berkali-kali tidak berdokumen).

Apakah sebenarnya ada manfaat untuk kompilasi saat Anda melanjutkan?

Anda meminimalkan konteks yang harus dilakukan oleh pikiran Anda, memungkinkan Anda untuk lebih fokus pada dampak dan efek samping dari perubahan yang Anda buat. Ini juga membuat Anda tidak terlalu lelah (dan kurang rentan terhadap kesalahan) dan meningkatkan kualitas output Anda (yaitu Anda dapat menjamin efek samping yang diminimalkan lebih mudah ketika Anda mengubah dan mengkompilasi satu file pada suatu waktu, daripada ketika Anda mengkompilasi dan mengubah sepuluh).

Jika Anda mengkompilasi dalam iterasi yang sangat singkat (ini mengasumsikan proses kompilasi dioptimalkan untuk mengambil waktu singkat) dimungkinkan untuk memperbaiki kesalahan kompilasi tanpa keluar dari "zona".

Atau apakah ini semacam mitos yang disebarkan oleh komunitas perangkat lunak bahwa Anda harus sering mengkompilasi kode Anda?

Ini disebarkan oleh komunitas perangkat lunak juga, tetapi memiliki alasan yang bagus di baliknya.

Dalam pemahaman saya itu argumen yang tidak valid, karena "mendapatkan kode untuk dikompilasi" untuk panjang kode tertentu umumnya melibatkan memperbaiki sejumlah kesalahan kompilasi yang konstan dan membutuhkan waktu yang cukup konstan

Kedengarannya bagi saya seperti Anda memiliki sedikit (tidak ada) pengalaman, dalam pemeliharaan basis kode legacy menengah hingga besar (ratusan atau ribuan file sumber). Di sinilah sikap ini (yaitu "kompilasi sambil jalan") akan sangat membantu, dan di sinilah Anda membentuk kebiasaan semacam ini.

Saya akan membayangkan bahwa orang-orang yang mewawancarai Anda menarik kesimpulan yang sama ("Anda memiliki sedikit atau tidak ada pengalaman dalam basis kode besar").


1
"kompilasi dan ubah sepuluh" - banyak situasi di mana ini adalah unit terkecil yang berarti untuk dicoba; seperti menambahkan parameter baru ke suatu fungsi dan semua situs panggilannya.
pjc50

7
Switch konteks. kamu bercanda kan? Jika kami berbicara tentang kompilasi latar belakang otomatis untuk menunjukkan kesalahan sintaksis dalam kode Anda saat Anda mulai, itu tidak masalah. Tetapi saklar konteks tercepat tidak akan dapat memberi tahu Anda, apakah logika algoritma diterapkan dengan benar atau apakah algoritma tersebut cocok sama sekali. Tapi itulah yang membedakan solusi kerja dari yang tertata rapi, bebas dari kesalahan yang dikompilasi dan peledakan kode yang cepat, tetapi benar-benar salah.
JensG

5
@ Jen, tidak, aku tidak bercanda. Harus melompati seluruh kode untuk memperbaiki kesalahan kompilasi memastikan Anda tidak lagi memikirkan masalah yang sedang Anda selesaikan (membuat Anda keluar dari zona). Jika sebaliknya, Anda dapat mengkompilasi saat Anda menulis kode Anda dapat terus bekerja memeriksa algoritma - bukan sintaks. Cara tercepat untuk menangani sakelar konteks adalah memastikan Anda tidak membutuhkannya). Posting saya memang mengasumsikan dunia ideal (dengan kompilasi C ++ cepat dari basis kode besar dan antar-ketergantungan diminimalkan).
utnapistim

1
@ JensG yang tampaknya merupakan kesalahan logis: ini bukan tentang memilih antara kode yang dikompilasi dan kode menyebalkan tetapi tentang kemungkinan manfaat kompilasi lebih dari sekali.
Jorg

1
Saya ragu bahwa klaim bahwa memecah konsentrasi puluhan kali untuk waktu yang singkat untuk memperbaiki kesalahan sintaksis tunggal lebih cepat daripada memecahnya sekali dan memperbaiki selusin kesalahan sintaksis sekaligus (setelah Anda khawatir tentang algoritma Anda yang sebenarnya). Itu tentu bukan cara kerja switch konteks dalam komputasi (kami mencoba untuk mengoptimalkan throughput setelah semua di sini). Dan saya telah mengerjakan proyek dengan sekitar 500k LoC dari kode C ++ yang telah berkembang lebih dari satu dekade, jadi saya harap kita belum menggambar kartu kurang pengalaman?
Voo

26

Saya pikir ada lebih dari sedikit keangkuhan profesional di sini. Implikasinya tampaknya adalah "jika Anda tidak pernah memiliki kebutuhan untuk mengkompilasi secara teratur maka Anda tidak pernah bekerja dengan apa pun yang rumit - dapatkan lebih banyak pengalaman dan kembali ketika Anda telah belajar untuk bekerja persis seperti yang kita lakukan."

Tapi jelas ada sisi lain dari ini. Beberapa proyek membutuhkan waktu untuk dikompilasi. Saya telah bekerja dengan kerangka kerja yang membutuhkan waktu 30 menit atau lebih untuk dikompilasi bahkan setelah diedit kecil. Surga membantu Anda jika Anda perlu mengedit file header. Kompilasi penuh biasanya dilakukan dalam semalam, dan jika Anda mengandalkan kompiler untuk menangkap kesalahan Anda, masih ada kesalahan langka yang tidak akan terdeteksi selama pembangunan parsial. Anda hanya tidak melakukan kompilasi ulang setiap 5 menit dalam kondisi ini - kecuali jika Anda merasa malas .

Kompiler tidak dapat membantu Anda dengan kesalahan logis atau semantik dan kesalahan sintaks benar-benar tidak terlalu sulit untuk menghindari menghabiskan setengah hari dari kompilasi menjadi bermanfaat. Tentu saja, Anda akan membuat kesalahan ketik sesekali, tetapi saya akan menganggap Anda bisa mengetik dan membaca. Jika Anda memiliki kebebasan untuk memilih, gunakan gaya pengkodean yang memanfaatkan tata letak dengan baik untuk menyoroti kesalahan secara visual dan Anda tidak akan pernah lagi menjatuhkan tanda kurung, tanda kurung, atau tanda titik koma. Dibutuhkan sedikit latihan dan sedikit lebih banyak disiplin daripada yang biasa dilakukan, tetapi itu mungkin. Saya dapat menulis kode selama beberapa jam sekaligus, dalam editor teks biasa, dan mengkompilasinya pertama kali lebih baik daripada sembilan kali dari sepuluh. Tentu, saya bisa mengkompilasi lebih sering, tetapi saya tidak ingat kapan terakhir kali saya memiliki kesalahan yang akan lebih mudah untuk diperbaiki sebagai hasilnya.

Jika Anda bukan penggemar kompilasi ulang yang konstan, Anda berada di perusahaan yang baik. Inilah Donald Knuth:

Mengenai pertanyaan Anda yang sebenarnya, gagasan tentang kompilasi langsung dan "tes unit" jarang saya dapatkan, ketika saya merasakan jalan saya di lingkungan yang sama sekali tidak dikenal dan membutuhkan umpan balik tentang apa yang berhasil dan yang tidak. Kalau tidak, banyak waktu yang terbuang untuk kegiatan yang saya tidak perlu lakukan atau bahkan pikirkan.


Semua itu dikatakan ... jika Anda bekerja dalam konteks di mana kompilasi adalah tindakan bebas, mengapa Anda tidak melakukannya? Di rumah, pada proyek-proyek pribadi, saya menekan ctrl-S sekali setiap 30 detik dan pintasan "kompilasi" hampir sama seringnya, dalam sebuah IDE yang terus-menerus menjalankan kode melalui ujung depan kompiler untuk memberikan sorotan kesalahan waktu-nyata. Mengapa melewatkan makan siang gratis?


Saya tidak setuju bahwa kompilasi gratis, gangguan mahal! Tetapi sebaliknya, jawaban yang bagus, terima kasih :)
CaptainCodeman

Mungkin saya seharusnya membuat huruf tebal, huruf miring "jika" sebuah "iff" ... Saya pikir tergantung pada proyek, kompiler dan lingkungan, itu bisa sangat dekat dengan tindakan bebas. Jika Anda memiliki jendela atau layar kedua untuk keluaran kompiler maka Anda dapat mengkompilasi hampir sesering Anda berhenti bernapas. Jika Anda benar-benar hardcore (saya tidak), Anda bahkan tidak perlu berpaling dari kode Anda - asalkan kompiler menghasilkan kesalahan yang cukup banyak untuk didaftarkan pada penglihatan tepi Anda. Sekali lagi, ini jika kompilasi cukup cepat, jika tidak lihat di atas.
DeveloperInDevelopment

2
I hit ctrl-S about once every 30 seconds. Saya mungkin menyimpan dua kali lebih sering lol. Itu kebiasaan yang sangat buruk. Kadang-kadang saya akan menyimpan di tengah-tengah baris kode, dan kemudian menyimpan lagi di akhir. Setiap kali saya berhenti untuk berpikir sejenak dan tidak mengetik, saya menabung.
Cruncher

21

Ada beberapa manfaat untuk dikompilasi saat Anda pergi. Tapi saya sangat setuju bahwa tetap pada tugas adalah strategi pengkodean yang OK.

Manfaat paling signifikan untuk kompilasi tambahan adalah mentalitas yang masuk jika mereka menunggu sampai akhir dikompilasi dan diuji : kami lebih peduli pada akhirnya dalam menjalankan kode daripada apa pun pada saat itu. Kita berkata "Oh, hanya perlu menambahkan braket ini sehingga kompiler berhenti mengeluh" atau "oh hanya perlu memanfaatkan ini" tanpa berpikir jika ada kesalahan semantik yang mendasari kesalahan menyembunyikan sintaks ini. Saya benar-benar menemukan kesalahan sintaksis sering bersarang di kesalahan semantik (yang sebaliknya tidak benar).

Sebagai contoh, katakan saya mengubah arti variabel dan sebagai hasilnya, mengubah namanya. Perubahan nama menghasilkan kesalahan sintaks di kemudian hari dalam kode tetapi jika saya hanya menyenangkan kompilator dengan memperbaiki nama, saya telah mengabaikan mengapa kesalahan itu muncul.


5
+1 untuk menyoroti hubungan antara kesalahan semantik dan kesalahan
Doc Brown

15

Saya mengerti manfaat menguji kode Anda saat Anda mulai, tetapi mengapa mengkompilasi?

Tetapi bagaimana Anda akan menguji kode Anda ketika Anda pergi ketika Anda tidak mengkompilasi sesuai?

Kasus ekstremnya adalah test-driven development (TDD). Jelas bahwa TDD tidak bekerja dengan strategi Anda, karena TDD berarti siklus penulisan yang sangat singkat, kompilasi (harus gagal), tulis-kode, kompilasi lagi, jalankan-tes, perbaiki bug, kompilasi lagi, refactor, kompilasi -lagi, jalankan-tes, dan-seterusnya ...

Jadi tidak semua orang melakukan TDD, setidaknya tidak selalu (saya juga, saya akui). Dengan strategi Anda saat ini, Anda tidak akan pernah memiliki kesempatan untuk mencoba TDD. Tetapi bahkan ketika Anda tidak melakukan TDD, IMHO sangat membantu untuk menguji kode Anda lebih teratur - yang tidak mungkin ketika Anda tidak mengkompilasi secara teratur. Dan ketika tes Anda gagal, Anda harus menjalankannya untuk debug (yang dapat membantu Anda memahami mengapa algoritma yang tampak bagus yang Anda tulis beberapa menit sebelumnya tidak berperilaku sebaik yang Anda pikir seharusnya dilakukan). Dan semakin banyak kode yang Anda tulis tanpa kompilasi, semakin banyak kode yang Anda tulis tanpa pengujian, sehingga semakin besar kemungkinan Anda akan mengalami kasus di mana Anda tidak dapat memprediksi bahwa waktu untuk memperbaiki masalah adalah "O (1)", seperti Kau menulis.


1
Saya setuju dengan Anda, tetapi saya pikir ada perbedaan antara mengkompilasi program karena Anda ingin menjalankannya, vs. mengkompilasi ketika tidak ada yang berarti untuk diuji (atau untuk memperbaiki kesalahan kompilasi).
CaptainCodeman

@ KaptenCodeman: Saya pikir ketika menulis 100 baris kode, hampir selalu ada banyak bagian kecil yang bisa diuji sendiri-sendiri. 100 baris kode biasanya berarti antara 4 dan 15 fungsi (atau> 20, jika Anda kode dengan gaya Bob Martin).
Doc Brown

5
@CaptainCodeman: Di TDD tidak pernah ada "tidak ada yang berarti" untuk diuji. Contoh klasik adalah Anda ingin menulis kelas baru (sebut saja Foo) maka hal pertama yang Anda lakukan adalah membuat unit test dan menulis new Foo();yang jelas akan gagal dikompilasi karena Anda belum menulis definisi kelas. Dalam TDD itu alasan yang sah untuk menjalankan kompiler - itu membuktikan bahwa uji unit Anda berfungsi (dengan gagal).
slebetman

@slebetman: terima kasih atas komentar yang bermanfaat itu. Saya ingin menambahkan bahwa IMHO ini tidak terbatas pada TDD. Saat menulis 100 baris kode, selalu ada sesuatu yang bermakna untuk diuji di antaranya, apakah Anda melakukan TDD atau tidak.
Doc Brown

14

Saya sebenarnya setuju dengan Anda bahwa kesalahan kompiler seharusnya bukan masalah besar bagi pengembang yang berpengalaman. Saya tidak berpikir biaya untuk memperbaikinya meningkat cukup signifikan dari waktu ke waktu untuk dikhawatirkan. Jika mungkin untuk menunda memperbaiki semua kesalahan kompiler sampai sebelum push, saya akan melakukannya, karena akan menghadirkan gangguan yang jauh lebih kecil dan lebih terkonsolidasi.

Sayangnya, menemukan kesalahan penyusun bukan satu-satunya yang dilakukan penyusun. Dengan risiko menyatakan yang sudah jelas, kompilasi diperlukan untuk menjalankan program Anda, dan menjalankan program Anda diperlukan untuk menemukan semua bug runtime yang lebih kompleks, halus, dan menarik yang bahkan dibuat oleh pengembang berpengalaman. Dan jenis-jenis bug itu lebih sulit dan karenanya lebih mahal untuk memperbaikinya semakin lama Anda menunda debugging mereka, karena mereka dapat membangun atau menutupi satu sama lain.

Namun, saya tidak perlu menandai seseorang dalam latihan wawancara karena menunda kompilasi sampai akhir. Latihan wawancara cenderung sangat mudah, dan pengembang yang berpengalaman biasanya mengetahui batasannya. Semakin yakin Anda tentang apa yang Anda tulis, semakin lama Anda akan pergi di antara kompilasi. Itu hanya sifat manusia.

Agar tidak membuat Anda kecewa karenanya, kepercayaan diri harus dibenarkan. Jika Anda menghabiskan 45 menit menulis sesuatu tanpa kompilasi, maka diperlukan 45 menit lagi untuk men-debugnya, saya akan sangat membebani Anda.


8

Satu hal penting tentang kompilasi sering, hilang dari jawaban lain sejauh yang saya bisa lihat adalah ini: jika Anda jarang mengkompilasi dan mendapatkan sejumlah besar kesalahan kompiler, sebagian besar tidak ada artinya, karena mereka dihasilkan oleh kesalahan pertama. Mungkin karena Anda salah ketik, atau salah ketik, atau kesalahan sintaksis biasa yang membuat beberapa pernyataan tidak valid.

Anda selalu bisa memperbaiki yang pertama, mengkompilasi ulang, memperbaiki yang tersisa berikutnya, dan seterusnya, tetapi dengan basis kode besar ini bisa lambat. Tetapi jika Anda mencoba membaca daftar panjang kesalahan kompiler dan kesalahan tempat yang independen, maka Anda menghabiskan banyak waktu membaca pesan yang tidak relevan, atau menavigasi kode dari tempat kesalahan sekunder ke penyebab sebenarnya.

Hal lain yang terjadi pada build biasa adalah, tidak ada yang menghentikan Anda dari mulai mengkompilasi segera setelah Anda memiliki blok kode lengkap yang ditulis, yang harus dikompilasi. Anda kemudian dapat melanjutkan menulis lebih banyak kode saat kompilasi berjalan, selama Anda tidak menyimpan editan baru sampai kompilasi selesai. Jadi praktis tidak ada waktu terbuang untuk menunggu pembangunan. Jika Anda menunggu sampai Anda telah menulis semua yang akan Anda tulis pada saat itu, Anda harus menunggu kompilasi tanpa melakukan apa pun. Ini pada dasarnya adalah versi manual dari apa yang dapat dilakukan IDE modern di latar belakang secara otomatis.


Menariknya, ini adalah alasan yang bagus untuk melakukan kompilasi secara teratur walaupun kompilasi berjalan lambat . Poin bagus.
sleske

3

Untuk programmer yang cukup berpengalaman mengkompilasi kode tidak pernah menjadi hambatan.

Setelah Anda tahu bahasa dengan cukup baik (yaitu ketika Anda tidak lagi harus berpikir tentang sintaks dan alih-alih hanya kode untuk fungsi), Anda cenderung tidak membuat kesalahan sintaksis yang sederhana. Yang Anda buat biasanya bug kesalahan ketik atau salin-tempel, dan mereka dapat dibersihkan dalam waktu singkat hanya dengan beberapa pass kompilasi.

Saya secara teratur menulis kode sepanjang hari tanpa kompilasi, maka saya akan mengkompilasi dan hanya memperbaiki kesalahan sintaks dan peringatan apa yang dilaporkan kompiler sebelum saya mengkomit kode saya (dengan catatan yang mengatakan "perlu diuji!" ). Saya tidak punya masalah membersihkan 1.000+ baris kode C atau C ++ hanya dalam beberapa menit.

Debugging dan pengujian di sisi lain adalah apa yang butuh waktu. Kesalahan logika muncul karena berbagai alasan dan saya belum menemukan kompiler yang akan memberi tahu saya tentang subrutin yang saya lupa tuliskan, atau akan melihat bahwa pohon biner saya tidak berfungsi karena saya menempelkannya node->leftketika seharusnya node->right.

Meskipun saya pikir secara umum tidak bijaksana untuk berkelahi dengan pewawancara, saya akan mengatakan jika Anda merasa gaya Anda layak dipertahankan, Anda harus menunjukkan bahwa Anda memiliki waktu yang cukup untuk men - debug kode yang Anda tulis. Itulah hal yang tidak pernah diabaikan oleh programmer yang baik.

ps - Jika saya melihat Anda meninjau kode dengan membacanya, saya akan mempekerjakan Anda di tempat. Itulah yang dilakukan seorang profesional, setiap saat.


4
"Aku belum bertemu dengan kompiler yang akan memberitahuku tentang subrutin yang aku benar-benar lupa untuk menulis." Saya benar-benar mengandalkan kompiler untuk memberi tahu saya ketika saya belum menyelesaikan perubahan yang jauh. Kadang-kadang saya bahkan mengganti nama variabel untuk mencegah kompilasi yang berhasil sampai saya telah memeriksa setiap contoh penggunaannya dan memberi mereka semua nama baru. Saya tidak mengerti bagaimana Anda bisa mengatakan Anda belum menemukan kompiler yang tidak akan memperingatkan Anda jika ada sesuatu yang hilang. Kecuali Anda menulis subrutin tempat penampung kosong dan kemudian melupakannya, dalam hal ini surga membantu Anda.
Ian Goldby

@par Terima kasih atas jawaban Anda; Senang mengetahui bahwa saya bukan satu-satunya yang kode seperti ini!
CaptainCodeman

3
@ KaptenCodeman Saya sangat menyadari bahwa kesalahan logika lebih berbahaya daripada kesalahan kompiler. Tapi itu adalah pernyataannya tentang kompiler yang tidak dapat memberi tahu Anda tentang kode yang hilang yang ingin saya sengketakan. Kecuali Anda sengaja menulis kode yang salah (atau tidak lengkap) yang mengkompilasi ..., tapi itu agak mengalahkan argumen bahwa kesalahan yang tidak dapat ditangkap oleh kompiler adalah masalah IMO yang sebenarnya. Heck, saya bahkan menggunakan kompiler untuk memindahkan tanda sisipan ke baris di mana saya selanjutnya perlu menulis beberapa kode. Tapi mungkin aku sangat malas.
Ian Goldby

1
@IanGoldby: Anda benar-benar melewatkan maksudnya dan saya bahkan melangkah lebih jauh dengan mengatakan Anda memilih untuk memutarbalikkan kata-kata saya. Kompiler tidak dapat memperingatkan Anda tentang kode yang hilang dengan cara yang sama saya tidak bisa memberi tahu Anda apa yang akan Anda makan untuk sarapan besok. Memperkenalkan kesalahan sintaksis secara sengaja sehingga kompiler akan mengingatkan Anda tentang sesuatu adalah teknik pemrograman; itu tidak memenuhi syarat sebagai kesalahan atau memberikan kekuatan super psikis kompiler.
par

1
@par Saya minta maaf atas pelanggaran yang saya jelas disebabkan oleh komentar saya - itu tidak dimaksudkan dan saya tentu tidak bermaksud untuk salah mengartikan apa yang Anda katakan. Saya melihat sekarang bahwa ketika Anda menulis kode tidak lengkap yang tetap dikompilasi, Anda membuatnya menjadi praktik untuk memastikan bahwa itu tidak dapat dilupakan dengan menambahkan #warning atau TODO. Itu teknik yang sah. Yang penting, yang kami berdua sepakati, adalah kode yang mengkompilasi tetapi tidak berfungsi jauh lebih berbahaya daripada kode yang tidak dikompilasi.
Ian Goldby

3

Tidak, itu tidak masuk akal untuk menunda kompilasi sampai Anda telah melakukan jumlah kode yang cukup (dan 'jumlah yang cukup' tergantung pada pembuat kode dan kode yang sedang ditulis).

Sebagai contoh, jika Anda seorang pembuat kode yang luar biasa yang mengambil waktu untuk memperbaikinya, dan Anda tidak menulis kode dalam jumlah besar atau berbelit-belit, maka kompilasi secara teratur adalah pemborosan, dan mungkin juga pengalih perhatian. Jika tidak, kompilasi setiap fungsi bisa menjadi hal yang baik. Tergantung orangnya.

Sebagai contoh tandingan, bayangkan Anda sedang menulis kode JavaScript - tidak ada kompiler. Alih-alih (mengingat sifat sebagian besar kode JavaScript) Anda akan menjalankan program (atau menyegarkan halaman) untuk melihat hasil pengkodean Anda. Sekarang, Anda tidak dapat melakukan itu sampai Anda menulis kode yang cukup masuk akal. Akibatnya, pengembang JavaScript cenderung "mengkompilasi" sesering mungkin, yang belum tentu sangat sering.

Singkatnya, tidak ada jawaban yang benar di sini - pewawancara tidak salah, tetapi Anda juga tidak. Lakukan apa yang membuat Anda produktif dan lupakan apa yang dikatakan orang kepada Anda bahwa Anda seharusnya melakukannya. Ada banyak faktor yang lebih penting tentang pengkodean daripada kecenderungan Anda untuk memukul F7secara teratur (atau tidak) sama sekali tidak ada konsekuensinya.


Paragraf kedua Anda tidak jelas; Anda mungkin ingin mengeditnya, agar jelas apakah "pembuat kode yang mengagumkan" harus dikompilasi secara teratur atau tidak. (Apakah Anda menambahkan "t" dan mengubah "tidak" menjadi "tidak"?)
DougM

@DougM - ta banyak.
gbjbaanb

Cukup sering kode skrip dikembangkan "langsung", yang dijalankan di lingkungan REPL. Jadi "kompilasi" memang terjadi setiap saat, sebagian besar kode yang ditulis ke file sumber juga telah dieksekusi sekali. Tidak semua menulis kode skrip dengan cara ini, tapi saya akan mengatakan siapa pun terbiasa dan menyukai "keamanan" relatif dari bahasa yang diketik secara statis dan kesalahan kompiler yang diberikan oleh kode buruk, mereka harus bekerja dalam bahasa skrip dengan cara ini.
hyde

2

Dengan lingkungan pengembangan yang baik saya melihat sedikit alasan untuk mengkompilasi kecuali Anda benar-benar berencana untuk menguji kode. Alat pemeriksaan sintaksis latar menangkap sebagian besar segala sesuatu yang tampaknya dibicarakan oleh pewawancara, meskipun saya akui masih ada beberapa kasus (melibatkan perubahan yang menyebar di seluruh file) yang tidak selalu sepenuhnya diidentifikasi.

Yang sedang berkata, saya akan mencoba untuk mengkompilasi dan menjalankan unit kode terkecil yang benar-benar dapat menghasilkan hasil. Setengah jam yang lalu saya menciptakan cara untuk mencetak beberapa hasil pencarian dan saya melakukan setengah lusin cetakan tes (untuk .pdf, bukan kertas) membuat perubahan pada hasil agar terlihat lebih baik - tingkat sekitar 1 kompilasi per 10 garis.


1

Menurut pendapat saya dan pengalaman saya, apakah kompilasi kode atau tidak pada dasarnya acak, melibatkan hal-hal seperti apakah titik koma hilang atau tidak, dan tidak ada hubungannya dengan kebenaran dari program yang mendasarinya. (Bagi saya, fokus pada kompilasi adalah seperti menjalankan artikel melalui pemeriksa ejaan tanpa proofreading untuk memeriksa tata bahasa.)

Pengalaman saya sangat berbeda: kurang dari 5% kesalahan kompilasi yang saya dapatkan adalah tentang sintaks . Saya tahu bahasanya dengan baik, ketika saya mendapatkan kesalahan itu sebagian besar jenis kesalahan, mengatakan kepada saya bahwa semantik tidak benar.

Inilah sebabnya saya senang mendapatkan manfaat secepat mungkin dari umpan balik dari kompiler saya. Pernahkah Anda mengalami menggunakan IDE yang menggarisbawahi kesalahan kompilasi secara real-time? Memiliki umpan balik yang lebih pendek bisa sangat berharga.

Jika Anda memberi saya sepotong kode tidak lengkap, hal pertama yang saya lakukan adalah membacanya. Saya bahkan tidak akan mencoba untuk mengkompilasinya sampai saya tahu apa yang dilakukan kode dan saya tahu algoritma itu benar.

Jika Anda diharapkan mengerjakan kode yang ditulis oleh orang lain, Anda tidak selalu punya waktu untuk membaca semuanya. Berita baiknya adalah: kode yang ditulis dengan baik memiliki kopling rendah, dan harus memungkinkan Anda untuk berpikir secara independen tentang hanya bagian dari kode yang Anda butuhkan.

Dalam kasus tersebut, Anda harus menganggap bahwa kode yang belum Anda baca sudah benar, dan selidiki dengan malas ketika ada masalah.

"mendapatkan kode untuk dikompilasi" untuk panjang kode tertentu umumnya melibatkan memperbaiki jumlah kesalahan kompilasi yang konstan dan membutuhkan waktu yang cukup konstan, yang harus sama apakah Anda melakukannya setelah Anda selesai menulis kode, atau jika Anda interleave dengan waktu coding Anda.

Pergantian konteks mahal untuk otak Anda, oleh karena itu memperbaiki kesalahan kecil segera setelah Anda menulisnya bisa lebih efisien.

EDIT: Saya juga bisa membuat analogi dengan kontrol sumber, ketika seluruh tim bekerja pada sumber yang sama. Mengompilasi saat Anda mengikuti adalah seperti membuat sering melakukan, itu membantu untuk menghindari memiliki banyak rasa sakit pada akhirnya ketika Anda harus menggabungkan dan memilah semuanya.

Anda mengatakan bahwa Anda menonaktifkan hal-hal seperti garis merah di bawah teks Anda. Apakah Anda juga melakukan itu ketika mengetik email atau menulis dokumen teknis? Maka Anda harus membaca ulang lagi semua halaman alih-alih memperbaiki kesalahan saat Anda melakukannya.

Keuntungan lain adalah, ketika bekerja pada kode Anda, jika Anda tetap mengkompilasi atau hampir-kompilasi setiap saat, Anda bisa mendapat manfaat dari banyak fitur IDE berbasis semantik (penggantian nama yang aman, refactoring, menemukan penggunaan simbol ...) .

Jika Anda ingin memiliki pemahaman yang lebih baik tentang bagaimana fitur ini membantu, Anda dapat mencoba mengaktifkannya dan berlatih, untuk merasakan sendiri manfaatnya bagi diri Anda. Anda juga bisa mencoba melakukan pemrograman pasangan dengan siapa saja yang terbiasa dengannya, dan lihat bagaimana mereka mendapat manfaat darinya.


1
Saya biasanya mematikan "fitur" kompiler yang mengganggu seperti pemformatan otomatis, menggambar garis merah di bawah teks Anda, dll. Saya merasa saya lebih produktif tanpa fitur-fitur bodoh ini.
CaptainCodeman

1

Saya berpikir sedikit lebih lama tentang ini, karena saya merasa ada sesuatu yang sangat, sangat salah dengan pewawancara dan tidak bisa menunjukkan dengan tepat apa itu. Inilah masalahnya: Untuk kode apa pun yang telah saya tulis dalam dua puluh tahun terakhir, jumlah waktu yang diperlukan untuk mengubah algoritma yang bisa diterapkan menjadi kode yang dikompilasi sangat minim. Setiap keuntungan dalam efisiensi di bidang itu memiliki dampak yang sangat kecil pada total waktu pengembangan sehingga benar-benar dapat diabaikan, dan seorang pewawancara yang menolak calon yang dianggap tidak efisien di daerah itu tidak tahu apa yang membuat pengembang yang baik.

Sebagian besar waktu harus dihabiskan untuk mengumpulkan informasi apa yang seharusnya dilakukan kode, mengumpulkan informasi dan spesifikasi tentang layanan luar yang perlu digunakan, menciptakan desain global yang akan mengarah pada kode yang benar dan dapat dipelihara alih-alih diretas bersama kode, dan menemukan algoritma yang akan mengarah pada kode yang berfungsi alih-alih kode yang ditambal bersama-sama hingga berfungsi (kode yang jelas tidak memiliki kesalahan vs. kode yang tidak memiliki kesalahan yang jelas).

Kemudian datang sejumlah kecil waktu menulis kode yang mengkompilasi.

Kemudian datang sejumlah besar waktu yang dihabiskan untuk memastikan bahwa kode itu berfungsi, dan untuk memastikan bahwa kita tahu bahwa kode itu berfungsi dan akan tetap berfungsi. Yang dilakukan dengan menulis tes unit, melangkah melalui kode, dan sebagian besar dengan memiliki kode yang dirancang dengan baik sejak awal.

Pewawancara ini berkonsentrasi pada sesuatu yang ditutupi oleh sepuluh kata dalam jawaban saya. Yang mewakili 10 persen atau kurang dari waktu kerja yang sebenarnya. Dan hampir tidak memiliki pengaruh pada kemampuan pengembang untuk menghasilkan kode yang andal dan berfungsi.


Itu sangat masuk akal. Menurut pendapat saya, pengembang yang baik harus bisa menulis kode di atas kertas sepanjang hari, dan kemudian pada akhir hari ketik itu.
CaptainCodeman

1

Keuntungan dari "kompilasi sambil jalan" adalah Anda mendapatkan umpan balik yang konstan, dan tidak akan memiliki peluang untuk berbuat salah sebelum didorong ke arah yang benar. Untuk programmer yang kompeten seperti Anda, itu bukan pertimbangan besar, tetapi bagi banyak orang lain itu. Dengan kata lain, "kompilasi sambil jalan" adalah cara "meminimalkan kerugian maksimum," meskipun ada beberapa potensi kerugian efisiensi dalam kasus Anda.

Perusahaan saat ini tidak hanya tertarik pada produk jadi. Mereka ingin tahu bahwa itu "di bawah kendali" selama ini. Bagi mereka, "mencapai setengah kesenangan."


ini tampaknya tidak menawarkan sesuatu yang substansial atas apa yang diposting di 16 jawaban sebelumnya
agas

2
Terima kasih tapi kerugian macam apa yang sedang kita bicarakan? Tentunya, kecuali Anda telah melakukan sesuatu yang drastis seperti tidak sengaja menulis dalam bahasa yang salah, Anda tidak perlu menulis ulang kode apa pun hanya karena kesalahan kompilasi.
CaptainCodeman

@CaptainCodeman: Itu membuat perusahaan merasa lebih baik, dan merupakan bentuk "asuransi." Itu adalah sesuatu yang membutuhkan biaya, tetapi membuat kebanyakan orang (termasuk manajer) "tidur lebih nyenyak di malam hari."
Tom Au

@gnat: Poin yang saya coba sampaikan adalah bahwa sebagian besar manfaatnya adalah manfaat tingkat "korporat", dan itu adalah sesuatu yang harus dilakukan oleh programmer karena bos menyuruhnya, bukan karena programmer menganggap itu benar atau salah.
Tom Au

poin baik yang mendukung "umpan balik yang lebih pendek" telah dibuat dan dijelaskan dengan baik dalam jawaban pertama di sini; Jujur saya tidak melihat betapa isinya menebak tentang "perusahaan hari ini" menambahkan sesuatu yang layak atas apa yang sudah dinyatakan
nyamuk

1

Jawaban lain di sini adalah pertahanan yang bagus untuk sering mengkompilasi pada pekerjaan , tetapi karena pertanyaan Anda terpusat pada wawancara , saya ingin membahasnya.

Dalam wawancara saya, saya melakukan yang sebaliknya: kandidat tidak dapat menggunakan kompiler. Mereka menulis program pendek di papan tulis dan kemudian kita membahasnya. Saya telah menemukan bahwa terlalu banyak pengembang yang menggunakan kompiler (atau penerjemah) sebagai penopang, dan itu adalah pemborosan waktu yang jauh lebih besar daripada mengkompilasi terlalu jarang. Jika saya menawarkan Anda banyak uang dan Anda bahkan tidak bisa menulis FizzBuzz dengan benar tanpa kompiler, maka Anda tidak akan pernah memotongnya untuk jangka panjang, mengerjakan masalah yang 100x lebih sulit daripada latihan mainan. dalam wawancara. Namun latihan-latihan sederhana ini menyingkirkan lebih banyak kandidat daripada bagian wawancara lainnya.

Tujuan dari sebuah wawancara adalah untuk mengevaluasi kesesuaian timbal balik dari kandidat dan bisnis. Pertanyaan wawancara yang baik harus menyatakan tujuan pertanyaan dan bagaimana orang yang diwawancara akan dinilai. Melontarkan pertanyaan jebakan pada orang yang diwawancarai dan kemudian menghukum mereka karena tidak mengetahui jawaban tersembunyi tidak membantu pewawancara atau orang yang diwawancarai. Sayangnya, sebagian besar programmer - bahkan yang senior - tidak dilatih untuk mewawancarai programmer lain, jadi mereka hanya mengandalkan klise dan menanyakan jenis pertanyaan yang sama dengan yang mereka tanyakan ketika diwawancarai, tanpa banyak memikirkan apakah ini merupakan teknik yang efektif untuk mengevaluasi kandidat atau tidak.

Saya tidak mengklaim bahwa pendekatan saya adalah "satu jalan yang benar", tetapi itu sangat membantu saya. Seperti banyak metodologi perangkat lunak yang dimulai dengan huruf kapital, ada jumlah "mandat" yang sama untuk wawancara. Mereka semua tidur. Anda perlu melakukan apa yang berhasil untuk Anda dan bisnis Anda.


0

Dalam proyek yang lebih besar, dengan beberapa subrutin, Anda ingin menguji bagian-bagian ini, sebelum menggunakannya dalam skema yang lebih besar, karena jauh lebih mudah untuk melakukan debug jika Anda tahu bagian-bagian tertentu sudah berfungsi.

Untuk menguji potongan-potongan yang lebih kecil ini, Anda perlu mengkompilasi.

Mungkin pewawancara membingungkan situasi ini dengan program kecil yang tidak dirancang dengan cara ini.


0

Mengenai wawancara kedua, manfaat kompilasi adalah Anda dapat mengamati, hanya dalam beberapa detik, apa yang dilakukan oleh program (atau tidak). Dari sana lebih mudah untuk membaca kode dan memfokuskan upaya Anda pada bagian yang relevan. Mungkin inilah yang diharapkan pewawancara.

Membaca basis kode yang tidak dikenal seperti ini dari awal hingga akhir bisa sangat tidak produktif (Anda bukan kompiler), sementara kompilasi / menjalankan aplikasi akan dengan cepat memberi Anda gambaran yang lebih besar.


ini tampaknya tidak menawarkan sesuatu yang substansial atas apa yang diposting di 15 jawaban sebelumnya
agas
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.