Cakupan kode menyoroti metode yang tidak digunakan - apa yang harus saya lakukan?


59

Saya telah ditugaskan untuk meningkatkan cakupan kode proyek Java yang ada.

Saya perhatikan bahwa alat cakupan kode ( EclEmma ) telah menyoroti beberapa metode yang tidak pernah dipanggil dari mana pun.

Reaksi awal saya bukan menulis unit test untuk metode ini, tetapi untuk menyoroti mereka ke manajer lini saya / tim dan bertanya mengapa fungsi-fungsi ini ada untuk memulai.

Apa yang akan menjadi pendekatan terbaik? Tulis unit test untuk mereka, atau tanyakan mengapa mereka ada di sana?


1
Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
maple_shaft

Jawaban:


118
  1. Menghapus.
  2. Melakukan.
  3. Lupa.

Alasan:

  1. Kode mati sudah mati. Dengan deskripsinya itu tidak memiliki tujuan. Mungkin ada tujuan pada satu titik, tetapi itu hilang, dan kode harus hilang.
  2. Kontrol versi memastikan bahwa dalam (dalam pengalaman saya) peristiwa unik yang jarang terjadi ketika seseorang mencari kode itu dapat diambil kembali.
  3. Sebagai efek samping, Anda langsung meningkatkan jangkauan kode tanpa melakukan apa pun (kecuali kode mati diuji, yang jarang terjadi).

Peringatan dari komentar: Jawaban semula mengasumsikan bahwa Anda telah memverifikasi dengan seksama bahwa kode, sudah pasti, mati. IDE bisa keliru, dan ada beberapa cara kode yang terlihat mati sebenarnya bisa disebut. Bawa ahli kecuali Anda benar-benar yakin.


118
Secara umum saya akan setuju dengan pendekatan ini, tetapi jika Anda baru mengenal suatu proyek dan / atau pengembang junior, lebih baik tanyakan pada mentor / atasan Anda sebelum menghapus. Tergantung pada proyek beberapa metode mungkin tidak terlihat digunakan tetapi dipanggil / digunakan oleh kode luar tidak dalam kode proyek Anda memiliki akses ke. Ini mungkin kode autogenerated sehingga penghapusan Anda tidak akan menghasilkan apa-apa selain kebisingan riwayat log. IDE Anda mungkin tidak dapat menemukan akses berbasis refleksi dari dalam proyek. Dll. Hal. Jika Anda tidak yakin tentang kasus sudut tersebut setidaknya tanyakan sekali.
Frank Hopkins

11
Meskipun saya setuju dengan inti dari jawaban ini, pertanyaan literalnya adalah "haruskah saya mempertanyakan mengapa mereka ada di sana?" . Jawaban ini mungkin memberi kesan OP seharusnya tidak bertanya kepada tim mereka sebelum menghapus.
Doc Brown

58
Saya akan menambahkan langkah pertama - periksa log git menyalahkan untuk baris kode yang tidak digunakan. Jika Anda dapat menemukan orang yang menulisnya, Anda dapat menanyakan untuk apa itu. Jika jalurnya baru maka ada peluang bagus seseorang berencana untuk menggunakannya segera (dalam hal ini mereka mungkin harus diuji unit sekarang).
bdsl

10
Ada banyak hal yang salah dengan jawaban ini, seperti yang diungkapkan dalam komentar atau jawaban lain, yang saya tidak percaya ini adalah jawaban yang dipilih dan diterima.
user949300

11
@Emory Cara terbaik untuk memulai dalam tim baru adalah menghancurkan bangunan dengan menghapus hal-hal secara sembrono karena Anda pikir tidak ada yang membutuhkannya. Jaminan bahwa Anda populer mulai hari pertama. Tentu itu mungkin tidak diperlukan (karena setiap aplikasi besar yang lebih lama selalu memiliki batuk cakupan kode 100% ), tapi itu ROI yang sangat buruk.
Voo

55

Semua jawaban lain didasarkan pada asumsi bahwa metode yang dimaksud benar-benar tidak digunakan. Namun, pertanyaannya tidak menentukan apakah proyek ini mandiri atau semacam perpustakaan.

