私は巨大なJavaプロジェクトでいくつかの作業を行うように割り当てられており、開発者の数回の反復の影響は明らかです。標準のコーディングスタイル、フォーマット、命名規則、またはクラス構造はありません。Javadocを使ったクラスに出会うのは良い日であり、ユニットテストは幸せな空想です。
これまでのところ、プロジェクトに参加している人たちは、私たちが取り組んでいるクラスの既存の慣習に適応して「溶け込んで」いますが、ある程度の秩序と一貫性を課す時が来ています。
それは大変な挑戦であり、私は人々がそのような仕事について持っているかもしれないアドバイスを探しています。特に効果的な戦略や、注意すべき落とし穴はありますか？試してみるのもいい考えですか？
編集して追加：プロジェクトが悪いという印象を与えたくありません。実際、プロジェクトはしっかりと設計されており、大部分はよく書かれています。それはちょうどその年齢とメンテナンスの必然性を感じています...
Eclipseは、このような操作のための非常に強力なツールであることがわかりました。
多くの人がプログラミング用のコマンドラインツールとモーダルベースのテキストエディタを誓いますが、主要なリファクタリングに完全なIDEを使用することには大きな利点があります。
Eclipseのツールセットに加えて、コードが常に機能していることを確認するために、他の最新のJavaツールを利用することを検討するかもしれません。
編集：
また、個人的にはEclipseを好みます。なぜなら、私はリファクタリングを行っているのであり、コードについてほとんど何も知らない自動化されたツールではないからです。
ツールを使用して、プロジェクトのソースコードに共通の形式を課すことができます。それとは別に、Michael Feathersの「レガシーコードを効果的に使用する」（「レガシーコード」は「単体テストなしのコード」と定義されています）を参照してください。これは、レガシーコードを完全にテストされたテスト可能なコードに徐々に変換する方法を説明しています。
この状況で私がしたいことは次のとおりです。
モノリシッククラスから始めて、それらを分割します（コメントと中括弧だけの行を除いて、500を超えるステートメント）。インターフェイスを導入してから、依存性注入を導入します。
私はこのプロセスを数回経験しましたが、解決策には次のことを知っている必要があることがわかりました。
政治的状況を緩和するのは最も困難であり、基本的には横方向の動きのアイデアを好む人は誰もいません。コードのフォーマットと命名規則を適用するプロセスを経ることは、非常に横方向の動きです。あなたがあなたの決定を正当化する確かな一連の測定基準を思い付くことができれば、あなたの横方向の動きは前方への動きになりすますことができます。ここでの最良の指標は、
「一貫したコーディング標準のセットにより、次の結果が得られます。-30％少ないバグ-30％速い開発-80％低いメンテナンスコスト-私たちのコーダーの100％は、この変更にはるかに満足しています。」
これらの数字を空中から引き出すだけではありません。これを正当化することができます。
現在プロジェクトに追加している人々から賛同を得ない限り、明らかにこの作業を開始する意味はありません。誰もが同意し、これらの理想を現在存在するコードにレトロフィットし始める必要があります。誰もがIDEを使用しているわけではないことを忘れないでください（たとえば、すべてのJavaをVIMでコーディングします）。したがって、この形式がすべての人（特に新しいチームメンバー）が見ることができるようにWikiで指示されていること、およびWikiページにさまざまなエディターのダウンロードがあることを確認する必要があります。使用中で。
コードのフォーマットだけでなく、変数の名前変更やパターンの変更についても話している可能性が高いため、これらはクラスのパブリックAPIに影響を与えるため、非常に安定したテストケースのセットを用意する必要があります。テストケースが欠落している場合は、常に外部から開始する必要があります。ユーザーと同じように相互作用するようにテストをモデル化します。その後、ある程度の自信を持ってリファクタリングを行うことができます。夢に似たコードができたら、各オブジェクトの近くにテストを追加できます。すべてのテストケースを作成してから、APIを変更し、すべてのテストケースを変更しなければならないことほど苦痛なことはありません。それが起こるのを見るたびに、テストカバレッジが大幅に低下します。
私の提案は、ビルドシステムにCheckstyleのようなものを追加することです。完全なオーバーホールを一度に行うという考えを経営陣に受け入れさせるのは困難です。優れたスタイルガイドラインのセットを設計し、それらをCheckstyleに実装して、ビルドに追加します。
次に、コードのすべての新しいチェックインがCheckstyleを壊さないことを要求します。つまり、クラスで作業するときはいつでも、それを標準に引き上げることになります。しばらくコミットする前にやらなければならないことが少しでもあれば、余分な作業をしているようには見えません。
また、Eclipse用のcheckstyleプラグインがあります。
これはかなり一般的なタスクであり、あまり楽しいものではありませんが、悪夢でもありません...他の言語（Perl、PHP、C ++、-gasp- VB ...）でコーディングすると、さらに悪化する可能性があります。実際、Javaはシナリオに最適なものの1つです。
適切なIDE（Eclipse）を入手して、依存関係と呼び出しサイクルを理解するために十分な時間を費やしてください。すべてに慣れるまでには長い時間がかかるので、最初は小さな変更のみを行うようにしてください。
ドキュメントが不足している場合、IDE（および静的コンパイル）は、誰がどのクラスまたはメソッドを使用しているかを知るのに大いに役立ち、非常に自信を持ってリファクタリングを行うことができます。ただし、最初に、どのレイヤー/パッケージ/クラスでリフレクションが使用されているかを特定してみてください（コードによって明示的に、またはフレームワークによって暗黙的に（たとえば、一部のゲッターやセッター）。
「レガシーソフトウェアのリエンジニアリング」と関連する問題に捧げられた多くの本があります。
そんな経験をしました。Mavenビルド、Eclipse、Checkstyle、ビッグクラスのリファクタリングなどを推奨する人々に同意します。作業を開始する前に完全なテストカバレッジを達成することはできないことを理解しています。1.チェックスタイルまたは同様のツールを使用してバッチモードでコードを再フォーマットすることをお勧めします。2。Eclipseですべての妥当な警告を有効にし、このリファクタリングが簡単な場合にそのような警告を引き起こすコードをリファクタリングします。それ以外の場合は、@ SupressWarningと特別なTODOを配置して、後でこのコードに戻ってください。3.欠陥駆動型の自動テストを使用します。つまり、変更するモジュールのテストを開発します。
幸運を！
また、IDEの機能を使用してコードの品質を向上させることをお勧めします。日食のためにこれは私がすることです：
設定java>コードスタイル>フォーマッタで-独自のフォーマットを定義して追加します。その後、プロジェクトを右クリックし、ソース<クリーンアップします。sustomプロファイルを選択して構成します。ここでできることはたくさんあります。たとえば、コードのフォーマットをクリーンアップしてインポートをクリーンアップし、レガシーforループを拡張ループに変換して未使用のコードをクリーンアップするなどです。
その後、checkstyle、pmd、findbugsなどを使用するなど、他の人が提案したことを実行します。