ダーティコードについていくつか質問をしたいと思います。中規模のプロジェクトでコーディングした初心者もいます。コードは非常に大きな泥の塊です。彼らは上級プログラマーではありません。彼らは、Javaについてキーボードの使い方を少し知っているだけです。メインクラスに12,000行のコードを記述しただけですが、6000行はNetBeans自体に属します。

私の仕事は、コードを分析し、コードを維持する良い方法を提案することです。私のアイデアは、プロジェクトを廃棄し、OOP方法論で新しいプロジェクトを開始することです。最近、このサイトや他のいくつかから、問題に関するメモやアイデアを集めました。

今、私は次の質問があります：

1. コードを修復し、OOPに変更する必要がありますか？現在、デバッグ中です。
2. コードにはコメント、ドキュメント、プログラミングの特定のスタイルなどがありません。それを変更することは本当に高価で時間がかかります。これについて何ができますか？
3. すべてのルール（コメント、OOP、優れたコード品質など）に従うように指導するにはどうすればよいですか？
4. コードに誤りがあり、エラーが発生しやすい。私たちは何ができる？テスト？修正用に2〜3枚のA4ペーパーを作成しますが、終わりはないようです。

私は彼らとは新しいと言わなければなりません。同様に、プロジェクトへの参加が遅すぎるというルールを破ったと思います。私は彼らを去らなければならないと思いますか？

ステップ0：SCMへのバックアップ

JBRWilkinsonがコメントで示唆したように、バージョン管理は（不可逆的な）災害に対する最初の防御線であるためです。

ソフトウェア構成の詳細、成果物を作成する手順などもバックアップしてください。

ステップ1：最初にテストする

次に、テストを記述することから始めます。

• 何のために
• そして失敗したもののために。

何をすることにしたとしても、あなたはカバーされます。次のいずれかを実行できます。

• 最初からやり直して書き直し、
• または修正します。

私のアドバイスは、一般的なアーキテクチャを最初から開始することですが、混乱からチェックポイントを検証する部分を抽出し、必要に応じてこれらをリファクタリングすることです。

ステップ2：確認と監視

継続的インテグレーションシステム（ステップ0およびステップ1を補完するため）と継続的インスペクションシステム（ステップ4の準備のため）をセットアップします。

ステップ3：巨人の肩に立つ

（いつものように...）

• パターンへのリファクタリング
• リファクタリング：既存のコードの設計を改善します。
• レガシーコードを効果的に使用する（ Jason Bakerが推奨）
• リファクタリング

ステップ4：クリーニング

そのようなことは言うまでもありませんが、自分でコードをざっと調べる代わりに、壊れたコードベースでリンター/静的アナライザーやその他のツールを実行して、設計と実装のエラーを見つけることができます。

次に、コードフォーマッタを実行することもできます。これは、すでにハウスキーピングに少し役立ちます。

ステップ5：レビュー

リファクタリングやクリーンアップを行うことで、小さなバグを簡単に導入できます。間違った選択とキーのクイックヒットだけが必要で、最初は気付かないうちにかなり重要なものを削除する可能性があります。また、場合によっては数か月後に効果が現れることもあります。もちろん、上記の手順はこれを回避するのに役立ちます（特に強力なテストハーネスを実装することで）が、何がすり抜けることができるのか、また何がすり抜けるのかがわかりません。したがって、リファクタリングは、少なくとも1つの他の専用の目玉（および、できればそれ以上）でレビューしてください。

ステップ6：開発プロセスの将来性

上記のすべてを取り、それがあなたの通常の開発プロセスの固有の部分になります（まだそうでない場合）。時計でこれが再び発生しないようにし、チームと協力してプロセスにセーフガードを実装し、ポリシーで（可能であれば）これを実施します。生産作るクリーンなコードの優先順位を。

しかし、実際には、テストします。たくさん。

