私は、既存の悪いコードを良いコードに変更することに関する記事を読んでしまいました。参考までに、これは記事http://www.javaworld.com/jw-03-2001/jw-0323-badcode.html?page=1へのリンクです。
それは広く次のことについて話しました
コメントを追加
リファクタリングコード
良いようです。このリストにあなたが出くわしたかもしれないアドオンはありますか？
リファクタリングを行う前に、コードで実行できる一連の回帰テストがあることを確認してください。元の「悪い」コードが実際に行っていたものにわずかなニュアンスが欠けているために（そしてリファクタリングでそれが欠けているために）何千ものリグレッションバグを導入する場合、コードベースをリファクタリングするのは良くありません。
コメントに関しては、JavaDocsを使用することをお勧めします。これは、コーディングしながらドキュメントを作成するようなものです。
Martin Fowler は、リファクタリングに関する優れた本を書きました。
コードを恒久的に変更する前に完全に理解できるように、それを読んでいじくり回し、コメントしながらコメントしてください。
ほとんどのコードは、高レベルのインターフェースからリファクタリングできます（そして、これらの1つを作成することは、リファクタリングプロジェクトの良いスタートになる可能性があります）。
古いコードには多くの特殊なケースや回避策、または文書化されていないが必要な動作が含まれている可能性があるため、最初から再実装する価値はありません。したがって、リファクタリングの基礎として常に既存のコードを使用してください。
JavaDocsとコメントを追加して、既存のコードベースを学習しながら文書化します。これは、コードの機能を理解するときに、後で再設計の基礎を形成する可能性があります。
変数名をリファクタリングして変更するだけで、読みやすさが大幅に向上する可能性があります。特にコードが機能し、これらの単純な問題のために保守が少し難しい場合は、可能であれば常に単純なリファクタリングを行うようにしてください。
回帰テストの完全なスイートがあることを確認してください！
FindBugs、PMDなどを入手して、彼らが何を言わなければならないかを調べ始めます。私は、Findbugsのエラーを最も多く報告するクラスには多くの問題があり、リファクタリングの取り組みを開始するのに適した場所であることに気付く傾向があります。
注目に値するもう1つのツールはSTAN4Jです。これは、コードの設計を実際に改善できる場所を示す構造メトリックを生成します。脆弱な継承階層、不適切な抽象化などを検出します。これらは、リファクタリング作業のターゲットになるはずです。
これらの種類のツールに常に注意を払うことは価値があります。それらがあなたに言っていることを解釈する方法を学ぶならば、それらはあなたを大いに助けます。
IDEの警告にも注意してください。警告は理由があります。
コードをリファクタリングする理由を自問してください。コードに触れる必要がありますか? 壊れやすいコードを改善することで簡単に壊すことができます。
コードを変更する必要があると判断した場合は、他の人が述べたように、一連のテストを用意すると非常に役立ちます。
変更しているファイルのリビジョン履歴を見て、バグを修正するために変更が加えられたかどうかを確認してください。そうすれば、それらのバグを書き直すのを避けることができます。
パフォーマンス上の理由でコードをリファクタリングする場合は、アルゴリズムの改善に注意してください。コードのホットセクションでO(n^2) アルゴリズムを O(n log(n)) に変更できれば、他の小さな変更よりも多くのことをコードに実行できます。