3

他の人のソフトウェア プロジェクトを引き継ぐ必要があるときの経験を知りたいです。元のソフトウェア開発者がすでに辞任している場合はなおさらです。

4

5 に答える 5

5

私たちがこれまでに達成した最大の成功は、すべてを「ウィキ」化したことです。通知期間中は、退職する開発者に、チーム/会社の wiki ですべてを文書化するのを手伝ってもらい、セクションを説明するレビューを行いながら、彼/彼女と一緒にコード レビューを行い、コードにコメントを追加できるかどうかを確認してください。「引き継ぐ」開発者が、離脱者の監督の下でコードにコメントを書き込むのに最適です。

于 2008-09-24T06:37:39.163 に答える
3

私はかつて、外注から蒸し暑いがらくたの山を引き渡されたチームに参加しました。元のプロジェクト (Java、Struts、Hibernate|Oracle に基づくマルチメディア コンテンツ マネージャー) は、適切に構成されていました (2 人ほどの作業、ペア プログラミング、設計パターンの賢明な使用、いくつかの単体テストのようです)。その後、別の誰かがプロジェクトを継承し、延々と機能をコピー アンド ペーストし、ビジネス ルールを緩和し、パッチを適用し、次のような精巧に作成されたコードを持つ巨大なスパゲッティ モンスターになるまで分岐しました。

List<Stuff> stuff = null; 
if (LOG.isDebugEnabled())
{
    stuff = findStuff();
    LOG.debug("Yeah, I'm a smart guy!");
    for (Stuff stu : stuff)
    {
        LOG.debug("I've got this stuff: " + stu);
    }
} 
methodThatUsesStuff(stuff);

他の素晴らしい創意工夫の中に隠されています。

私は忍耐強いリファクタリング (メソッドとクラスの抽出を頻繁に行う) によって獣を飼いならし、時々コードにコメントを付け、コードベースが 30% 縮小するまですべてを再編成し、時間の経過とともにますます管理しやすくなりました。

于 2008-09-24T10:35:47.327 に答える
3

プロジェクトを引き渡す前に元の開発者が去ったケースは常に最も興味深いものです。コードベースが不明な状態で立ち往生しています。私がいつも興味をそそられるのは、新しい開発者がコードの設計がいかにひどいものであるかについてコメントするために最善を尽くす方法です。ことわざは常にOld dev == bad devです。皆さんはどう思いますか: 私はこれを公式の悪い慣行と呼んでいます: 私たちの前にいた人たちの悪口.

私はできるだけ実用的なアプローチをとろうとしています: コードベースを学び、少し歩き回ります。明確な最初の関係がまったくない場合でも、要件とコードの間の関係を理解するようにしてください。彼らが何かをした理由がこのように行われたか、またはそのように行われたかを理解する「あはは」の瞬間が常にあります。何かが間違った方法で実装されていると確信している場合は、可能であればリファクタリングを行ってください。そして、変更できないコード部分を分離します。モッキング フレームワークを使用して単体テストを行います。

メンテナンス開発者へようこそ。

于 2008-09-24T07:08:12.833 に答える
1

何度か、品質の異なる他の人のコードを引き継がなければなりませんでした。したがって、ヒント：

  • 利害関係者の名前、ビジネス ルール、コード、ドキュメントの場所など、重要な情報を最初から構造化されたメモを取るように努めてください。必要に応じてページを切り取ることができるように、新しいスパイラル ノートを専用にすることをお勧めします。

  • 市場で入手可能な優れた無料のインデックス作成ツールとデスクトップ検索ツールのいずれかを利用します (Google デスクトップ サーチ、MS Windows サーチで十分です)。すべてのドキュメント、電子メール、コードの場所をそれに追加します。

  • 何かを開発する前に、文書分析を行います。ネットワークや印刷された文書で電子的に手に入れることができるものをすべて見つけ、単にそれを読む努力をしてください。未完成の草稿の中にも、役立つ情報が驚くほどたくさんあります。

  • コード、アーキテクチャなどをマインド マップします。

  • 文書化と保守が不十分なシステムでは、先延ばしモードに陥る可能性のある絶望的な瞬間が必然的に発生します。特に、頭が消化しなければならない新しい情報の量が圧倒的に多い最初の数日または数週間は. このようなときは、気楽に、まず重要なことに集中し、飛躍するのではなく、理解を得るために小さな一歩を踏み出すことに戻るように思い出させてくれる (または自分でやってみる) 人がいるとよいでしょう。

  • メモを取り、図を作成し、豊かな絵を描き、マインド マッピングを続けます。ほとんどが整理されていない大量の新しい情報を消化するのに本当に役立ちます。

へい、頑張って！

于 2008-09-29T14:50:21.407 に答える
0

実際には、プロジェクトを引き継ぐために存在しなければならない特定の「成果物」のセットがあります。

機会があれば、最初にプロジェクトを開発しているグループ内に私たちのメンバーの 1 人を押し込もうとします。そうすれば、私たちのグループがコードを引き継ぐ前に、直接の知識を得ることができます。（@Guyが書いた行で）

そうは言っても、私にとって最も重要な部分は次のとおりです。

  • コードが何をするかのある種の高レベルの概要（描画？）。
  • 実際にコードを書いた人に簡単に質問できる

これは、コードとプロジェクトを引き継ぐときのアルファオメガです。

于 2008-09-24T06:56:09.883 に答える