Apakah praktik yang buruk untuk tidak menghapus file berlebihan segera dari VCS tetapi tandai sebagai "Dihapus" dengan komentar terlebih dahulu?


53

Saya ingin tahu apakah cara saya menangani file sumber yang perlu dihapus dari kontrol versi dapat dianggap sebagai praktik buruk.

Saya ingin menjelaskannya kepada Anda berdasarkan contoh itu:

Saya baru-baru ini menjadi sangat marah karena saya harus memilah-milah kelas Java dalam program yang pada dasarnya mati kode tetapi tidak didokumentasikan dan juga tidak berkomentar di kelas-kelas Jawa. Tentu saja mereka perlu dihapus tetapi sebelum saya menghapus hal-hal yang berlebihan saya punya - beberapa mungkin mengatakan aneh - kebiasaan:

Saya tidak langsung menghapus file-file redundan seperti itu melalui SVN-> Delete (ganti dengan perintah delete dari sistem kontrol versi pilihan Anda) tetapi sebaliknya berikan komentar pada file-file itu (saya merujuk pada head dan footer) bahwa mereka akan dihapus + nama saya + tanggal dan juga - yang lebih penting - MENGAPA MEREKA DIHAPUS (dalam kasus saya, karena mereka sudah mati, kode membingungkan). Lalu saya simpan dan komit ke kontrol versi. Lain kali ketika saya harus melakukan / memeriksa sesuatu dalam proyek untuk kontrol versi, saya tekan SVN-> Hapus dan kemudian mereka akhirnya dihapus dalam Kontrol Versi - masih tentu saja dapat diperbaiki melalui revisi dan ini sebabnya saya mengadopsi kebiasaan itu.

Mengapa melakukan ini alih-alih menghapusnya segera?

Alasan saya adalah, bahwa saya ingin memiliki marker eksplisit setidaknya dalam revisi terakhir di mana file-file redundan itu ada, mengapa mereka pantas dihapus. Jika saya segera menghapusnya, itu dihapus tetapi tidak ada yang mendokumentasikan mengapa mereka dihapus. Saya ingin menghindari skenario seperti ini:

"Hmm ... kenapa file-file itu dihapus? Aku bekerja dengan baik sebelumnya." (Penekan 'kembalikan' -> orang yang dikembalikan kemudian hilang selamanya atau tidak tersedia dalam minggu-minggu berikutnya dan penerima tugas berikutnya harus mencari tahu dengan membosankan seperti saya tentang file-file itu)

Tetapi tidakkah Anda perhatikan mengapa file-file itu dihapus dalam pesan komit?

