5

最近、私は「強化」するために仕事でビジネスクリティカルなプロジェクトを継承しました。このコードは、過去5年間にわたって作成され、多くの人に渡されてきました。もはや会社にいないコンサルタントとフルタイムの従業員は、この非常に繊細で非常に機密性の高いアプリケーションを破壊しました。私たちのほとんどは、レガシーコードまたはこのタイプのプロジェクトに対処する必要があります...開発者であることの一部です...しかし...

ゼロユニットとゼロシステムテストがあります。ロジックは、ストアドプロシージャ、ビュー（はい、ビューと言いました）、およびコードの間で混ざり合っています（理由もなく複製されることもあります）。ドキュメンテーション？そうだね。怖いです。はい、最小限の「微調整」またはリファクタリングを行うことは非常に神聖です。1つの小さな事故、そして私の雇用主にとって大きな収入の損失と潜在的な法的問題があるでしょう。

それで、何かアドバイスはありますか？私の最初の考えは、既存のコードに対してアサーション/単体テストを書き始めることです。ただし、ストアドプロシージャには多くのロジックが組み込まれているため、これまでのところしかできません。（ストアドプロシージャをテストすることは可能ですが、ソースコードロジックの単体テストと比較すると、歴史的にはるかに困難です）。別のまたは追加のアプローチは、アプリケーションが関数を実行する前後のデータベースの状態を比較し、コードを変更してから、データベースの状態を比較することです。

4

7 に答える 7

3

エンタープライズ ファイル システムの最も複雑なサブシステムの数千行をマルチスレッド化するために書き直したので、これはすべて経験に基づくものです。書き直しが正当である場合 (機能を大幅に強化するために書き直しが行われている場合、または既存のコードがより多くの機能強化を行うことを妨げている場合)、次のポインタがあります。

  1. これを行うには、まず自分の能力に自信を持つ必要があります。これは、関連するテクノロジーについて十分な経験がある場合にのみ得られます。

  2. コミュニケーション、コミュニケーション、コミュニケーション。関係するすべての利害関係者に、これは混乱している、リスクが高い、急いで行うことはできない、少しずつ行う必要がある、一度に 1 つの領域を攻撃する必要があることを知らせてください。

  3. システムを徹底的に理解する。すべてのニュアンス、トリック、ハックを文書化します。全体的な設計を文書化します。正当化できないコードが存在する歴史的な理由について、古参の人に尋ねてください。これらは踏みたくない地雷です。これらは役に立たないコードだと思い、後でそれらを取り除いた後に後悔するかもしれません。

  4. 単体テスト。既存のテスト スイートを使用してシステムを動作させます。存在しない場合は、まず既存のコードのテストを記述します。

  5. 書き換え中にデバッグコードをいたるところに吐き出します-アサート、ログ、コンソール出力（それらをオンまたはオフにする機能が必要であり、出力のさまざまなレベルを指定する、つまり冗長性を制御する必要があります）。これは私の経験では必須であり、書き直しの際に非常に役立ちます。

  6. コードを確認するときは、実行する必要があるすべてのことのリストを作成します - 調べる必要があること、テストを作成する必要があること、質問する必要があること、一部の部分をリファクタリングする方法を思い出させるためのメモコードの書き直しに影響を与える可能性のあるものはすべて...何も忘れることはできません! 私はこれを Outlook タスクを使用して行います (使用するものが常に目の前にあることを確認してください。これは、机に座ってすぐに開く最初のアプリです)。中断された場合は、考えていたことをすべて書き留めて、タスクに戻った後にどこから続行するかのヒントを示します。

  7. 書き換え時にハックを避けるようにしてください (これが書き換える理由の 1 つです)。あなたが遭遇する難しい問題について考えてみてください。それらについて他の人と話し合い、あなたのアイデアを彼らにぶつけて (これに勝るものはありません)、明確な解決策を提示してください。todo リストに入れているすべてのタスクを見てください。既存の設計の 10,000 フィートの写真を作成してから、新しいリライトがどのようになるか (モジュール、サブモジュール、それらがどのように組み合わされるかなど) を決定します。

  8. 他のどの問題よりも先に、最も困難な問題に取り組みます。これにより、トンネルの終わり近くで解決できない問題に遭遇するのを防ぎ、後退するのを防ぐことができます。もちろん、最も困難な問題が何であるかを知る必要があります。繰り返しますが、既存のコードに進出する際には、最初にすべてを文書化することをお勧めします。

于 2010-01-10T06:01:29.830 に答える
2

