Memeriksa kode "berkomentar" [ditutup]

Oke, ini adalah sesuatu yang menyebabkan beberapa gesekan pada pekerjaan saya saat ini dan saya benar-benar tidak mengharapkannya. Pengembangan perangkat lunak terorganisir di rumah adalah konsep baru di sini dan saya telah menyusun draf pertama dari beberapa pedoman pengkodean.

Saya telah mengusulkan agar kode yang "dikomentari" tidak boleh diperiksa ke dalam repositori. Alasan saya menyatakan ini adalah karena repositori menyimpan riwayat lengkap file. Jika Anda menghapus kode fungsional, hapus semuanya. Repositori menyimpan perubahan Anda sehingga mudah untuk melihat apa yang telah diubah.

Hal ini menyebabkan beberapa gesekan di mana pengembang lain percaya bahwa mengambil rute ini terlalu membatasi. Pengembang ini ingin dapat mengomentari beberapa kode yang sedang dia kerjakan tetapi tidak lengkap. Kode ini kemudian tidak akan pernah diperiksa sebelumnya dan kemudian tidak disimpan di mana pun. Kami akan menggunakan TFS jadi saya menyarankan bahwa menyimpan perubahan akan menjadi solusi yang paling tepat. Namun itu tidak diterima karena dia ingin dapat check in sebagian perubahan yang mungkin atau mungkin tidak diterapkan.

Kami ingin akhirnya mencapai titik di mana kami memanfaatkan sepenuhnya Integrasi Berkelanjutan dan secara otomatis menerapkan ke server web pengembangan. Saat ini tidak ada versi pengembangan server web atau server basis data tetapi itu semua akan segera diubah.

Ngomong-ngomong, apa pendapatmu? Apakah Anda yakin bahwa kode "yang diberi komentar" berguna untuk dimiliki di repositori?

Saya sangat tertarik untuk mendengar dari orang lain tentang topik ini.

Sunting: Demi kejelasan, kami tidak menggunakan cabang pribadi. Jika kami melakukannya maka saya akan mengatakan melakukan apa yang Anda inginkan dengan cabang pribadi Anda tetapi jangan pernah menggabungkan kode yang diberi komentar dengan batang atau cabang bersama.

Sunting: Tidak ada alasan yang sah kami tidak menggunakan swasta atau per cabang pengguna. Ini bukan konsep yang tidak saya setujui. Kami hanya belum mengaturnya seperti itu. Mungkin itu jalan tengah akhirnya. Untuk saat ini kami menggunakan rak TFS.

Mungkin ada orang lain dengan pengalaman yang berbeda, tetapi di saya memeriksa kode setengah jadi adalah ide yang mengerikan, titik.

Berikut adalah asas-asas yang telah saya pelajari dan coba ikuti:

• Sering-seringlah check-in - setidaknya sekali, tetapi sebaiknya berkali-kali per hari
• Hanya periksa fungsionalitas lengkapnya
• Jika konflik pertama dan kedua (mis. Butuh lebih dari satu hari untuk membuat fungsionalitas berfungsi) maka tugas terlalu besar - pecahkan menjadi tugas-tugas kecil yang dapat diselesaikan.

Ini berarti:

• Kode yang dikomentari tidak boleh diperiksa karena tidak berfungsi
• Mengomentari bukanlah strategi pengarsipan yang valid, jadi apakah itu kode yang belum selesai atau kode yang dihentikan, berkomentar dan check-in tidak masuk akal.

Singkatnya, TIDAK! Jika kode belum siap untuk melanjutkan ke tahap berikutnya (mana saja yang cocok untuk Anda: IntTest / QA / UAT / PreProd / Prod), kode tidak boleh dikomit ke trunk atau cabang multi-developer. Titik.

Sunting: Setelah membaca jawaban dan komentar lain, saya akan menambahkan bahwa menurut saya bukan ide yang baik untuk melarang kode yang dikomentari (toh tidak yakin bagaimana Anda akan menegakkannya). Apa yang akan saya katakan adalah Anda harus membuat semua orang di tim Anda setuju dengan filosofi yang saya jelaskan di atas. Tim tempat saya bekerja merangkulnya dengan sepenuh hati. Akibatnya, kontrol sumber adalah anggota tim yang tidak kaku, yang membantu kami menyelesaikan pekerjaan.

Orang yang tidak menganut filosofi itu biasanya menyebabkan jendela rusak dan sering kali dibuat frustrasi oleh kendali sumber. Mereka melihatnya sebagai kejahatan yang diperlukan, dan sesuatu yang paling buruk untuk dihindari; yang menyebabkan checkin jarang, yang berarti changeets sangat besar dan sulit untuk digabungkan, yang menambah frustrasi, membuat checkin menjadi sesuatu yang harus dihindari, dll. Hal ini pada akhirnya adalah hal sikap, bukan proses yang sebenarnya. Sangat mudah untuk memasang penghalang mental terhadapnya; mudah untuk menemukan alasan mengapa itu tidak berhasil, sama seperti mudahnya menemukan alasan untuk tidak berdiet jika Anda tidak benar-benar menginginkannya. Tetapi ketika orang benar- benar ingin melakukannya dan berkomitmen untuk mengubah kebiasaan mereka, hasilnya akan dramatis. Beban ada pada Anda untuk menjualnya secara efektif.

