Bagaimana menemukan kode yang tidak digunakan / mati dalam proyek java [ditutup]

Alat apa yang Anda gunakan untuk menemukan kode yang tidak digunakan / mati dalam proyek-proyek java besar? Produk kami telah dikembangkan selama beberapa tahun, dan semakin sulit untuk secara manual mendeteksi kode yang tidak lagi digunakan. Namun kami mencoba untuk menghapus kode yang tidak terpakai sebanyak mungkin.

Saran untuk strategi / teknik umum (selain alat khusus) juga dihargai.

Sunting: Perhatikan bahwa kami sudah menggunakan alat cakupan kode (Clover, IntelliJ), tetapi ini sedikit membantu. Kode mati masih memiliki unit test, dan muncul sebagai tertutup. Saya kira alat yang ideal akan mengidentifikasi kelompok kode yang memiliki sangat sedikit kode lain tergantung padanya, memungkinkan untuk melakukan pemeriksaan manual.

Saya akan instrumen sistem yang berjalan untuk menyimpan log penggunaan kode, dan kemudian mulai memeriksa kode yang tidak digunakan selama berbulan-bulan atau bertahun-tahun.

Misalnya jika Anda tertarik pada kelas yang tidak digunakan, semua kelas bisa diinstrumentasi untuk mencatat ketika instance dibuat. Dan kemudian skrip kecil dapat membandingkan log ini dengan daftar kelas lengkap untuk menemukan kelas yang tidak digunakan.

Tentu saja, jika Anda mengikuti level metode, Anda harus selalu mengingat kinerja. Misalnya, metode hanya bisa mencatat penggunaan pertama mereka. Saya tidak tahu bagaimana ini paling baik dilakukan di Jawa. Kami telah melakukan ini di Smalltalk, yang merupakan bahasa yang dinamis dan karenanya memungkinkan untuk modifikasi kode saat runtime. Kami instrumen semua metode dengan panggilan logging dan menghapus kode logging setelah metode telah login untuk pertama kalinya, sehingga setelah beberapa waktu tidak ada lagi hukuman kinerja terjadi. Mungkin hal serupa dapat dilakukan di Jawa dengan bendera boolean statis ...

Plugin Eclipse yang berfungsi dengan baik adalah Detektor Kode yang Tidak Digunakan .

Ini memproses seluruh proyek, atau file tertentu dan menunjukkan berbagai metode kode yang tidak digunakan / mati, serta menyarankan perubahan visibilitas (yaitu metode publik yang dapat dilindungi atau pribadi).

CodePro baru-baru ini dirilis oleh Google dengan proyek Eclipse. Ini gratis dan sangat efektif. Plugin ini memiliki fitur ' Cari Kode Mati ' dengan satu / banyak titik masuk. Bekerja dengan cukup baik.

Saya terkejut ProGuard belum disebutkan di sini. Ini adalah salah satu produk paling matang di sekitar.

ProGuard adalah shrinker, optimizer, obfuscator, dan preverifier file kelas Java gratis. Ini mendeteksi dan menghapus kelas, bidang, metode, dan atribut yang tidak digunakan. Ini mengoptimalkan bytecode dan menghapus instruksi yang tidak digunakan. Itu mengubah nama kelas yang tersisa, bidang, dan metode menggunakan nama pendek yang tidak berarti. Akhirnya, ini memverifikasi kode yang diproses untuk Java 6 atau untuk Java Micro Edition.

Beberapa penggunaan ProGuard adalah:

• Membuat kode yang lebih ringkas, untuk arsip kode yang lebih kecil, transfer yang lebih cepat di seluruh jaringan, pemuatan yang lebih cepat, dan jejak kaki memori yang lebih kecil.
• Membuat program dan perpustakaan lebih sulit untuk direkayasa ulang.
• Daftar kode mati, sehingga dapat dihapus dari kode sumber.
• Penargetan ulang dan preverifikasi file kelas yang ada untuk Java 6 atau lebih tinggi, untuk mengambil keuntungan penuh dari pemuatan kelas yang lebih cepat.

Berikut contoh kode mati daftar: https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode

Satu hal yang saya ketahui dilakukan di Eclipse, pada satu kelas, adalah mengubah semua metodenya menjadi pribadi dan kemudian melihat keluhan apa yang saya dapatkan. Untuk metode yang digunakan, ini akan memancing kesalahan, dan saya mengembalikannya ke tingkat akses terendah yang saya bisa. Untuk metode yang tidak digunakan, ini akan memancing peringatan tentang metode yang tidak digunakan, dan itu bisa dihapus. Dan sebagai bonus, Anda sering menemukan beberapa metode publik yang dapat dan harus dibuat pribadi.

Tapi ini sangat manual.

Gunakan alat cakupan tes untuk instrumen basis kode Anda, kemudian jalankan aplikasi itu sendiri, bukan tes.

Emma dan Eclemma akan memberi Anda laporan bagus tentang berapa persen dari kelas apa yang dijalankan untuk setiap menjalankan kode.

Kami sudah mulai menggunakan Find Bugs untuk membantu mengidentifikasi beberapa funk di lingkungan basis kode kami yang kaya untuk refactor. Saya juga akan mempertimbangkan Structure 101 untuk mengidentifikasi bintik-bintik dalam arsitektur basis kode Anda yang terlalu rumit, sehingga Anda tahu di mana rawa-rawa yang sebenarnya.

Secara teori, Anda tidak dapat secara pasti menemukan kode yang tidak digunakan. Ada bukti matematis dari ini (well, ini adalah kasus khusus dari teorema yang lebih umum). Jika Anda penasaran, cari Masalah Pemutusan.

Ini dapat memanifestasikan dirinya dalam kode Java dalam banyak cara:

• Memuat kelas berdasarkan input pengguna, file konfigurasi, entri basis data, dll;
• Memuat kode eksternal;
• Melewati pohon objek ke perpustakaan pihak ketiga;
• dll.

Yang sedang berkata, saya menggunakan IDEA IntelliJ sebagai IDE pilihan saya dan memiliki alat analisis yang luas untuk dependensi antara modul, metode yang tidak digunakan, anggota yang tidak digunakan, kelas yang tidak digunakan, dll. Cukup cerdas juga seperti metode pribadi yang tidak dipanggil adalah ditandai tidak terpakai tetapi metode publik membutuhkan analisis yang lebih luas.

Di Eclipse Goto Windows> Preferensi> Java> Compiler> Kesalahan / Peringatan
dan ubah semuanya menjadi kesalahan. Perbaiki semua kesalahan. Ini adalah cara paling sederhana. Keindahannya adalah ini akan memungkinkan Anda untuk membersihkan kode saat Anda menulis.

Kode Cuplikan Layar:

IntelliJ memiliki alat analisis kode untuk mendeteksi kode yang tidak digunakan. Anda harus mencoba membuat sebanyak mungkin bidang / metode / kelas sebagai non-publik dan itu akan menunjukkan lebih banyak metode / bidang / kelas yang tidak digunakan

Saya juga akan mencoba mencari kode duplikat sebagai cara mengurangi volume kode.

Saran terakhir saya adalah mencoba mencari kode sumber terbuka yang jika digunakan akan membuat kode Anda lebih sederhana.

Perspektif slice Structure101 akan memberikan daftar (dan grafik dependensi) dari setiap "yatim" atau " kelompok yatim " kelas atau paket yang tidak memiliki dependensi ke atau dari "utama" cluster.

DCD bukanlah plugin untuk beberapa IDE tetapi dapat dijalankan dari semut atau mandiri. Sepertinya alat statis dan dapat melakukan apa yang PMD dan FindBugs tidak bisa . Saya akan mencobanya.

PS Seperti yang disebutkan dalam komentar di bawah, Proyek tinggal sekarang di GitHub .

Ada alat yang kode profil dan menyediakan data kode cakupan. Ini memungkinkan Anda melihat (saat kode dijalankan) berapa banyak yang dipanggil. Anda dapat memperoleh alat-alat ini untuk mencari tahu berapa banyak kode yatim yang Anda miliki.

• FindBugs sangat baik untuk hal semacam ini.
• PMD (Project Mess Detector) adalah alat lain yang dapat digunakan.

