メソッド名の一貫性ツールの課題
メソッド名の一貫性を保つための現在のツールを調べると、結構な問題があることがわかる。
― 1 分で読む
ソフトウェアコードのメソッドの適切な命名は重要だね。明確なメソッド名は、開発者がコードを理解しやすくして、時間が経つにつれてのメンテナンスに役立つ。でも、開発者は時々、コミュニケーション不足や命名ルールを知らないせいで、一貫性のない名前を使っちゃうことがあるんだ。それを解決するために、多くの研究者がメソッド名の一貫性を自動でチェックして、より良い名前を提案するツールを作るために取り組んできたんだ。ただ、残念ながら、こういったツールの多くは、なぜその名前が間違っているのかを説明してくれないから、あまり役立たないってわけ。名前変更の理由を知ることが、命名の改善に役立つんだけどね。
このギャップを埋めるために、私たちはReName4Jというベンチマークを作ったんだ。このベンチマークは、名前変更とコードレビューをつなげるもので、現在のツールがどれだけ一貫したメソッド名を見つけて提案できるのかを見ていくよ。私たちは、新しいベンチマークそのものを提示するんじゃなくて、実際のコードレビューに基づいた新たな視点を提供することを目指しているよ。私たちの調査結果から、現在のツールはこのレビューに焦点を当てたベンチマークに対して、うまく機能しないことが分かったんだ。また、既存のツールがどのように評価されているかに偏りがある可能性も指摘して、今後の研究でのさらなる調査の必要性を強調しているよ。
命名の重要性
ソフトウェアのメソッドは、特定のタスクを実行する小さなコードの塊なんだ。だから、確立された命名ルールに沿ったメソッド名を選ぶことが大事で、そのメソッドが何をするのかを明確に表す必要があるんだ。こうすることで、コードをよりメンテナブルにして、読みやすくなるんだよ。それにも関わらず、開発者は適切な名前を思いつくのが難しいことがあるんだ。
例えば、いくつかのオープンソースプロジェクトでは、register
という名前のメソッドはデータを保存するように思えるけど、実際には新しいオブジェクトを作成して返すんだ。同様に、transitToRestoreActive
というメソッドはプログラムの状態を選択的に変更するように見えるけど、そのメソッドはずっと動いてるんだ。これらのメソッドのコードレビューでは、generateToken
やenforceRestoreActive
のような代替名が提案されていて、実際の機能をよりよく反映しているんだ。
一貫性のないメソッド名の問題に対処するために、研究者は二つの主な作業を自動化する技術を提案してるんだ:メソッド名の一貫性をチェックすることと、より良い名前を提案すること。しかし、これらの技術を意味のある形で評価することは、チャレンジになることもあるよ。
現在の技術の課題
現存のデータセットは、命名ツールを評価するには限られていることが多いんだ。例えば、あるデータセットはメソッド名だけを変更するリビジョンで構成されているけど、それがコミュニティの基準や個々の開発者の意見と一貫しているかは分からないんだ。さらに、多くのデータセットは特定の学習方法に合わせて作られていて、メソッド名が時間の経過とともに安定する実際の条件を反映してないかもしれない。だから、命名問題をチェックするために設計されたツールは、ほとんどの名前が一貫している不均衡なデータセットで苦労する可能性があるんだ。
また、多くのアプローチは特定の類似性指標に依存していて、それが単一のデータセット用に調整されているから、より広い適用可能性に疑問が生じるんだ。
コードレビューの役割
コードレビューは重要で、命名の課題について貴重な洞察を提供することができるんだ。研究では、レビュー中にメソッド名がしばしば議論に出てくることが示されていて、開発者が名前を改善する方法について意見を共有しているんだ。こうした議論は、現在の命名の一貫性チェックや推奨ツールを評価するためのメソッドリネーミングインスタンスのデータベースを作成するためのしっかりした基盤を形成することができるんだ。
私たちのベンチマークでは、プルリクエストからレビューを集めて、命名に関連した用語に焦点を当てて関連する議論を特定したんだ。コメントとともにパッチを集めることで、メソッド名を抽出して400対のメソッド名ペアをまとめたんだ-それぞれがレビューに支持された変更を示しているんだ。
研究質問
ReName4Jベンチマークを使用して、いくつかの重要な研究質問に答えようとしているんだ:
- 既存のツールは、コードレビューシナリオで出てくるメソッドの正しい名前を取得できるのか?
- これらのツールは、一貫したメソッド名と一貫していないメソッド名を効果的に見つけられるのか?
- 現実のソフトウェア実践に似たデータセットでこれらのツールをテストした場合、どうなるのか?
これらの質問への回答は、ソフトウェア開発における研究と実践のギャップを埋める助けになるかもしれないよ、特にメソッド名の一貫性や推奨に焦点を当ててね。
実証研究の概要
この研究は三つのステップから成るよ:命名ベンチマークの構築、既存のメソッド名推奨ツールの再トレーニング、そして私たちのベンチマークに対するパフォーマンスのテスト。ベンチマークはコードレビューのデータから作成されていて、メソッドリネーミングタスクが開発者間の議論に裏打ちされていることを保証しているんだ。
私たちのベンチマークでは、メソッド名のペアを調べて、一貫性をチェックし、より良い名前を提案するんだ。この研究では、三つの現代的な技術-Spot、Cognac、GTNM-に注目して、その二つのタスクを実行する能力に焦点を当てて評価するよ。
データ収集
データ収集では、GitHubのトップJavaプロジェクトに注目したんだ。信頼性が高く関連性のあるデータセットを作るために、主に英語でないプロジェクトを除外して、メソッド名についての意味のある議論があるプロジェクトに絞ったんだ。GitHubのREST APIを使って、プルリクエストを集め、命名に関連するキーワードに基づいて関連レビューを特定したんだ。
このプロセスによって、コードレビューのコメントに関連したメソッドリネーミングタスクに関する豊富なデータを集めて、実用的なベンチマークの作成に寄与したんだ。
研究からの発見
私たちの研究からの発見は、現在の命名技術にいくつかの問題があることを示しているんだ、私たちのベンチマークに適用した場合:
- ツールはしばしばメソッドに対して適切な名前を推奨できず、以前の評価に比べて私たちの命名データではパフォーマンスが悪くなるんだ。
- 一貫性をチェックする際、これらのツールは多くの名前を誤分類し、精度が大きく低下していることを示しているんだ。
現在の技術の問題
全体的に、現在の技術は短くシンプルなメソッド名を好む傾向があるけど、コードレビューでは開発者が詳細で説明的な名前を好むことが示されているんだ。例えば、既存のモデルのメソッド名の平均長は、私たちのベンチマークのものよりずっと短いから、命名の好みに明確な違いがあるってことが分かる。
ツールを評価したとき、私たちは彼らが私たちのデータセットに含まれるより複雑な名前に苦労していることを発見したんだ。それらの名前にはメソッドに関する情報がもっと含まれているからね。
メソッド名推奨の評価
私たちの研究の最初のタスクは、特定のメソッドボディに対するメソッド名の推奨の効果を評価することだよ。このタスクでは、収集したベンチマークから各ツールが正しいメソッド名を提供できるかを分析するんだ。
私たちは、技術が私たちのデータセットに対して一貫して不十分に機能することを観察したよ。ツールからの推奨の理由を見直すと、より広い文脈を考慮する必要性が浮き彫りになったんだ。
例えば、いくつかのケースでは、技術がメソッドのユニークな目的を捉えきれない名前を推奨していて、全体的なコード構造に対する理解が不足していることを示唆しているね-つまり、現在のツールは改善が必要なんだ。
メソッド名の一貫性チェックの評価
二つ目のタスクは、各技術がメソッド名を一貫しているか一貫していないかを正確に分類できるかをチェックすることに焦点を当てているよ。ツールはそれぞれのメソッドボディに合わない名前を特定できることが期待されているんだ。
この研究の部分では、ツールが誤分類するケースがたくさんあったことに気づいたよ。特に、安定していると考えられる既存メソッドに関して、ツールはほとんどの名前を一貫していないと分類する傾向があったから、彼らのアルゴリズムの効果について疑問が生じたんだ。
不均衡なデータセット
最後に調べた点は、実際の状況を模した不均衡なデータセットでテストしたときの技術の効果だよ。こういったシナリオでは、ツールは一貫した名前の大半を正確に特定するのが難しく、多くを一貫していないと分類してしまった。
結果として、ツールは過度に厳しい閾値やパラメータを持っている可能性があり、それが高い誤分類率につながっていることを示しているんだ。閾値を調整することで、パフォーマンスの向上が期待できるかもしれないね。
結論
この研究は、現実のデータに直面したときの現在のメソッド名の一貫性チェックや推奨技術が直面する課題を浮き彫りにしているんだ。私たちは、多くのツールが精度と効果に苦しんでいること、特にコードレビューのデータに基づく複雑な命名タスクを評価する際にそうだということを発見したよ。
今後は、研究者や開発者がこれらの技術を洗練させて、コードレビューで得られる豊かな文脈情報を考慮することが重要だね。メソッド名の推奨や一貫性チェックに使うアルゴリズムを改善することで、ソフトウェアのメンテナンス性や可読性を大幅に向上させることができるかもしれないよ。
この研究から得られた洞察は、今後の研究の指針として役立って、ソフトウェア開発の風景にプラスになるようなより良い方法論につながるかもしれないね。
タイトル: How are We Detecting Inconsistent Method Names? An Empirical Study from Code Review Perspective
概要: Proper naming of methods can make program code easier to understand, and thus enhance software maintainability. Yet, developers may use inconsistent names due to poor communication or a lack of familiarity with conventions within the software development lifecycle. To address this issue, much research effort has been invested into building automatic tools that can check for method name inconsistency and recommend consistent names. However, existing datasets generally do not provide precise details about why a method name was deemed improper and required to be changed. Such information can give useful hints on how to improve the recommendation of adequate method names. Accordingly, we construct a sample method-naming benchmark, ReName4J, by matching name changes with code reviews. We then present an empirical study on how state-of-the-art techniques perform in detecting or recommending consistent and inconsistent method names based on ReName4J. The main purpose of the study is to reveal a different perspective based on reviewed names rather than proposing a complete benchmark. We find that the existing techniques underperform on our review-driven benchmark, both in inconsistent checking and the recommendation. We further identify potential biases in the evaluation of existing techniques, which future research should consider thoroughly.
著者: Kisub Kim, Xin Zhou, Dongsun Kim, Julia Lawall, Kui Liu, Tegawendé F. Bissyandé, Jacques Klein, Jaekwon Lee, David Lo
最終更新: 2023-08-24 00:00:00
言語: English
ソースURL: https://arxiv.org/abs/2308.12701
ソースPDF: https://arxiv.org/pdf/2308.12701
ライセンス: https://creativecommons.org/licenses/by-sa/4.0/
変更点: この要約はAIの助けを借りて作成されており、不正確な場合があります。正確な情報については、ここにリンクされている元のソース文書を参照してください。
オープンアクセスの相互運用性を利用させていただいた arxiv に感謝します。
参照リンク
- https://github.com/apache/flink/pull/14863
- https://github.com/elastic/elasticsearch/pull/82639
- https://medium.com/transparent-data-eng/good-practices-of-code-review-guide-for
- https://github.com/apache/shardingsphere/pull/18618
- https://github.com/wangpeibin713/flink/blob/748ad82745d9d493922150fe007136e125a50209/flink-table/flink-table-runtime-blink/src/test/java/org/apache/flink/table/runtime/operators/deduplicate/ProcTimeDeduplicateKeepLastRowFunctionTest.java
- https://github.com/open-beagle/shardingsphere/blob/5be6a2c81c647cdffb1f7f17db9c69204be14b4e/shardingsphere-proxy/shardingsphere-proxy-backend/src/test/java/org/apache/shardingsphere/proxy/backend/text/distsql/rdl/resource/AlterResourceBackendHandlerTest.java
- https://github.com/dhruvilshah3/kafka/blob/4c882dee7cacc4e09e13dc071804e6a1d8c8aaac/clients/src/main/java/org/apache/kafka/common/network/KafkaChannel.java
- https://github.com/Apache/eat-kafka/blob/a268e35e3c204b4335a19483b8ec3703c4d97e39/kafka-2.4.0-src/streams/src/test/java/org/apache/kafka/streams/state/internals/metrics/RocksDBMetricsRecorderTest.java
- https://github.com/apache/kafka/pull/2282
- https://github.com/apache/kafka/pull/1486
- https://github.com/apache/kafka/pull/11689
- https://figshare.com/s/8cdb4e3208e01991e45c
- https://docs.github.com/en/rest
- https://github.com/apache/kafka/pull/8988
- https://github.com/jenkinsci/jenkins/pull/4239
- https://github.com/jenkinsci/jenkins/pull/4239/files/41919ee7829223062d5d5ca4d592fd8056e55017#r330954855
- https://github.com/apache/kafka/pull/8319/files/c7ac051e495a98b6c72a340c24f4b9bb1f25dcdd#r395348873
- https://github.com/jenkinsci/jenkins/pull/4239/files/41919ee7829223062d5d5ca4d592fd8056e55017
- https://github.com/apache/kafka/pull/8319/
- https://github.com/apache/kafka/pull/8319/files/c7ac051e495a98b6c72a340c24f4b9bb1f25dcdd
- https://openreview.net/forum?id=H1gKYo09tX
- https://doi.org/10.1109/ICSE43902.2021.00061
- https://github.com/
- https://www.nndb.com/people/400/000031307/
- https://doi.org/10.1109/APSEC53868.2021.00010
- https://doi.org/10.1145/3510003.3510154