"Tidak pernah" jarang menjadi kata yang bagus untuk digunakan dalam pedoman.

Kolega Anda memiliki contoh yang bagus tentang kapan mungkin tepat untuk memeriksa kode yang diberi komentar: Ketika tidak lengkap dan mungkin merusak aplikasi jika check-in saat aktif.

Sebagian besar, mengomentari kode mati tidak diperlukan dalam sistem terkontrol perubahan yang dikelola dengan baik. Namun, tidak semua kode yang dikomentari "mati".

Kode yang diberi komentar tidak boleh diperiksa untuk tujuan memelihara riwayat. Itulah titik kendali sumber.

Orang-orang berbicara banyak tentang cita-cita di sini. Mungkin tidak seperti orang lain, saya harus mengerjakan banyak proyek dengan banyak interupsi dengan "dunia nyata" kadang-kadang mengganggu hari kerja saya.

Terkadang, kenyataannya adalah, saya harus check-in sebagian kode lengkap. Ini berisiko kehilangan kode atau kode check-in yang tidak lengkap. Saya tidak selalu mampu untuk "menyelesaikan" tugas, tidak peduli seberapa kecilnya. Tetapi saya tidak akan memutuskan laptop saya dari jaringan tanpa memeriksa semua kode.

Jika perlu, saya akan membuat cabang kerja saya sendiri untuk melakukan perubahan parsial.

Satu kasus di mana saya meninggalkan kode berkomentar:

// This approach doesn't work
// Blah, blah, blah

padahal itu pendekatan yang jelas untuk masalah tetapi mengandung beberapa kelemahan halus. Tentu, repositori akan memilikinya tetapi repositori tidak akan memperingatkan siapa pun di masa mendatang untuk tidak melakukan hal itu.

Saya pasti akan mengecilkan hati, dengan tegas, memeriksa kode yang diberi komentar. Saya tidak akan, bagaimanapun, secara mutlak melarangnya.Kadang-kadang (jika jarang) adalah tepat untuk memeriksa kode yang diberi komentar ke dalam kontrol sumber. Mengatakan "jangan pernah lakukan itu" terlalu membatasi.

Saya pikir kita semua setuju dengan poin-poin ini:

• Jangan pernah memeriksa kode mati ke dalam kendali sumber
• Jangan pernah memeriksa kode yang rusak (tidak berfungsi) ke dalam kontrol sumber, setidaknya tidak pernah ke trunk dan sangat jarang ke cabang pribadi, YMMV
• Jika Anda sementara mengomentari sesuatu atau merusak sesuatu untuk tujuan debugging, jangan periksa kode sampai Anda memulihkan kode ke bentuk yang benar

Beberapa di antaranya mengatakan ada kategori lain, seperti kode yang dihapus sementara , atau peningkatan tambahan tetapi tidak lengkap yang menyertakan sejumlah kecil kode yang diberi komentar sebagai dokumentasi tentang apa yang akan terjadi selanjutnya, atau cuplikan komentar yang sangat pendek (idealnya 1 baris) kode keluar yang menunjukkan sesuatu yang tidak boleh ditambahkan kembali. Kode yang dikomentari harus SELALU disertai dengan komentar yang mengatakan mengapa dikomentari (dan tidak hanya dihapus) dan memberikan perkiraan masa pakai kode yang dikomentari. Misalnya, "Kode berikut lebih merugikan daripada bermanfaat, jadi dikomentari, tetapi perlu diganti sebelum rilis XXX."

Komentar seperti di atas sesuai jika Anda mengirimkan perbaikan terbaru untuk menghentikan pendarahan pelanggan dan Anda tidak memiliki kesempatan langsung untuk menemukan perbaikan terakhir. Setelah mengirimkan hotfix, kode yang diberi komentar adalah pengingat bahwa Anda masih memiliki sesuatu yang perlu diperbaiki.

Kapan saya check-in kode komentar? Salah satu contohnya adalah ketika saya secara tentatif menghapus sesuatu yang menurut saya kemungkinan besar harus ditambahkan kembali dalam waktu dekat, dalam beberapa bentuk. Kode yang diberi komentar ada di sana untuk berfungsi sebagai pengingat langsung bahwa ini tidak lengkap. Tentu, versi lama ada dalam kontrol sumber dan Anda bisa menggunakan komentar FIXME sebagai tanda bahwa diperlukan sesuatu yang lebih. Namun, terkadang (jika tidak sering) kode adalah komentar yang lebih baik.