Jika proyek tersebut adalah perpustakaan, metode yang tampaknya tidak digunakan dapat digunakan di luar proyek dan menghapusnya akan merusak proyek-proyek lainnya. Jika perpustakaan itu sendiri dijual kepada pelanggan atau disediakan untuk umum, mungkin bahkan tidak mungkin untuk melacak penggunaan metode ini.

Dalam hal ini, ada empat kemungkinan:

  • Jika metode ini bersifat pribadi atau paket-pribadi, metode tersebut dapat dihapus dengan aman.
  • Jika metode ini bersifat publik, keberadaannya dapat dibenarkan bahkan tanpa penggunaan yang sebenarnya, untuk kelengkapan fitur. Mereka harus diuji.
  • Jika metode bersifat publik dan tidak dibutuhkan, menghapusnya akan menjadi perubahan besar dan jika perpustakaan mengikuti versi semantik , ini hanya diperbolehkan dalam versi utama baru.
  • Atau, metode publik juga dapat ditinggalkan dan dihapus nanti. Ini memberi waktu bagi konsumen API untuk beralih dari fungsi yang tidak digunakan sebelum dihapus di versi utama berikutnya.

9
Ditambah lagi jika itu adalah perpustakaan, fungsinya ada untuk kelengkapannya
PlasmaHH

Bisakah Anda menguraikan bagaimana mereka harus diuji? Jika Anda tidak tahu mengapa metode ini ada, Anda mungkin tidak tahu apa yang harus dilakukan.
Tidak U

Nama-nama metode seperti filter_name_exists, ReloadSettingsatau addToSchema(dipilih secara acak dari 3 proyek open source sewenang-wenang) harus memberikan beberapa petunjuk tentang apa yang seharusnya dilakukan oleh metode tersebut. Komentar javadoc mungkin lebih bermanfaat. Bukan spesifikasi yang tepat, saya tahu, tetapi bisa cukup untuk membuat beberapa tes yang dapat mencegah regresi setidaknya.
Zoltan

1
metode publik pada kelas atau antarmuka pribadi tidak boleh dianggap publik untuk tujuan ini. sama halnya jika kelas publik bersarang di dalam kelas privat, itu tidak benar-benar publik.
emory

30

Pertama periksa apakah alat jangkauan kode Anda sudah benar.

Saya memiliki situasi di mana mereka belum mengambil metode yang dipanggil melalui referensi ke antarmuka, atau jika kelas dimuat secara dinamis di suatu tempat.


Terima kasih, akan lakukan. Di Eclipse, saya melakukan pencarian pada basis kode untuk fungsi, dan tidak ada yang muncul. Jika Anda memiliki saran lain tentang cara melakukan pencarian yang lebih komprehensif, saya akan sangat berterima kasih.
Lucas T

3
ya, Anda harus memeriksa proyek lain yang mungkin mengimpor kelas sebagai dll
Ewan

7
Jawaban ini terasa tidak lengkap. "Pertama, periksa apakah alat cakupan kode Anda sudah benar. Jika benar, maka .... [masukkan jawaban lain] ". Secara khusus, OP ingin tahu apa yang harus dilakukan jika alat cakupan kode sudah benar.
Jon Bentley

1
@jonbentley OP meminta pendekatan terbaik untuk laporan alat. "Periksa secara manual" karena cukup jelas dari konteksnya yang salah
Ewan

15

Karena Java dikompilasi secara statis, itu seharusnya cukup aman untuk menghapus metode. Menghapus kode mati selalu baik. Ada beberapa kemungkinan bahwa ada beberapa sistem refleksi gila yang menjalankannya dalam runtime, jadi tanyakan terlebih dahulu dengan pengembang lain, tetapi jika tidak hapuslah.


9
+1 untuk memeriksa dengan orang-orang, agak mengikuti prinsip paling tidak mengejutkan. Anda tidak ingin seseorang menghabiskan terlalu banyak waktu untuk mencari metode yang baru saja ditinggalkan di sana beberapa komitmen sebelumnya. Juga, dalam beberapa kasus tepi, kode mati mungkin merupakan hal baru yang sudah diperiksa tetapi belum disambungkan ke mana pun (meskipun dalam kasus ini, kode tersebut harus didokumentasikan dengan baik dengan komentar, dan diuji).
Frax