Tentu saja saya lakukan tetapi pesan komit terkadang tidak dibaca oleh rekan kerja. Ini bukan situasi umum ketika Anda mencoba memahami kode (dalam kasus saya mati) yang pertama kali Anda periksa log kontrol Versi dengan semua pesan komit terkait. Alih-alih merayapi log, seorang kolega dapat langsung melihat bahwa file ini tidak berguna. Ini menghemat waktu dan dia tahu bahwa file ini mungkin dipulihkan untuk yang buruk (atau setidaknya menimbulkan pertanyaan.


120
Anda pada dasarnya mencoba mereplikasi pekerjaan sistem kontrol versi Anda secara langsung dalam file. Melakukan hal seperti itu pasti akan menaikkan bendera di kepalaku. Jika kolega Anda tidak membaca pesan komit dan mereka menghidupkan kembali file yang seharusnya dihapus dan melewati pemeriksaan kode, pasti ada sesuatu yang salah di tim Anda, dan ini adalah kesempatan bagus untuk mengajar mereka dengan lebih baik.
Vincent Savard

6
@GregBurghardt Ini sepertinya pertanyaan yang bagus tentang ide yang buruk. Mungkin orang downvoting berdasarkan bagian kedua dari itu (kapan, IMO, mereka harus upvoting untuk yang pertama)?
Ben Aaronson

13
"Lain kali ketika saya harus melakukan / memeriksa sesuatu dalam proyek untuk kontrol versi, saya tekan SVN-> Hapus" Apakah Anda mengatakan Anda menghapusnya dalam (berpotensi) komitmen yang sama sekali tidak terkait?
Kevin

21
Tentu saja saya lakukan tetapi pesan komit terkadang tidak dibaca oleh rekan kerja. - jika mereka tidak memeriksa pesan komit, aman untuk menganggap mereka tidak tertarik mengapa file itu dihapus ... kalau tidak mereka harus memeriksa pesan komit.
Semut P

9
Jika saya ingin tahu mengapa file menghilang dari checkout VCS saya, saya akan mencari di riwayat perubahan terlebih dahulu , dan jika itu tidak menjelaskan banyak hal, saya akan membaca diskusi yang terjadi ketika penghapusan ditinjau. (Jika Anda tidak memiliki proses peninjauan kode yang harus dilakukan setiap perubahan, Anda memiliki masalah yang lebih besar.) Dan jika itu masih belum jelas, saya akan berbicara dengan siapa pun yang menghapus file tersebut. Saya mungkin melihat isi file sebelumnya untuk mencoba menemukan apa yang biasa dilakukan, tetapi tidak untuk penjelasan tentang penghapusan.
zwol

Jawaban:


110

Masalah dengan menambahkan komentar ke file yang harus dihapus, alih-alih menghapusnya dalam kontrol sumber dan meletakkan penjelasan di sana, adalah asumsi bahwa jika pengembang tidak membaca pesan komit, mereka pasti akan membaca komentar dalam kode sumber.

Dari perspektif orang luar, metodologi ini tampaknya berakar pada pandangan yang sangat konservatif tentang kontrol sumber.

"Bagaimana jika saya menghapus file yang tidak digunakan ini dan kemudian seseorang membutuhkannya?" seseorang mungkin bertanya.

Anda menggunakan kontrol sumber. Kembalikan perubahan, atau lebih baik bicarakan dengan orang yang menghapus file (berkomunikasi).

"Bagaimana jika saya menghapus file yang mati, lalu seseorang mulai menggunakannya lagi dan mereka membuat perubahan?" orang lain mungkin bertanya.

Sekali lagi, Anda menggunakan kontrol sumber. Anda akan mendapatkan konflik gabungan yang harus diselesaikan seseorang. Jawabannya di sini, seperti pertanyaan terakhir, adalah berkomunikasi dengan rekan satu tim Anda.

Jika Anda benar-benar ragu file harus dihapus, komunikasikan sebelum menghapusnya dari kontrol sumber. Mungkin ini baru saja berhenti digunakan, tetapi fitur yang akan datang mungkin membutuhkannya. Anda tidak tahu itu, tetapi salah satu pengembang lain mungkin.

Jika harus dihapus, hapus. Potong lemak dari basis kode.

Jika Anda membuat "oopsi" dan Anda benar-benar membutuhkan file tersebut, ingatlah bahwa Anda menggunakan kontrol sumber sehingga Anda dapat memulihkan file tersebut.

Vincent Savard, dalam komentar pada pertanyaan itu, mengatakan:

... Jika kolega Anda tidak membaca pesan komit dan mereka menghidupkan kembali file yang dihapus dengan benar dan melewati peninjauan kode, pasti ada sesuatu yang salah di tim Anda, dan ini merupakan kesempatan bagus untuk mengajar mereka lebih baik.

Ini saran yang bagus. Ulasan kode harus menangkap hal semacam ini. Pengembang harus berkonsultasi pesan komit ketika perubahan tak terduga dilakukan pada file, atau file dihapus atau diganti namanya.

Jika pesan komit tidak menceritakan kisahnya, maka pengembang juga harus menulis pesan komit yang lebih baik.

Ketakutan untuk menghapus kode atau menghapus file merupakan indikasi masalah sistemik yang lebih dalam dengan proses:

  • Kurangnya ulasan kode yang akurat
  • Kurangnya pemahaman tentang cara kerja kontrol sumber
  • Kurangnya komunikasi tim
  • Pesan komit yang buruk di pihak pengembang

Ini adalah masalah yang harus diatasi, jadi Anda tidak merasa seperti sedang melempar batu di rumah kaca ketika Anda menghapus kode atau file.


3
"Asumsikan bahwa jika pengembang tidak membaca pesan komit, mereka pasti akan membaca komentar dalam kode sumber." Saya pikir ini asumsi yang cukup bagus. Pengembang yang mengubah file harus benar-benar melihat file untuk menyelesaikan tugas, sementara tidak ada yang memaksa seseorang untuk melihat riwayat kontrol sumber.
AShelly

7
@ AShelly: tugas pengembang jarang mengubah komentar. Tugas melibatkan perubahan kode, yang menjadi fokus pengembang - bukan komentar.
Greg Burghardt

21
@ AShelly Hanya karena mereka harus membuka file bukan berarti mereka akan membaca komentar tertentu di bagian atas. Target audiens untuk perubahan ini adalah jenis pengembang yang paling tidak sadar, jenis yang berpikir kebutuhan mereka adalah satu-satunya kebutuhan dan semuanya harus berputar di sekitar mereka. Ini tidak mungkin untuk membaca komentar sopan Anda. Lebih buruk lagi, mereka cenderung membacanya, dan kemudian kembali ke versi tertua berikutnya.
Cort Ammon

5
@ Ashelly - sebagai contoh saya biasanya membuka file ke suatu lokasi. Dalam VS saya dapat membuka langsung ke metode menggunakan dropdown di bagian atas atau menu konteks "pergi ke definisi". Saya tidak akan pernah melihat bagian atas file. Juga di Sublime Text, saya sering membuka ke baris dialog terbuka mereka users.rb: 123 akan membuka users.rb langsung ke baris 123. Banyak editor kode memiliki opsi yang sangat mirip.
coteyr

2
Selain hal di atas, semakin kompleks untuk melakukan tugas pembersihan seperti ini, semakin kecil kemungkinan orang melakukannya secara teratur. Jika Anda bisa melakukannya dengan lebih sederhana, ini akan menurunkan "energi aktivasi" untuk Anda dan semua orang. Ini sangat penting jika Anda mencoba mendorong perubahan praktik untuk anggota tim lainnya. Semakin kompleks prosedurnya, semakin sulit untuk diterima.
xdhmoore

105

Ya itu praktik yang buruk.

Anda harus memasukkan penjelasan untuk penghapusan dalam pesan komit ketika Anda melakukan penghapusan file.

Komentar dalam file sumber harus menjelaskan kode seperti yang terlihat saat ini . Pesan komit harus menjelaskan mengapa perubahan dalam komit dibuat, sehingga riwayat komit pada file menjelaskan sejarahnya.

Menulis komentar yang menjelaskan perubahan secara langsung di sumber itu sendiri hanya akan membuat kode lebih sulit untuk diikuti. Pikirkan tentang hal ini: Jika Anda berkomentar dalam file setiap kali Anda mengubah atau menghapus kode, segera file akan dibanjiri dengan komentar tentang sejarah perubahan.


6
Mungkin tambahkan jawaban untuk pertanyaan: Apakah ini praktik yang buruk? Ya, karena ....
Juan Carlos Coto

1
Saya terkadang melakukan hal yang sama (seperti OP) karena lebih mudah untuk membatalkan komentar daripada mengembalikan. Dalam kasus yang jarang terjadi meskipun kode mengkompilasi dan lulus pengujian otomatis, ada alasan untuk keberadaan kode yang saya abaikan bahwa penguji manual akan melihat. Dalam skenario yang jarang terjadi ini, alih-alih melalui rasa sakit yang hebat atau mengembalikan hal-hal yang dilakukan beberapa kali kemudian, saya hanya menghilangkan tanda komentar pada kode itu kembali (dan meninjau kembali bagaimana kode itu dapat ditingkatkan)
Andrew Savinykh

2
@AndrewSavinykh Itu berbeda, Anda berkomentar kode Anda masih tidak yakin ingin menghapus.
Goyo

6
@AndrewSavinykh “sakit besar atau mengembalikan beberapa hal kemudian” - Saya bertanya-tanya versi kontrol apa yang Anda gunakan; ini seharusnya tidak menjadi sakit besar. Ini tentu saja tidak ada di Git, setidaknya tidak setelah Anda melakukannya beberapa kali dan belajar apa yang harus diwaspadai ... dan asalkan sejarah Anda tidak dipenuhi dengan komitmen bolak-balik yang tidak perlu yang memberi Anda konflik setiap penggabungan lainnya. Dan melakukan yang hanya berkomentar sesuatu agak cenderung untuk melakukan ini ...
leftaroundabout

4
@AndrewSavinykh ya, dan tidak seperti saya tidak mengalami masalah ini - proyek yang pengelolanya tidak pernah benar-benar bekerja dengan kontrol versi dan memasukkan banyak info dalam komentar yang seharusnya benar-benar melakukan pesan, alih-alih menambahkan manual-undo-commit baru sebagai gantinya mengembalikan dengan benar, dll. Keadaan repositori yang dihasilkan membuat banyak konflik menjadi menyenangkan di setiap rebase yang lebih besar ... Tapi, dan itulah poin saya, masalah ini sering kali sebagian besar disebabkan oleh penyelesaian seperti yang Anda pertahankan di sini.
leftaroundabout

15

Menurut pendapat saya, kedua pilihan Anda bukanlah praktik terbaik , dan bukan praktik buruk :

  1. Menambahkan komentar hanya menambah nilai apa pun jika seseorang kebetulan membaca komentar itu.
  2. Cukup menghapus dari VCS, (dengan alasan dalam deskripsi perubahan), dapat berdampak pada pengiriman kritis dan banyak orang tidak membaca deskripsi perubahan, terutama ketika berada di bawah tekanan.

Praktek favorit saya - sebagian besar karena telah digigit beberapa kali selama bertahun-tahun, mengingat bahwa Anda tidak selalu tahu di mana atau oleh siapa kode Anda digunakan - adalah untuk:

  1. Tambahkan komentar yang menyatakan bahwa itu adalah kandidat untuk penghapusan dan penghentian #warning atau serupa, (sebagian besar bahasa memiliki semacam mekanisme seperti itu, misalnya di Jawa , dalam kasus terburuk printpernyataan atau kemauan yang sama sudah cukup), idealnya dengan semacam skala waktu dan dengan detail kontak. Ini akan memberi tahu siapa pun yang masih menggunakan kode itu. Peringatan ini biasanya di dalam setiap fungsi atau kelas jika hal-hal seperti itu ada .
  2. Setelah beberapa waktu perbarui peringatan ke lingkup file standar #warning(beberapa orang mengabaikan peringatan penghentian dan beberapa rantai alat tidak menampilkan peringatan seperti itu secara default).
  3. Nanti ganti lingkup file #warningdengan #erroratau yang setara - ini akan merusak kode pada waktu membangun tetapi dapat, jika benar-benar perlu dihapus tetapi orang yang menghapusnya tidak dapat mengabaikannya. (Beberapa pengembang tidak membaca atau mengatasi peringatan apa pun atau memiliki begitu banyak sehingga mereka tidak dapat memisahkan yang penting).
  4. Terakhir, tandai file tersebut, (pada atau setelah tanggal jatuh tempo), sebagaimana dihapus dalam VCS.
  5. Jika menghapus seluruh paket / perpustakaan / dll pada tahap peringatan saya akan menambahkan README.txt atau README.html atau serupa dengan informasi kapan & mengapa itu direncanakan untuk menyingkirkan paket dan meninggalkan hanya file itu, dengan ubah untuk mengatakan kapan dihapus, sebagai satu-satunya konten paket untuk beberapa waktu setelah menghapus sisa konten.

Salah satu keuntungan dari pendekatan ini adalah bahwa beberapa sistem versi (CVS, PVCS, dll.) Tidak akan menghapus file yang ada pada checkout jika telah dihapus di VCS. Ini juga memberi pengembang sadar, mereka yang memperbaiki semua peringatan mereka, banyak waktu untuk mengatasi masalah ini atau mengajukan banding atas penghapusan. Ini juga memaksa pengembang yang tersisa untuk setidaknya melihat pemberitahuan penghapusan dan banyak mengeluh .

Perhatikan bahwa #warning/ #erroradalah mekanisme C / C ++ yang menyebabkan peringatan / kesalahan diikuti oleh teks yang disediakan ketika kompiler menemukan kode itu, java / java-doc memiliki @Deprecatedcatatan untuk mengeluarkan peringatan pada penggunaan & @deprecateduntuk memberikan beberapa informasi, dll. Ada resep untuk melakukan hal yang sama dengan python & saya telah melihat assertdigunakan untuk memberikan informasi serupa #errordi dunia nyata.


7
Secara khusus, karena pertanyaan ini menyebutkan Java, gunakan @deprecatedkomentar JavaDoc dan @Deprecatedanotasi .
200_sukses

8
Ini sepertinya lebih tepat ketika Anda ingin menyingkirkan sesuatu yang masih digunakan. Peringatan dapat bertahan sampai semua penggunaan hilang, tetapi begitu kode mati, harus segera dihapus.
Andy

6
@Andy Salah satu masalah dengan kode jenis pustaka, terutama di Open Source atau di organisasi besar, adalah Anda mungkin berpikir kode itu mati tetapi ternyata digunakan secara aktif di satu, atau lebih, tempat-tempat yang secara pribadi tidak pernah Anda bayangkan. yang digunakan. Kadang-kadang kode perlu dimatikan, karena benar-benar buruk atau termasuk risiko keamanan, tetapi Anda tidak tahu apakah & di mana itu digunakan.
Steve Barnes

1
@ 200_success terima kasih - latar belakang saya di C / C ++ yang ditampilkan - ditambahkan ke jawabannya.
Steve Barnes

1
@ SveveBarnes Mungkin tapi bukan itu yang ditanyakan OP. Dia memverifikasi bahwa kodenya sudah mati.
Andy

3

Ya, saya akan mengatakan itu praktik yang buruk, tetapi bukan karena itu ada di file versus di pesan komit. Masalahnya adalah Anda mencoba melakukan perubahan tanpa berkomunikasi dengan tim Anda.

Setiap kali Anda membuat perubahan pada trunk - menambah, menghapus, atau memodifikasi file dengan cara apa pun - Anda harus, sebelum Anda berkomitmen kembali ke trunk, bicarakan perubahan itu langsung dengan anggota (atau anggota) dari tim yang akan secara langsung memiliki pengetahuan tentang mereka (pada dasarnya, diskusikan apa yang akan Anda masukkan ke header secara langsung dengan rekan tim Anda). Ini akan memastikan bahwa (1) kode yang Anda hapus benar-benar perlu dihapus, dan bahwa (2) tim Anda akan lebih mungkin mengetahui bahwa kode itu dihapus dan dengan demikian tidak mencoba mengembalikan penghapusan Anda. Belum lagi Anda juga akan mendapatkan deteksi bug dan sejenisnya untuk kode yang Anda tambahkan.

Tentu saja, ketika Anda mengubah hal-hal besar, Anda juga harus memasukkannya ke dalam pesan commit, tetapi karena Anda sudah membahasnya, itu tidak perlu menjadi sumber pengumuman penting. Jawaban Steve Barnes juga membahas beberapa strategi yang baik untuk digunakan jika kelompok potensial pengguna untuk kode Anda terlalu besar (mis. Menggunakan penanda Deprecated bahasa Anda alih-alih menghapus file pada awalnya).

Jika Anda tidak ingin selama itu tanpa melakukan (yaitu perubahan Anda paling masuk akal karena beberapa revisi), itu ide yang baik untuk membuat cabang dari batang dan komit ke cabang, kemudian menggabungkan cabang kembali ke bagasi ketika perubahan sudah siap. Dengan begitu, VCS masih mencadangkan file untuk Anda, tetapi perubahan Anda tidak memengaruhi bagasi.


1

Masalah terkait dari proyek yang dibangun di berbagai platform dan konfigurasi. Hanya karena saya menentukan bahwa itu sudah mati tidak berarti itu adalah tekad yang benar. Perhatikan bahwa mati digunakan mungkin masih berarti ketergantungan yang masih perlu disingkirkan, dan beberapa mungkin telah terjawab.

Jadi (dalam proyek C ++) saya menambahkan

#error this is not as dead as I thought it was

Dan memeriksanya. Tunggu hingga bisa membangun kembali semua platform normal dan tidak ada yang mengeluh tentang hal itu. Jika seseorang menemukannya, akan mudah untuk menghapus satu baris dan bukannya bingung dengan file yang hilang.

Saya setuju pada prinsipnya bahwa komentar yang Anda sebutkan menduplikasi fitur yang harus dilakukan dalam sistem manajemen versi . Tapi, Anda mungkin punya alasan khusus untuk mendukung itu. Tidak mengetahui alat VCS bukan salah satunya.


-1

Pada rangkaian Praktik Buruk, ini cukup kecil. Saya akan melakukan ini sesekali, ketika saya ingin memeriksa cabang dan dapat melihat kode lama. Ini dapat memudahkan perbandingan dengan kode pengganti. Saya biasanya mendapat komentar kode review "cruft". Dengan sedikit penjelasan saya lulus ulasan kode.

Tapi kode ini seharusnya tidak hidup lama. Saya biasanya menghapus di awal sprint berikutnya.

Jika Anda memiliki rekan kerja yang tidak membaca pesan komit atau tidak akan bertanya mengapa Anda meninggalkan kode dalam proyek, maka masalah Anda bukan salah satu gaya pengkodean yang buruk. Anda memiliki masalah yang berbeda.


ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 6 jawaban sebelumnya
nyamuk

-3

Anda juga dapat memperbarui kelas dan mengganti nama dengan awalan ke UNUSED_Classname sebelum Anda menarik aksi Anda. Maka Anda harus langsung melakukan operasi penghapusan juga

  • Langkah 1: ganti nama kelas, tambahkan komentar Anda, komit
  • Langkah 2: hapus file dan komit

Jika itu kode mati, hapus itu. Siapa pun yang membutuhkannya, mereka dapat kembali, tetapi langkah mengubah nama akan mencegah mereka menggunakannya secara langsung tanpa berpikir.

Juga ajarkan orang-orang cara melihat semua pesan yang dikomit untuk suatu file, beberapa orang bahkan tidak tahu itu mungkin.


6
"Refactoring" tidak benar-benar berarti apa yang Anda pikirkan
Nik Kyriakides

6
Tidak perlu mengganti nama kelas / metode untuk memastikan itu tidak digunakan, menghapusnya juga berfungsi. Sebaliknya prosedurnya sama dengan perubahan lain: 1) hapus kode mati , 2) jalankan tes , 3) jika lulus, komit dengan komentar .
Schwern