Juga, ketika bug diperbaiki dengan menghapus satu baris (atau lebih jarang, dua baris) kode, saya terkadang hanya mengomentari baris dengan komentar untuk tidak pernah mengaktifkan kembali kode itu dengan alasan mengapa. Komentar semacam ini jelas, langsung, dan ringkas.

Rex M berkata: 1) Hanya memeriksa fungsionalitas lengkap, 2) [Jika] tugas terlalu besar - pecahkan menjadi tugas-tugas kecil yang dapat diselesaikan.

Sebagai tanggapan: Ya, ini yang ideal. Terkadang tidak ada opsi yang dapat dicapai saat Anda mengerjakan kode produksi dan memiliki masalah mendesak yang harus segera diperbaiki. Terkadang untuk menyelesaikan tugas, Anda perlu meletakkan versi kode di lapangan untuk beberapa saat. Hal ini terutama berlaku untuk perubahan kode pengumpulan data saat Anda mencoba menemukan akar penyebab masalah.

Untuk contoh spesifik yang ditanyakan di pertanyaan yang lebih umum ... selama pengembang memeriksa kode yang diberi komentar ke dalam cabang pribadi yang tidak akan dilihat oleh siapa pun kecuali pengembang itu (dan mungkin seseorang yang berkolaborasi dengan pengembang), itu tidak membahayakan. Tetapi pengembang tersebut seharusnya (hampir) tidak pernah mengirimkan kode seperti itu ke dalam trunk atau yang setara. Batang harus selalu dibangun dan harus selalu berfungsi. Mengirim kode yang belum selesai ke trunk hampir selalu merupakan ide yang sangat buruk. Jika Anda membiarkan pengembang memeriksa kode yang belum selesai atau sementara ke dalam cabang pribadi, maka Anda harus bergantung pada pengembang untuk tidak lupa menggosok kode sebelum mengirim ke trunk.

Untuk memperjelas dalam menanggapi komentar untuk jawaban lain, jika kode dikomentari dan diperiksa, harapan saya bahwa kode akan berfungsi jika tidak diberi komentar turun dengan lamanya waktu kode telah dikomentari. Jelas, alat pemfaktoran ulang tidak akan selalu menyertakan komentar dalam pemfaktoran ulang mereka. Hampir selalu, jika saya memasukkan kode komentar ke dalam produksi, kode itu ada di sana untuk berfungsi sebagai komentar yang disempurnakan, sesuatu yang lebih spesifik daripada prosa, bahwa ada sesuatu yang perlu dilakukan di sana. Ini bukanlah sesuatu yang harus berumur panjang.

Terakhir, jika Anda dapat menemukan kode yang diberi komentar di setiap file sumber, maka ada sesuatu yang salah. Mengirimkan kode yang diberi komentar ke dalam bagasi untuk alasan apa pun harus menjadi peristiwa yang jarang terjadi. Jika ini sering terjadi, maka itu menjadi berantakan dan kehilangan nilainya.

Saya pikir kondisi tidak pernah terlalu kuat.

Saya cenderung berkomentar, check in, menjalankan tes, berpikir dan kemudian menghapus komentar setelah rilis berikutnya.

Secara umum, memeriksa kode yang diberi komentar adalah salah karena dapat menimbulkan kebingungan di antara mereka yang bukan penulis asli dan perlu membaca atau mengubah kode. Bagaimanapun, penulis asli sering kali bingung tentang kode setelah 3 bulan berlalu.

Saya mendukung keyakinan bahwa kode itu milik perusahaan, atau tim, dan bahwa Anda bertanggung jawab untuk mempermudah rekan-rekan Anda. Memeriksa kode yang diberi komentar tanpa menambahkan komentar tentang mengapa disimpan sama saja dengan mengatakan:

Saya tidak keberatan jika Anda akhirnya bingung mengapa barang ini ada di sini. Kebutuhan saya lebih penting daripada kebutuhan Anda, itulah sebabnya saya melakukan ini. Saya tidak merasa perlu untuk membenarkan kepada Anda, atau siapa pun, mengapa saya melakukan ini.

Bagi saya kode yang dikomentari biasanya dilihat sebagai tanda tidak hormat dari rekan kerja yang kurang bijaksana.

Ketika Anda perlu menambahkan fitur kecil atau perbaikan bug seperti SEKARANG, dalam 3 menit ke depan dan Anda harus memperbaiki file yang memiliki beberapa kode setengah berkembang, saya akan mengatakan tidak apa-apa, kebutuhan praktis menguasai cita-cita pragmatis di medan perang.

Saya sangat setuju dengan prinsip bahwa kode yang diberi komentar tidak boleh diperiksa. Sistem kontrol sumber adalah sumber daya bersama, dan kolega Anda, sampai batas tertentu, menggunakannya sebagai alas awal pribadinya. Ini tidak terlalu mempertimbangkan pengguna lain, terutama jika Anda berlangganan gagasan kepemilikan bersama dari basis kode.

