コメントされていない汚いコードを整理していますか？
汚いコードについていくつか質問をしたいと思います。中規模プロジェクトでコーディングした初心者もいます。コードは非常に巨大な泥の塊です。彼らは高度なプログラマではありません。彼らはちょうどJavaについて少しキーボードの使い方を知っています。彼らはメインクラスに12,000行のコードを書いただけですが、6000行はNetBeans自体に属しています。
私の仕事はコードを分析し、コードを維持するための良い方法を提案することです。私のアイデアは、プロジェクトをスクラップして、OOP方法論で新しいプロジェクトを開始することです。最近、このサイトや他のサイトから、問題に関するメモやアイデアを集めました。
今、私は次の質問があります：
- コードを修正して、OOPに変更する必要がありますか？現在デバッグ中です。
- コードにはコメント、ドキュメント、特定のプログラミングスタイルなどはありません。それを変更することは本当に費用と時間がかかります。これに対して私たちは何ができますか？
- すべてのルール（コメント、OOP、優れたコード品質など）に従うように教えるにはどうすればよいですか？
- コードに誤りがあり、エラーが発生しやすい。私たちは何ができる？テスト？修正のためにA4用紙を2〜3枚書いていますが、それは無限のようです。
私は彼らと一緒に新しいと言う必要があります。プロジェクトに遅すぎる人を追加するというルールも破ったと思います。私を離れる必要があると思いますか？
ステップ0：SCMへのバックアップ
コメントでJBRWilkinsonが示唆したように、version controlは、（不可逆的な）災害に対する最初の防御線です。
ソフトウェア構成の詳細、成果物を作成する手順などもバックアップします。
ステップ1：最初にテストする
次に、テストを作成することから始めます：
- 何がうまくいくか
- そして何が失敗したのか。
あなたが何をしようと決心しても、あなたはカバーされます。次のいずれかを実行できます。
- startfrom scratchおよびre-write、
- またはfixそれ。
私のアドバイスは、一般的なアーキテクチャを最初から開始することですが、extract混乱からチェックポイントを検証し、必要に応じてこれらをリファクタリングします。
ステップ2：確認と監視
継続的インテグレーションシステムをセットアップします（ステップを補完するために）0およびstep 1) AND a継続的検査システム（ステップ4の準備）。
ステップ3：巨人の肩の上に立つ
（いつものように...）
ステップ4：クリーニング
そのようなことは言うまでもありませんが、コードを自分でざっと目を通す代わりに、壊れたコードベースでリンター/スタティックアナライザーやその他のツールを実行して、デザインや実装のエラーを見つけることができます。
次に、コードフォーマッターを実行することもできます。これは、ハウスキーピングに少し役立ちます。
ステップ5：レビュー
refactoring で小さなバグを導入したり、クリーンアップしたりするのは簡単です。間違った選択とキーのクイックヒットしかとらないため、最初は気付かないうちにかなり重要なものを削除する可能性があります。そして時には効果は数ヶ月後に現れるでしょう。もちろん、上記の手順はこれを回避するのに役立ちます（特に強力なテストハーネスを実装することで）。したがって、リファクタリングを少なくとも1つの他の専用の眼球（できればそれ以上）でレビューしてもらうようにしてください。
ステップ6：開発プロセスの将来を保証する
上記のすべてを取り入れて、通常の開発プロセスの固有の部分にしてください（そうでない場合）。これを時計で再び起こさないでください。チームと協力してプロセスに保護手段を実装し、ポリシーに（可能な場合は）これを適用してください。生成する クリーンコード を優先します。
しかし、本当に、test。 たくさん。
個人的に、私は レガシーコードで効果的に動作する のコピーを手に入れるまで、このプロジェクトを開始しませんでした。真剣に、それはまさにこのタイプのもののために書かれました。トリッキーなコードを処理するための戦略が満載であり、ここで説明するよりもはるかに詳細に説明します。
何度か行ったことがある。私のルールは次のとおりです。ソフトウェアが自明ではなく（使用しているリソースで1週間を超える作業）、機能する場合は、それを維持して増分リファクタリングを続行します。
ソフトウェアが実際に機能しない場合（非常に多くのバグ、不明確な要件など）、ゼロから書き直す方が良いでしょう。かなり小さい場合も同じです。
リファクタリングのポイント（Fowlerの本とKerievskyの本 http://www.industriallogic.com/xp/refactoring/ のように）は、システムを動作させ続けることです。おそらく、リファクタリングには2倍の時間がかかりますしかし、リスクはゼロです。
最初から書き直すと、要件の誤解から間違った実装まで、多くのリスクが発生する可能性があります（ほとんどすべてのチームが同じになるため）。
実際に、複雑な手順が最初から2回書き直され、それでも期待どおりに機能しないのを目にしました。
完全に書き直します。このようなコードを修復できない場合があります。もう1つのオプションは、新しい機能を追加せずに機能させることです。チームに優れたコード（よく設計され、文書化され、テストを含む）を書くように教えるには、現在のコードを修正させます。全員にバグの修正や他の開発者のコードのレビューを任せてください。いくつかの試みの後、彼らはそのようなコードをレビュー/修正することはほとんど不可能であることを理解します。
後期プロジェクトに人を追加することは非常に稀です。通常は締め切りを守ります。プロジェクトを正常に完了するためにできることはすべて実行してから、去ることを考えるべきです。
私のアドバイスは、コード全体を完全に廃棄しないことです。これは日常の問題であり、すべての開発チームが直面しています。コードの一部を一度に攻撃します。修正し、きれいにし、文書化します。そして、他の部分に移動します。主なことは、常にいくつかの出荷可能なコードを手元に置くことです。コード全体を最初から書き直すには、これまでに費やされた時間がかかり、現在よりも優れているという保証はありません。
しかし、それでまた人々はこの方法でコードを書くことを避けるべきです。コードレビューにもう少し時間をかけてください。一定のコーディングスタイルに適応します。最初に設計について議論し、次にコードを記述します。そのような単純なことは大きな変化をもたらします。
機能する場合は、リファクタリングします。それを行うのに役立つツールがあります。それが機能しない場合は、魔法のコード改善コマンドを使用してください。つまり、Windows respのdeltreeです。 rm -rf Linuxの場合。
コードを修正して、OOPに変更する必要がありますか？現在デバッグ中です。 [...エラーが含まれていますが、ドキュメントはありません...]
私はそこに行った、あなたは私の同情を持っています。私はこれについてarticleを書いて、いくつかの視点を得るのに役立つかもしれません。しかし、要するに：
コードに複製のlotsが含まれている場合は、書き換える必要があります。識別可能な構造がない場合（明確なインターフェース、スパゲッティがない場合）、リファクタリングは失敗し、おそらく書き換えるべきです。
どうすればすべてのルールに従うように教えることができますか？
彼らが個人的にそれから得ることができるものを彼らに示すことによって、なぜ彼らがそれをしたいのかを説明することから始めます。彼らがこれに同意し、学びたいと思ったら、 shuhari を使って彼らに教え始める。
私の提案は、@ durosの回答と@Manoj Rの回答の組み合わせです。
最初から、今度は良いコード/ OOP /コメント付きなどを作成することを念頭に置いて、古いコードから参照/コピー＆ペーストしてください。古いコードの悪い部分に遭遇したら、それらを書き直すかリファクタリングしてください。
開発者が十分に訓練されていない場合は、コースに派遣することをお勧めします。急速に変化するIT業界での定期的な再トレーニングにとって重要