4
Yah kecuali jika kode menggunakan refleksi untuk memanggil metode "tidak digunakan", tetapi dalam kasus itu Anda memiliki masalah yang jauh lebih besar, dan kami berharap untuk melihat kode di thefailywft.com (Lakukan tes cepat untuk melihat apakah ada kode yang melakukan ClassName. kelas).
MTilsted

2
Ini dikompilasi secara statis, tetapi ada juga invokedynamicinstruksinya, jadi, Anda tahu ...
corsiKa

@MTilsted: Ada banyak kerangka kerja yang akan memanggil kode dengan menggunakan string - saya bisa memikirkan setidaknya Spring dan Hibernate dari atas kepala saya.
jhominal

9

Apa yang akan menjadi pendekatan terbaik? Tulis unit test untuk mereka, atau tanyakan mengapa mereka ada di sana?

Menghapus kode adalah hal yang baik.

Ketika Anda tidak dapat menghapus kode, Anda tentu dapat menandainya sebagai @Deprecated , mendokumentasikan rilis utama yang Anda targetkan untuk menghapus metode ini. Kemudian Anda dapat menghapusnya "nanti". Sementara itu, akan jelas bahwa tidak ada kode baru yang ditambahkan tergantung padanya.

Saya tidak akan merekomendasikan berinvestasi dalam metode yang sudah usang - jadi tidak ada pengujian unit baru untuk mencapai target cakupan.

Perbedaan antara keduanya terutama apakah metode tersebut merupakan bagian dari antarmuka yang diterbitkan . Menghapus bagian antarmuka yang diterbitkan secara sewenang-wenang dapat menjadi kejutan yang tidak menyenangkan bagi konsumen yang bergantung pada antarmuka.

Saya tidak dapat berbicara dengan EclEmma, ​​tetapi dari pengalaman saya, salah satu hal yang perlu Anda perhatikan adalah refleksi. Jika, misalnya, Anda menggunakan file konfigurasi teks untuk memilih kelas / metode mana yang akan diakses, perbedaan yang digunakan / tidak digunakan mungkin tidak jelas (saya telah dibakar oleh itu beberapa kali).

Jika proyek Anda adalah daun dalam grafik dependensi, maka kasus penghentian melemah. Jika proyek Anda adalah pustaka, maka kasus penghinaan lebih kuat.

Jika perusahaan Anda menggunakan mono-repo , maka menghapus lebih rendah risikonya daripada dalam kasus multi-repo.

Seperti dicatat oleh l0b0 , jika metode sudah tersedia dalam kontrol sumber, memulihkannya setelah penghapusan adalah latihan langsung ke depan. Jika Anda benar-benar khawatir perlu melakukan itu, pikirkan bagaimana mengatur komit Anda sehingga Anda dapat memulihkan perubahan yang dihapus jika Anda membutuhkannya.

Jika ketidakpastiannya cukup tinggi, Anda dapat mempertimbangkan untuk mengomentari kodenya , daripada menghapusnya. Ini adalah pekerjaan tambahan di jalur bahagia (di mana kode yang dihapus tidak pernah dipulihkan), tetapi itu membuatnya lebih mudah untuk dipulihkan. Dugaan saya adalah bahwa Anda harus memilih penghapusan langsung sampai Anda telah dibakar beberapa kali, yang akan memberi Anda wawasan tentang cara mengevaluasi "ketidakpastian" dalam konteks ini.

pertanyaan mengapa mereka ada di sana?

Waktu yang diinvestasikan untuk menangkap pengetahuan tidak selalu sia-sia. Saya diketahui melakukan penghapusan dalam dua langkah - pertama, dengan menambahkan dan melakukan komentar yang menjelaskan apa yang telah kami pelajari tentang kode, dan kemudian menghapus kode (dan komentar).

Anda juga bisa menggunakan sesuatu yang analog dengan catatan keputusan arsitektural sebagai cara untuk menangkap pengetahuan dengan kode sumber.