Pengembang berikutnya yang melihat kode yang diberi komentar tidak akan tahu bahwa ini sedang dalam proses. Apakah dia bebas mengubahnya? Apakah itu kode mati? Dia tidak tahu.

Jika perubahan kolega Anda tidak dalam keadaan yang dapat diperiksa, dia harus menyelesaikannya, dan / atau belajar membuat perubahan yang lebih kecil dan bertahap.

"Memeriksa perubahan parsial yang mungkin atau mungkin tidak diterapkan" - mungkin itu juga berarti mungkin diuji atau tidak? Itu lereng licin ke basis kode yang sangat kuat.

Ini menunjukkan perbedaan mendasar dalam dua aliran pemikiran: Mereka yang hanya memeriksa kode kerja yang mereka rasa puas dan merasa layak untuk menabung, dan mereka yang memeriksa pekerjaan mereka sehingga ada kontrol revisi untuk mencegah mereka kehilangan data.

Saya akan mengkarakterisasi yang terakhir sebagai "mereka yang suka menggunakan sistem kendali revisi mereka sebagai tape backup orang miskin", tapi itu akan memberi tahu saya ke kamp mana saya berada. :-)

Dugaan saya adalah bahwa Anda dari kamp "kode yang baik", dan dia dari kamp "kode kerja".

[EDIT]

Dari komentarnya, ya saya kira benar.

Seperti yang saya katakan, saya bersama Anda, tetapi sejauh yang saya tahu ini adalah opini minoritas, baik di sini di stackoverflow dan di mana saya bekerja. Karena itu, menurut saya Anda tidak dapat benar-benar mengabadikannya dalam standar pengembangan Anda sebagai satu-satunya cara untuk beroperasi. Tidak jika Anda ingin standarnya diikuti. Satu hal yang diketahui pemimpin yang baik adalah jangan pernah memberi perintah yang mereka tahu tidak akan diikuti.

btw: Editor yang baik akan membantu mempertahankan versi lama. Misalnya, di Emacs saya menetapkan keep-old-version dan keep-old-version menjadi 10, yang menyimpan sekitar 10 penyimpanan terakhir dari file saya. Anda mungkin melihat itu sebagai cara untuk membantu argumen Anda melawan kerumunan revision-control-as-backup. Namun, Anda tidak akan pernah memenangkan perdebatan.

Dalam pengalaman saya, sakelar pengembang diberi komentar kode.

Terkadang, back-end baru dibangun secara paralel, dengan sakelar pengaktif dikomentari di kontrol sumber.

Beberapa fitur aneh yang kita butuhkan sekali di bulan biru tetapi tidak ada pelanggan yang membutuhkan sering diimplementasikan dengan cara itu. Hal-hal ini biasanya membawa risiko tinggi keamanan atau pengabaian integritas data sehingga kami tidak ingin mereka aktif di luar pengembangan. Mewajibkan pengembang yang akan menggunakannya untuk menghapus komentar kode pertama kali tampaknya merupakan cara termudah untuk mendapatkannya.

Alasan lain untuk check in dengan kode komentar:

Anda memodifikasi kode yang ada, dan menemukan bug halus, yang mudah terlewatkan, dan mungkin terlihat benar pada pandangan pertama. Komentari, letakkan perbaikan pada tempatnya, dan tambahkan komentar untuk apa yang terjadi, dan mengapa itu diubah. Periksa itu, sehingga komentar Anda tentang perbaikan ada di repositori.

Mungkin pertanyaan sebenarnya di sini adalah apakah pengembang harus diizinkan untuk memeriksa kode yang tidak lengkap?

Praktik ini tampaknya bertentangan dengan tujuan yang Anda tetapkan untuk menerapkan integrasi berkelanjutan.

Tergantung. Jika dibiarkan di sana untuk tujuan ilustrasi, mungkin. Ini mungkin berguna selama refactoring. Jika tidak, dan umumnya, tidak. Selain itu, mengomentari kode yang belum selesai pasti rawan kegagalan dan juga membuang waktu. Lebih baik ia memecah kode menjadi potongan-potongan kecil dan memeriksanya saat berfungsi.

Pandangan saya: jika pengembang bekerja di cabang mereka sendiri, atau di area kotak pasir mereka sendiri, maka mereka harus dapat memeriksa apa pun yang mereka inginkan. Ketika mereka memeriksa kode ke dalam cabang bersama (cabang fitur, atau cabang tim, atau tentu saja MAIN / trunk), kode tersebut harus semurni mungkin (tidak ada kode yang dikomentari, tidak ada lagi FIXME, dll).

Saya pikir "Tidak pernah" adalah aturan yang terlalu kuat. Saya akan memilih untuk meninggalkan beberapa kelonggaran pribadi apakah orang memeriksa kode komentar di repositori. Sasaran akhir haruslah produktivitas pembuat kode, bukan "gudang murni".