1
@ user275398 Saya juga berpikir mengubah nama file terlalu banyak. Dan juga dari sudut pandang teknologi, SVN memperlakukan pengubahan nama seperti file akan dihapus dan dibuat dengan nama baru, sehingga Anda memiliki jeda dalam sejarah. Jika Anda ingin mengembalikan file yang diganti namanya dan melihat log SVN-nya, riwayat sebelum penggantian nama tidak tersedia. Untuk ini, Anda harus mengembalikan file dengan nama lama. Refactoring adalah sesuatu yang lain, refactoring adalah mengatur kode yang ada ke dalam struktur baru.
Bruder Lustig

@ BruderLustig: Perangkat lunak yang baik tentu tidak akan melakukannya. Git memiliki git mv, yang melacak sejarah. Mercurial juga memiliki hg mv. Sepertinya svn moveharus bekerja untuk SVN juga?
wchargin

@wchargin Tidak, git mvhanya memindahkan file dan tahapan penghapusan file dan pembuatan file. Semua pelacakan gerakan terjadi ketika Anda menjalankan git log --followdan yang serupa. gittidak memiliki cara melacak nama, itu sebenarnya tidak melacak perubahan sama sekali; itu malah melacak negara pada saat melakukan dan menemukan apa yang telah berubah pada saat Anda memeriksa sejarah.
maaartinus
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.