@Sudhanshu の素晴らしいリストを超えた 2 つのこと (そして、ある程度、彼の #8 に反対するもの):

最初に、テストされていないコードはバグのあるコードであることに注意してください。「変更されていないコードと同じように機能する」以外の「正しい」の定義については、ほとんどの場合、最初から正しく機能しません。つまり、システム内の予期しない動作を見つけ、その動作についてシステムの専門家に質問し、システムが本来の方法で機能していないと結論付けられるように準備してください。テストやその他のドキュメントがなければ、彼らが思っているように機能すると考える理由はないことを警告してください。

次へ:簡単にできる成果のリファクタリング 気楽に、ゆっくり、慎重に。コード内の簡単な部分 (重複など) に注目し、重複を含むメソッドを完全にテストしてから、それを削除します。泡立てて、すすぎ、繰り返します。変更を行う前にすべてのテストを作成するのではなく、変更するすべてのテストを作成します。このようにして、すべての段階でリリース可能な状態を維持し、継続的に価値を追加し、コード ベースを継続的に改善します。

「2 つのこと」と言いましたが、3 つ目を追加すると思います。それは、期待を管理することです。この仕事がどれほど怖いかを顧客に知らせてください。彼らが持っているものがどれほど悪いかを彼らに知らせてください。進捗がどれだけ遅くなるかを知らせ、その進捗状況を知らせ続けることを伝えます (そしてもちろん、それを行います)。あなたの顧客は、「ほんの少しの修正」を求めていると思うかもしれません - そして機能は実際には少ししか変わらないかもしれません - しかし、それはそれが多くの仕事と多くの時間ではないという意味ではありません. あなたはそれを理解しています。あなたの顧客もそうする必要があります。

于 2010-01-10T18:33:30.620 に答える
2

私は以前にこの問題を抱えていて、（スタックオーバーフローの時代の前に）周りに尋ねましたが、この本は常に私に勧められていました. http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

于 2010-01-10T18:38:33.293 に答える
2

  1. 要件の非常にしっかりしたリストを取得します。

  2. 暗黙の要件と明示的な要件があることを確認してください。つまり、どのプログラムでどのように動作する必要があるかを確認してください。

  3. 現在どのように使用されているかについて、すべてのシナリオとユース ケースを記述します。

  4. 単体テストをたくさん書く。

  5. 多くの統合テストを作成して、プログラムと連携する必要がある既存のプログラムとの統合をテストします。

  6. プログラムを使用しているすべての人に話しかけて、より暗黙的な要件を見つけてください。

  7. 本番環境に移行する前に、変更をテスト、テスト、テストします。

  8. CYA :)

于 2010-01-10T02:59:58.137 に答える
1

DB 部分と非 DB 部分を分離して、DBA がストアド プロシージャとデータベース自体に挑戦し、システムの他の部分で作業できるようにすることは可能ですか? これは、アプリケーションのその部分をステップアップして引き受けることができる DBA が存在することも前提としています。

それが不可能な場合は、コードベースがどれくらい大きいかを確認し、支援が得られるかどうかを確認することをお勧めします。これは責任の回避と見なされる可能性がありますが、ポイントは、物事が時々消えてしまう可能性があるため、通常は 1 人の手に委ねるべきではないということです。

幸運を！

于 2010-01-12T18:03:59.890 に答える
1

あなたは、法的な収入の損失とドキュメントがないため、コードに触れるのが怖いとおっしゃいました。それで、あなたはコードを理解していますか？最初にすべきことは、それを文書化し、リファクタリングについて考える前に、それを理解していることを確認することです. それを実行して問題領域を特定したら、最小の変更で最大の利益の順にリファクタリングの提案のリストを作成し、それを段階的に攻撃します。リファクタリングは、コードの寿命が長く、新しい機能が追加され、バグ修正が多数ある場合に、さらに意味があります。データベースの状態をテストすることに関しては、私は最近プロジェクトに取り組み、まさにそれを成功させました。

于 2010-01-10T04:29:09.800 に答える
1

これを自問してください：あなたは何を達成しようとしていますか？あなたの使命は何ですか？どのくらい時間がありますか？成功の尺度は何ですか？どのようなリスクがありますか? それらをどのように緩和し、対処しますか？

達成しようとしていることを理解していない限り、何にも触れないでください。

コードは「悪い」かもしれませんが、それはどういう意味ですか? コードは正しく動作しますか? 同じことをするようにコードを書き直すと、コードが同じことをするように途中でバグを導入する何かを書き直すのに多くの時間を費やしたことになりますか? 何のために？

あなたができる最も簡単なことは、システムが何をするかを文書化することです。そして、私は、誰も読まない気が遠くなるような Word 文書を書くという意味ではありません。つまり、重要な機能に関するテストを作成し、必要に応じてそのようなテストを作成できるようにコードをリファクタリングします。

于 2010-01-10T03:03:00.783 に答える