Untuk menyeimbangkan kelemahan itu, pastikan semua orang tahu bahwa kode yang diberi komentar memiliki tanggal kedaluwarsa. Siapapun diperbolehkan untuk menghapus kode yang diberi komentar jika sudah ada selama seminggu penuh dan tidak pernah aktif. (Gantikan "satu minggu" dengan apa pun yang terasa tepat bagi Anda.) Dengan begitu, Anda berhak untuk menghilangkan kekacauan saat Anda melihatnya, tanpa mencampuri terlalu langsung gaya pribadi orang.

Saya sangat setuju bahwa kode yang dikomentari tidak boleh diperiksa ke dalam repositori, untuk itulah kontrol kode sumber.

Dalam pengalaman saya ketika seorang programmer memeriksa kode yang diberi komentar, itu karena dia tidak yakin apa solusi yang tepat dan lebih senang meninggalkan solusi alternatif di sumber dengan harapan orang lain akan membuat keputusan itu.

Saya merasa itu memperumit kode dan membuatnya sulit untuk dibaca.

Saya tidak punya masalah dengan memeriksa kode setengah jadi (sehingga Anda mendapatkan manfaat dari kontrol sumber) yang tidak dipanggil oleh sistem langsung. Masalah saya adalah menemukan bagian dari kode yang diberi komentar tanpa penjelasan dilema yang mengakibatkan kode dikecualikan.

Saya pikir check-in kode komentar dalam sistem kontrol kode sumber harus dilakukan dengan sangat hati-hati, terutama jika tag bahasa yang digunakan untuk mengomentari kode tersebut ditulis oleh blok, yaitu:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Daripada secara garis individu, seperti:

// My commented code start here
// My commented code line 1
// My commented code line 2

(Anda mengerti)

Alasan saya menggunakan sangat hati-hati adalah karena bergantung pada teknologinya, Anda harus sangat berhati-hati dengan alat diff / merge yang Anda gunakan. Dengan sistem kendali kode sumber dan bahasa tertentu, alat diff / merge dapat dengan mudah dibingungkan. Perbedaan / penggabungan standar ClearCase misalnya terkenal buruk untuk menggabungkan file .xml.

Jika itu terjadi bahwa baris blok komentar tidak digabungkan dengan benar, kode Anda akan menjadi aktif di sistem ketika seharusnya tidak. Jika kodenya tidak lengkap dan merusak build, itu mungkin yang paling tidak jahat, karena Anda akan segera melihatnya.

Tetapi jika kode melewati build, itu mungkin menjadi aktif ketika seharusnya tidak ada, dan dari perspektif CM, itu bisa menjadi skenario mimpi buruk. QA umumnya menguji apa yang seharusnya ada di sana, mereka tidak menguji kode yang tidak seharusnya ada di sana, jadi kode Anda mungkin akan diproduksi sebelum Anda menyadarinya, dan pada saat itu akan disadari kode itu ada di sana ketika itu Seharusnya, biaya pemeliharaan berlipat ganda (karena "bug" akan ditemukan dalam produksi atau oleh pelanggan, tempat atau waktu terburuk yang pernah ada).

Gagasan tentang mengizinkan riwayat kendali sumber untuk mengilustrasikan "cara lama" dalam melakukan sesuatu daripada mengomentarinya dan memeriksa komentar keluar bersama dengan penjelasan adalah ide yang bagus dalam teori.

Namun, di dunia nyata, tidak ada yang pernah melihat riwayat kendali sumber pada file yang mereka kerjakan kecuali itu adalah bagian dari proses peninjauan resmi (dilakukan hanya secara berkala), atau jika ada sesuatu yang tidak berfungsi, dan pengembang tidak tahu kenapa.

Meski begitu, melihat ke belakang lebih dari 3 versi pada dasarnya tidak pernah terjadi.

Sebagian, ini karena sistem kendali sumber tidak membuat tinjauan biasa semacam ini menjadi mudah. Biasanya Anda harus memeriksa versi lama atau perbedaan dengan versi lama, Anda hanya melihat dua versi, dan tidak ada pandangan ringkas yang baik tentang apa yang berubah yang dapat memberi Anda gambaran sekilas tentang apa yang berubah.

Secara parsial, ini adalah kombinasi dari sifat manusia dan kebutuhan tim. Jika saya harus memperbaiki sesuatu, dan saya dapat memperbaikinya dalam beberapa jam, saya tidak akan menghabiskan satu jam untuk menyelidiki versi lama kode yang belum "aktif" dalam sebulan (yang, dengan setiap pengembang memeriksa sering kali, berarti kembali banyak revisi), kecuali saya kebetulan mengetahui bahwa ada sesuatu di sana (seperti jika saya ingat suatu diskusi tentang mengubah sesuatu yang berkaitan dengan apa yang saya lakukan sekarang).

Jika kode dihapus dan diperiksa kembali, maka, untuk semua maksud dan tujuan (kecuali untuk tujuan terbatas dari roll-back lengkap) itu tidak ada lagi. Ya, itu ada di sana untuk tujuan cadangan, tetapi tanpa seseorang yang berperan sebagai pustakawan kode, itu akan hilang.