Namun, tidak ada yang dapat menemukan metode statis publik yang tidak digunakan di ruang kerja. Jika ada yang tahu alat seperti itu maka tolong beri tahu saya.

Alat jangkauan pengguna, seperti EMMA. Tapi itu bukan alat statis (yaitu itu benar-benar harus menjalankan aplikasi melalui pengujian regresi, dan melalui semua kasus kesalahan yang mungkin, yang, yah, tidak mungkin :))

Meski begitu, EMMA sangat bermanfaat.

Alat cakupan kode, seperti Emma, ​​Cobertura, dan Clover, akan menginstrumentasi kode Anda dan mencatat bagian mana yang dipanggil dengan menjalankan serangkaian tes. Ini sangat berguna, dan harus menjadi bagian integral dari proses pengembangan Anda. Ini akan membantu Anda mengidentifikasi seberapa baik test suite Anda mencakup kode Anda.

Namun, ini tidak sama dengan mengidentifikasi kode mati nyata. Ini hanya mengidentifikasi kode yang dicakup (atau tidak dicakup) oleh tes. Ini dapat memberi Anda positif palsu (jika tes Anda tidak mencakup semua skenario) serta negatif palsu (jika tes Anda mengakses kode yang sebenarnya tidak pernah digunakan dalam skenario dunia nyata).

Saya membayangkan cara terbaik untuk benar-benar mengidentifikasi kode mati adalah dengan instrumen kode Anda dengan alat cakupan di lingkungan live running dan untuk menganalisis cakupan kode selama periode waktu yang panjang.

Jika Anda menjalankan dalam lingkungan redundan seimbang beban (dan jika tidak, mengapa tidak?) Maka saya kira masuk akal untuk hanya instrumen satu contoh aplikasi Anda dan untuk mengkonfigurasi penyeimbang beban Anda sedemikian rupa sehingga secara acak, tetapi kecil, bagian dari pengguna Anda berjalan pada instance yang diinstrumentasi. Jika Anda melakukan ini selama periode waktu yang lama (untuk memastikan bahwa Anda telah membahas semua skenario penggunaan dunia nyata - variasi musiman seperti itu), Anda harus dapat melihat dengan tepat area kode mana yang diakses di bawah penggunaan dunia nyata dan bagian mana benar-benar tidak pernah diakses dan karenanya kode mati.

Saya belum pernah melihat ini dilakukan secara pribadi, dan tidak tahu bagaimana alat-alat tersebut dapat digunakan untuk instrumen dan menganalisis kode yang tidak dipanggil melalui test suite - tetapi saya yakin mereka bisa melakukannya.

Ada proyek Java - Dead Code Detector (DCD). Untuk kode sumber sepertinya tidak berfungsi dengan baik, tetapi untuk file .jar - ini sangat bagus. Plus, Anda dapat memfilter menurut kelas dan metode.

Netbeans di sini adalah plugin untuk detektor kode mati Netbeans .

Akan lebih baik jika bisa menautkan dan menyorot kode yang tidak digunakan. Anda dapat memilih dan berkomentar di sini: Bug 181458 - Temukan kelas, metode, bidang yang tidak digunakan

Eclipse dapat menampilkan / menyorot kode yang tidak dapat dijangkau. JUnit dapat menunjukkan cakupan kode kepada Anda, tetapi Anda akan memerlukan beberapa tes dan harus memutuskan apakah tes yang relevan hilang atau kode tersebut benar-benar tidak digunakan.

Saya menemukan alat cakupan Clover yang instrumen kode dan menyoroti kode yang digunakan dan yang tidak digunakan. Tidak seperti Google CodePro Analytics, itu juga berfungsi untuk Aplikasi Web (sesuai pengalaman saya dan saya mungkin salah tentang Google CodePro).

Satu-satunya kelemahan yang saya perhatikan adalah tidak membutuhkan antarmuka Java.

Saya menggunakan Doxygen untuk mengembangkan metode panggilan peta untuk menemukan metode yang tidak pernah dipanggil. Pada grafik Anda akan menemukan pulau-pulau cluster metode tanpa penelepon. Ini tidak berfungsi untuk perpustakaan karena Anda harus selalu mulai dari beberapa titik masuk utama.