個人的には、「レガシーコードを効果的に使用する」のコピーが手元にあるまで、このプロジェクトを開始しませんでした。真剣に、それはまさにこのタイプのことのために書かれました。トリッキーなコードを扱うための戦略が豊富にあり、ここで説明するよりもはるかに詳細に説明します。

何度か行ったことがあります。私のルールは次のとおりです。ソフトウェアが自明ではなく（使用しているリソースに対して1週間以上動作する）、動作する場合は、それを保持してインクリメンタルリファクタリングを続行します。

ソフトウェアが実際に機能しない場合（非常に多くのバグ、不明な要件など）、最初から書き直す方が良いでしょう。かなり小さい場合も同じです。

リファクタリングのポイント（Fowlerの本とKerievskyの1つhttp://www.industriallogic.com/xp/refactoring/にあるように）は、システムの動作を維持することです。リファクタリングには2倍の時間がかかりますが、リスクはゼロです。

最初から書き直すと、要件の誤解から実装の誤りまで、多くのリスクが生じる可能性があります（ほとんどのチームが同じになった後）。

実際に、複雑な手順がゼロから2回書き直され、まだ期待どおりに動作しないのを見ました。

完全に書き直します。そのようなコードを修復することが不可能な場合があります。別のオプションは、新しい機能を追加せずに機能させることです。チームに適切なコード（適切に設計され、文書化され、テスト済み）を作成するように教えるために、現在のコードを修正してもらいます。誰もがバグを修正したり、他の開発者のコ​​ードをレビューしたりできます。いくつかの試みの後、彼らはそのようなコードをレビュー/修正することはほとんど不可能であることを理解します。

後期プロジェクトに人を追加することはほとんどありません。通常、それは期限を破ります。プロジェクトを正常に終了するためにできる限りのことを行ってから、離れることを検討する必要があります。

私のアドバイスは、コード全体を完全に廃棄しないことです。これは日常の問題であり、すべての開発チームが直面しています。コードの一部を一度に攻撃します。修正、クリーニング、文書化してください。そして、他の部分に移動します。主なことは、常にいくつかの出荷可能なコードを手元に置いておくことです。スクラッチからコード全体を書き換えると、これまでに費やされた時間がかかり、現在よりも優れているという保証はありません。
しかし、その後、人々はこの方法でコードを書くことを避けるべきです。コードレビューにもう少し時間をかけます。一定のコーディングスタイルに適応します。最初に設計について話し合ってから、コードを記述します。このような単純なことは大きな変化をもたらします。

Netscapeが緩んでいる理由を伝える素敵なブログ

動作する場合は、リファクタリングします。そのためのツールがあります。動作しない場合は、魔法のコード改善コマンドを使用してdeltreeください。つまり、Windowsの場合です。rm -rfLinuxで。

コードを修復し、OOPに変更する必要がありますか？現在、デバッグ中です。[...エラーが含まれていますが、ドキュメントはありません...]

私はそこにいました、あなたは私の同情を持っています。私はこれについての記事を書きました。しかし、要するに：

コードに多くの重複が含まれている場合は、書き直す必要があります。識別できる構造がない場合（明確なインターフェース、スパゲッティがない場合）、リファクタリングは失敗し、おそらく書き直す必要があります。

すべてのルールに従うように彼らに教えるにはどうすればよいですか？

彼らが個人的にそれから得ることができるものを彼らに示すことによって、彼らがそうすることを望むかもしれない理由を説明することから始めてください。彼らがこれに同意し、学びたいと思ったら、shuhariを使って教え始めます。

私の提案は、@ durosと@Manoj Rの回答の組み合わせです。

ゼロから始めて、今回は良いコード/ OOP /コメント付き/などを作成することを念頭に置いて、古いコードから参照/コピー＆ペーストします。古いコードの悪い部分に出会ったら、それらを書き直し/リファクタリングします。

開発者が十分な訓練を受けていない場合は、コースに参加することをお勧めします。急速に変化するIT業界での定期的な再トレーニングに重要