Pohon kendali sumber saya pada proyek saya saat ini berusia sekitar 10 minggu, dalam tim yang hanya terdiri dari sekitar 4 insinyur, dan ada sekitar 200 daftar perubahan yang berkomitmen. Saya tahu bahwa tim saya tidak melakukan pekerjaan sebaik yang seharusnya untuk check-in segera setelah ada sesuatu yang solid dan siap digunakan. Itu membuatnya sangat sulit untuk mengandalkan membaca riwayat kode untuk setiap bagian kode untuk menangkap setiap perubahan penting.

Saat ini, saya sedang mengerjakan proyek dalam mode pengembangan awal, yang sangat berbeda dari proyek dalam mode pemeliharaan. Banyak alat yang sama digunakan di kedua lingkungan, tetapi kebutuhannya sedikit berbeda. Misalnya, sering kali ada tugas yang membutuhkan dua atau lebih insinyur untuk bekerja sama untuk membangun sesuatu (katakanlah klien dan semacam server).

Jika saya menulis server, saya mungkin menulis kode untuk rancangan antarmuka yang akan digunakan klien dan memeriksanya sama sekali tidak berfungsi, sehingga insinyur yang menulis klien dapat memperbarui. Ini karena kami memiliki kebijakan yang menyatakan bahwa satu-satunya cara untuk mengirim kode dari satu insinyur ke insinyur lainnya adalah melalui sistem kendali sumber.

Jika tugas tersebut akan memakan waktu cukup lama, akan ada gunanya membuat cabang yang mungkin untuk kita berdua kerjakan (meskipun itu bertentangan dengan kebijakan di organisasi saya - insinyur dan pemimpin tim individu tidak memiliki izin yang diperlukan pada server kendali sumber). Pada akhirnya, ini adalah trade-off, itulah sebabnya kami mencoba untuk tidak menerapkan terlalu banyak kebijakan "selalu" atau "tidak pernah".

Saya mungkin akan menanggapi kebijakan no-comment-code-ever seperti itu dengan mengatakan bahwa itu agak naif. Beritikad baik, mungkin, tetapi pada akhirnya tidak mungkin mencapai tujuannya.

Meskipun melihat posting ini akan membuat kembali melalui kode yang saya periksa minggu lalu dan menghapus bagian yang diberi komentar yang tidak pernah final (meskipun berhasil) dan juga tidak akan pernah diinginkan lagi.

Saya pikir kode yang diberi komentar dianggap "sia-sia".

Saya berasumsi Anda bekerja dalam lingkungan tim. Jika Anda bekerja sendiri, dan Anda mengomentari kode dengan 'rencana' dan Anda akan kembali ke sana, maka itu berbeda. Tetapi dalam lingkungan tim, Anda dapat dengan aman berasumsi begitu kode yang diberi komentar diperiksa, kode itu akan tetap ada dan kemungkinan besar akan menyebabkan lebih banyak rasa sakit daripada kepuasan.

Jika Anda melakukan tinjauan kode sejawat maka itu mungkin menjawab pertanyaan Anda. Jika pengembang lain meninjau kode Anda dan mengatakan "mengapa ada kode yang dikomentari ini yang mencoba melakukan 'bla'" maka kode Anda telah gagal dalam peninjauan kode dan Anda tidak boleh memeriksanya.

Kode yang dikomentari hanya akan menimbulkan pertanyaan dengan pengembang lain - oleh karena itu membuang-buang waktu dan energi.

Anda perlu mengajukan pertanyaan " mengapa " kode tersebut dikomentari. Beberapa saran:

Jika Anda mengomentari kode karena "tidak yakin dengan aturan bisnis" maka Anda mungkin memiliki masalah dengan "cakupan creep" - sebaiknya jangan mengotori basis kode Anda dengan persyaratan yang "akan menyenangkan tetapi kita tidak punya waktu untuk mengimplementasikan "- jaga kebersihannya dengan kode yang jelas dan tes seputar apa yang sebenarnya ada.

Jika Anda mengomentari kode karena "tidak yakin apakah itu cara terbaik untuk melakukannya" maka minta rekan kode Anda untuk ditinjau! Waktu berubah, Anda akan melihat kode yang Anda tulis hari ini dalam 2 tahun dan berpikir itu mengerikan! Tapi Anda tidak bisa seenaknya berkomentar tentang hal-hal yang Anda 'tahu' bisa dilakukan lebih baik tetapi Anda tidak bisa menemukan jalannya sekarang. Biarkan siapa pun yang mempertahankan basis kode jangka panjang menentukan apakah ada cara yang lebih baik - cukup dapatkan kode tertulis, diuji dan bekerja dan lanjutkan.

