Apakah ada manfaat dalam mengkompilasi kode Anda saat Anda melanjutkan?

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?

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.

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.

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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.