11
レガシーコードを引き渡すためのベストプラクティス
数か月後に同僚が新しいプロジェクトに移り、私は彼のプロジェクトの1つを引き継ぎます。準備するために、私はすでにMichael FeathersのLegacy Codeでの効果的な作業を注文しました。 しかし、この本は、私がこれまで見つけたレガシーコードに関するほとんどの質問と同様に、コードをそのまま継承する場合に関係しています。しかし、この場合、私は実際に元の開発者にアクセスでき、秩序あるハンドオーバーのための時間があります。 私が継承するコードの一部の背景： 機能している：既知のバグはありませんが、パフォーマンス要件が上昇し続けるにつれて、それほど遠くない将来にいくつかの最適化が必要になります。 文書化されていない：メソッドおよびクラスレベルでの文書化はほとんどありません。しかし、私は長年そのAPIに対して（ブラックボックスとして）書いてきたので、コードがより高いレベルで行うことになっていることはよく理解されています。 上位レベルの統合テストのみ： APIを介した他のコンポーネントとの適切な相互作用をテストする統合テストのみがあります（再び、ブラックボックス）。 非常に低レベルで速度が最適化：このコードはアプリケーションシステム全体の中心であるため、その多くは長年にわたって数回最適化され、非常に低レベルです（一部には特定の構造体用の独自のメモリマネージャーがあります） /記録）。 コンカレントおよびロックフリー：コンカレントおよびロックフリープログラミングに非常に精通しており、実際にこのコードにいくつかの部分を提供しましたが、これにより複雑さがさらに増します。 大規模なコードベース：この特定のプロジェクトは1万行を超えるコードであるため、すべてを説明する方法はありません。 Delphiで書かれています。この問題を言語に依存しないと信じているので、私はこれをそこに置くつもりです。 彼の出発までの時間をどのように費やすのが最適か疑問に思いました。ここにいくつかのアイデアがあります： マシン上ですべてをビルドする：すべてをソースコード管理にチェックインする必要がありますが、たまにファイルをチェックインすることを忘れていないので、これがビジネスの最初の順序になるはずです。 より多くのテスト：変更を行うときに導入したバグを早期にキャッチできるように、より多くのクラスレベルの単体テストが必要ですが、現在のコードはテストできません（巨大なクラス、長いメソッド、多すぎる相互依存関係）。 何を文書化するか：まず最初に、低レベル/高度に最適化された性質などのために理解するのが難しいコードの領域に文書を集中するのが最善だと思います。見苦しくてリファクタリング/リライトが必要なものがいくつかあるのではないかと心配していますが、実際には私が見逃すかもしれない正当な理由でそこにあった最適化です（Joel Spolsky、Things You Should絶対にしない、パートI） 文書化の方法：いくつかの散文を伴うアーキテクチャのクラス図と重要な機能のシーケンス図が最適だと思います。 誰が文書化するのか：私は彼に文書を書いてもらうか、彼にそれを私に説明してもらうために、何が良いだろうと思っていたので、文書を書くことができます。私は、彼には明らかであるが私ではないものが適切にカバーされないことを恐れています。 ペアプログラミングを使用したリファクタリング：これは時間の制約のために実行できない場合がありますが、多分私は彼のコードの一部をリファクタリングして、物事がそうである理由についての入力を提供するために彼がまだいている間にそれをより保守可能にすることができます。 これにコメントして追加してください。このすべてを実行するのに十分な時間がないため、特に優先順位を付ける方法に興味があります。 更新：引き渡しプロジェクトが終了したので、以下の回答で自分の経験を使ってこのリストを拡張しました。