9

Alat cakupan kode tidak maha tahu, maha melihat. Hanya karena alat Anda mengklaim bahwa metode ini tidak dipanggil, itu tidak berarti itu tidak dipanggil. Ada refleksi, dan tergantung pada bahasanya mungkin ada cara lain untuk memanggil metode. Di C atau C ++ mungkin ada makro yang membangun fungsi atau nama metode, dan alat mungkin tidak melihat panggilan. Jadi langkah pertama adalah: Lakukan pencarian teks untuk nama metode, dan nama terkait. Tanyakan rekan yang berpengalaman. Anda mungkin menemukan itu benar-benar digunakan.

Jika Anda tidak yakin, letakkan assert () di awal setiap metode "yang tidak digunakan". Mungkin dipanggil. Atau pernyataan logging.

Mungkin kodenya sebenarnya berharga. Ini mungkin kode baru yang sudah dikerjakan seorang rekan selama dua minggu, dan dia akan menghidupkannya besok. Itu tidak dipanggil hari ini karena panggilan itu akan ditambahkan besok.

Mungkin kodenya sebenarnya berharga bagian 2: Kodenya mungkin melakukan beberapa tes runtime yang sangat mahal yang dapat menemukan kesalahan. Kode hanya dihidupkan jika ada yang salah. Anda mungkin menghapus alat debugging yang berharga.

Menariknya, saran terburuk yang mungkin "Hapus. Berkomitmen. Lupakan." adalah nilai tertinggi. (Ulasan kode? Anda tidak melakukan tinjauan kode? Apa yang Anda lakukan pemrograman jika Anda tidak melakukan tinjauan kode?)


Saya dengan hormat tidak setuju tentang "HAPUS. KOMIT. LUPAKAN" menjadi saran terburuk. (Saya pikir itu yang terbaik.). Pendekatan Anda juga oke. Saya pikir saran terburuk adalah menulis unit test yang menggunakan "kode mati" tetapi tidak membuat pernyataan. Alat jangkauan kode akan tertipu dengan berpikir mereka digunakan.
emory

3
Tidak ada dalam jawaban "Hapus. Komit. Lupa" yang mengatakan tidak melakukan peninjauan kode. Sangat mungkin (dan disarankan, IMHO) untuk meninjau kode setelah dilakukan (tetapi sebelum penempatan :-)).
sleske

@sleske Bagaimana Anda meninjau kode yang tidak ada lagi? Jawaban itu juga tidak menyebutkan "ulasan".
user949300

@ user949300: Apakah atau tidak perubahan kode perlu ditinjau atau tidak adalah pertanyaan yang terpisah, dan terlepas dari apakah kode ditambahkan, diubah atau dihapus (menambahkan kode bisa lebih berbahaya daripada menghapusnya, lihat misalnya kerentanan Heartbleed). Plus, jawabannya (sekarang) mengatakan untuk "membawa ahli", yang kedengarannya cukup dekat dengan tinjauan kode.
sleske

1
@ user949300: Mengenai "Bagaimana Anda meninjau kode yang sudah tidak ada lagi" - Saya harap itu sudah jelas: Dengan melihat perubahan pada alat kontrol versi pilihan Anda. Bagaimana lagi Anda akan meninjau perubahan (perubahan apa pun)?
sleske

6

Bergantung pada lingkungan tempat perangkat lunak dijalankan, Anda bisa masuk jika metode ini pernah dipanggil. Jika tidak dipanggil dalam jangka waktu yang sesuai, maka metode ini dapat dihapus dengan aman.

Ini adalah pendekatan yang lebih hati-hati daripada hanya menghapus metode, dan mungkin berguna jika Anda menjalankan dalam lingkungan yang sangat sensitif terhadap kesalahan.

Kami masuk ke #unreachable-codesaluran slack khusus dengan pengidentifikasi unik untuk setiap kandidat untuk dihapus, dan itu terbukti sangat efektif.



maka "periode waktu yang cocok" lebih lama (meskipun saya suka "pria setelah tengah malam")
Jamie Bull
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.