Jika Anda mengomentari kode karena "ada yang tidak berfungsi" maka PERBAIKI ! Skenario umum adalah "tes rusak" atau "rencana" . Jika Anda memilikinya, Anda akan menghemat banyak waktu baik dengan memperbaikinya atau hanya membuangnya. Jika bisa "dipatahkan" untuk jangka waktu tertentu, kemungkinan besar mereka bisa rusak selamanya.

Semua skenario potensial ini (dan yang belum saya sebutkan di sini) membuang-buang waktu dan tenaga. Kode yang dikomentari mungkin tampak seperti masalah kecil, tetapi bisa menjadi indikator masalah yang lebih besar di tim Anda.

Repositori adalah cadangan kode. Jika saya sedang mengerjakan kode tetapi belum selesai, mengapa tidak berkomentar dan memeriksanya di penghujung hari. Dengan cara itu jika hard drive saya mati dalam semalam, saya tidak akan kehilangan pekerjaan apa pun. Saya dapat memeriksa kode di pagi hari dengan menghapus komentar dan melanjutkan.

Satu-satunya alasan saya berkomentar adalah karena saya tidak ingin merusak bangunan dalam semalam.

Jelas ada ketegangan antara 1) check-in lebih awal, dan 2) selalu menjaga repositori dalam status kerja. Jika Anda memiliki lebih dari beberapa pengembang, yang terakhir ini akan semakin diutamakan, karena Anda tidak dapat memiliki satu pengembang yang mengalahkan semua orang untuk alur kerja pribadinya sendiri. Karena itu , Anda tidak boleh meremehkan nilai pedoman pertama. Pengembang menggunakan semua jenis tiang pagar mental yang berbeda, dan alur kerja individual adalah salah satu cara pengembang hebat memeras X ekstra tersebut. Sebagai seorang manajer, tugas Anda untuk tidak mencoba memahami semua nuansa ini — yang akan membuat Anda gagal kecuali jika Anda seorang jenius dan semua pengembang Anda idiot — melainkan memungkinkan pengembang Anda untuk menjadi yang terbaik melalui pengambilan keputusan mereka sendiri.

Anda menyebutkan di komentar bahwa Anda tidak menggunakan cabang privat. Pertanyaan saya untuk Anda adalah mengapa tidak? Oke, saya tidak tahu apa-apa tentang TFS, jadi mungkin ada alasan bagus. Namun setelah menggunakan git selama setahun, saya harus mengatakan bahwa DVCS yang baik benar-benar meredakan ketegangan ini. Ada beberapa kasus di mana saya merasa mengomentari kode berguna saat saya sedang membangun pengganti, tetapi saya akan kehilangan waktu untuk memikirkannya jika saya memaksakannya pada orang lain. Mampu bercabang secara lokal berarti saya dapat mempertahankan komitmen yang berarti untuk proses individu saya tanpa harus khawatir tentang (atau bahkan memberi tahu) pengembang hilir tentang kekacauan sementara.

Hanya menggemakan bagian chorus. Mencegah ini dengan segala cara. Itu membuat kode lebih sulit untuk dibaca dan membuat orang bertanya-tanya apa yang baik / buruk tentang kode itu yang bahkan bukan bagian dari aplikasi saat ini. Anda selalu dapat menemukan perubahan dengan membandingkan revisi. Jika ada beberapa operasi besar dan kode dikomentari secara massal, pengembang seharusnya mencatatnya dalam catatan revisi di checkin / merge.

kode tidak lengkap / eksperimental harus di cabang untuk dikembangkan sampai selesai. head / trunk harus menjadi jalur utama yang selalu dikompilasi dan merupakan pengiriman. setelah cabang percobaan selesai / diterima, cabang itu harus digabungkan menjadi head / mainline. Bahkan ada standar IEEE (IEEE 1042) yang menjelaskan ini jika Anda memerlukan dokumentasi dukungan.

Saya lebih suka melihat kode yang mungkin rusak dan dapat diakses yang belum digunakan dan belum diperiksa karena kode yang sama tidak tersedia sama sekali. Karena semua perangkat lunak kontrol versi memungkinkan semacam 'copy pekerjaan' terpisah dari trunk, lebih baik menggunakan fitur-fitur itu sebagai gantinya.

Baru, kode non-fungsional baik-baik saja di bagasi, karena baru. Itu mungkin tidak merusak apa pun yang sudah berfungsi. Jika itu merusak kode yang berfungsi, maka itu harus masuk ke cabang, sehingga pengembang lain dapat (jika mereka perlu) memeriksa cabang itu, dan melihat apa yang rusak.

" Jaringan Bekas Luka " adalah apa yang saya sebut kode komentar. Pada hari-hari sebelum meluasnya penggunaan sistem kontrol versi, Code Monkeys akan meninggalkan kode yang diberi komentar dalam file jika mereka perlu mengembalikan fungsionalitas.

Satu-satunya waktu yang dapat diterima untuk check-in "jaringan parut" adalah

1. Jika Anda memiliki cabang pribadi dan
2. Anda tidak punya waktu untuk membuat kode dikompilasi tanpa kesalahan dan
3. Anda akan berlibur panjang dan
4. Anda tidak mempercayai VCS Anda, seperti jika Anda menggunakan Visual Source Safe OR .
   [EDIT]
5. Anda memiliki bug halus yang mungkin muncul kembali jika kode yang salah tidak ditinggalkan sebagai pengingat. (poin bagus dari jawaban lain).

Hampir tidak ada alasan untuk # 4 karena ada banyak sistem VCS yang tersedia secara bebas dan kuat, Git menjadi contoh terbaik .

Jika tidak, biarkan VCS menjadi distributor arsip dan kode Anda. Jika pengembang lain ingin melihat kode Anda, kirimkan perbedaannya melalui email dan biarkan dia menerapkan hal-hal yang dia inginkan secara langsung. Bagaimanapun, penggabungan tidak peduli mengapa atau bagaimana pengkodean dua file menyimpang.

Karena ini adalah kode, jaringan parut bisa lebih mengganggu bahkan daripada komentar yang ditulis dengan baik. Pada dasarnya sebagai kode, Anda membuat programmer pemeliharaan mengeluarkan siklus cpu mental untuk mengetahui apakah jaringan parut ada hubungannya dengan perubahannya. Tidak peduli apakah bekas luka tersebut berumur seminggu atau 10 tahun, meninggalkan jaringan parut dalam kode membebani mereka yang harus menguraikan kode setelah kata sandi.

[EDIT] Saya menambahkan bahwa ada dua skenario utama yang perlu dibedakan:

• pengembangan pribadi, baik membuat kode proyek pribadi atau memeriksa ke cabang pribadi
• Pengembangan pemeliharaan, di mana kode yang diperiksa dimaksudkan untuk dimasukkan ke dalam produksi.

Katakan saja "TIDAK" pada jaringan parut!

Saya tidak tahu - Saya selalu mengomentari baris asli sebelum membuat perubahan - ini membantu saya mengembalikannya jika saya berubah pikiran. Dan ya, saya memeriksanya.

Namun saya menghapus kode komentar lama dari check-in sebelumnya.

Saya tahu saya bisa melihat log diff untuk melihat apa yang berubah tapi itu menyakitkan - senang melihat perubahan terakhir tepat di kode.

Kompromi yang bagus adalah menulis alat kecil yang membuang file yang sudah diperiksa / dimodifikasi ke drive cadangan jaringan. Dengan begitu, Anda dapat mengubah sepuasnya dan pekerjaan Anda dicadangkan, tetapi Anda tidak perlu memeriksa kode eksperimental atau yang belum selesai.

Saya pikir memeriksa kode yang diberi komentar harus valid karena, hanya karena perubahan baru lulus tes, mungkin lebih membantu untuk melihat apa yang ada sebelumnya dan melihat apakah perubahan baru benar-benar merupakan peningkatan.

Jika saya harus kembali ke beberapa versi untuk melihat perubahan sebelumnya yang sekarang mengarah ke kinerja yang terpukul maka itu akan sangat mengganggu.

Kadang-kadang kode yang dikomentari adalah sejarah yang baik, tetapi, masukkan tanggal kapan kode itu dikomentari. Nanti, seseorang yang bekerja di dekat sana tinggal menghapus kode yang dikomentari karena telah terbukti tidak diperlukan.

Baik juga untuk mengetahui siapa yang mengomentari kode tersebut sehingga jika beberapa alasan diperlukan maka mereka dapat ditanyai.

Saya lebih suka menulis fungsionalitas baru, memastikan pengujian unit lulus, memeriksanya, lalu mengizinkan orang lain untuk menggunakannya dan melihat cara kerjanya.

Jika pengembang telah mengomentari beberapa kode karena belum lengkap, maka cara "kontrol sumber" yang benar untuk mengatasinya adalah pengembang tersebut menyimpannya di cabang terpisah miliknya sendiri, sampai kode tersebut siap untuk diperiksa di.

Dengan DVCS (seperti git, bazaar, atau mercurial) ini sangat mudah karena tidak memerlukan perubahan di repositori pusat. Jika tidak, mungkin Anda dapat berbicara tentang memberi pengembang cabang mereka sendiri di server jika mereka bekerja pada fitur khusus yang akan memakan waktu cukup lama (yaitu, hari).

Tidak ada salahnya memeriksa kode yang diberi komentar dalam beberapa situasi, hanya saja ini adalah satu situasi di mana mungkin ada cara yang lebih baik untuk melakukannya, sehingga pengembang dapat melacak perubahan ke sumbernya meskipun belum siap. check in ke repositori utama.

Jelas, pengembang yang memeriksa kode yang diberi komentar harus bekerja di cabang terpisah, menggabungkan perubahan dari cabang utama sebagai hal yang diperlukan.

Terserah pada sistem VCS untuk membantu pengembang dalam alur kerja ini (git adalah salah satu sistem VCS yang sangat baik yang bekerja dengan sangat baik).