要件がなく、責任者がすぐに退職する大規模なコードベースを処理する方法
私は次のシナリオに直面しており、皆さんがこれに取り組む方法についていくつかのヒントを持っているかどうか疑問に思います。
同僚の1人が数か月で会社を辞めようとしています。彼が使用したテクノロジは古くなっているので、私は彼のアプリケーションのrewriteを実行するように指示されます。問題は、要件がなく、コードベースが文書化されていないソースの約25万行であり、アプリケーションが何をするかを知っているのは彼だけである（顧客は関心のある部分だけを知っている）です。私はとにかく私が書き換えをしているので、彼がまだここにいる間に最初に彼と一緒に要件を書くことを考えましたが、これが最善のアプローチであるかどうかわかりません。
これに最善のアプローチをする方法と、彼が会社に残っている時間を最大限に活用する方法についてのヒントはありますか？
よろしくお願いいたします。
ピーター
更新：
アプリケーションはそれほど複雑ではなく、250k行は、すべて古いVBAスクリプトであるためです。最新のライブラリと言語機能（C＃）を使用するだけで、locsを少なくとも50％削減できます。古いアプリケーションをマップし、古いコードベースをまったく使用しないという要件を取得することを考えています。 「書き換え」が「新規書き込み」であるかのように。これが良い考えかと思っているところです。 レガシーコードの処理方法を知っています。私の質問は、まったく処理しなくても済むようにできるかどうかです。
いくつかの古いVB6アプリケーションを.NETフレームワークに移植しましたが、すべてドキュメントがほとんどなく、その経験からいくつかの推奨事項を提供できます。まず、VB6を取り除くことは私見の正当な目標ですが、古いVBAコード（VBAプラットフォームとしてExcelまたはWordを使用）を取り除くことが価値がある場合、私は議論の余地があります。プラットフォーム。
とにかく、あなたが本当にこの道を進んでいるのであれば、以下の点を強くお勧めします：
1。代わりに書き直さないでください：port！
あなたが書いた "最新のライブラリと言語機能（C＃）を使用するだけで、locsを少なくとも50％削減できます（C＃）"。これにより、経験豊富な開発者であっても、私が何度も目にした典型的なエラーをすでに行っていて、変更しないと失敗しますあなたの戦術。 50％がtrueである場合でも（これはIMHOの方法では楽観的すぎます）、これらの50％のコード行を元のコードと同じくらいバグのないものにする時間を過小評価します。私の経験では、プログラムを本当に最初から書き直すと、1：1の方法でプログラムを移植するよりも約10倍遅くなります。 Eric Nelsonによるこの古いブログ投稿 も参照してください。 Joel Spolskyの有名な書き換えに関するブログの投稿 も必ずお読みください。
移植とは、変更を最小限に抑えた元のソースコードを新しいプラットフォームに持ち込むことを意味します。これについては、C＃は「クールな」言語であると確信している場合でも、C＃を使用しないでくださいVB.NETを使用してください。 。事実は、C＃とVB.NETはほぼ同等に強力であり、MSによって同等にサポートされていますが、VB.NETは古いVB6またはVBAプログラムからの移植ターゲットとしてはるかに適しています。移植により、古いコードのすべての文書化されていない詳細を理解していなくても、ほんのわずかな新しいバグで、ほとんどのプログラムを新しい環境に正しく転送できます。
また、古いプログラムが現在使用しているものに非常に類似している、より古く成熟したライブラリが利用可能な場合は、「モダンライブラリ」を使用しないことをお勧めします。たとえば、VB6 GUIをWinformsに移植する方が、WPFを使用してGUIを書き換えるよりも桁違いに簡単です。そして、DAOやADO=などのライブラリは、Windowsでも引き続き利用できます。非常に異なるADO.NETにすぐに切り替える必要はありません。新しいライブラリに切り替えると、本当にメリットがあると思うなら、これを後で行います-古いプログラマーの知恵に従います-最初にそれを正しくし、次にそれを素敵にします。
2。参照データを生成するための古いプログラムを使用して、これが理にかなっているすべての箇所に対して適切な回帰テストスイートを構築し、事前に構築してください！
レガシーコードの全体的な目的 を知らなくても、これは実現できます。移植を開始する前にこれを2回以上行いましたが、予期しないバグが発生することを何度も回避でき、間違いなく初期の作業でした。
3。小さなステップでの移植を計画し、本番環境の古いプログラムの一部をできるだけ早く新しいものに交換してください。
250KのLOCでは、ビッグバン方式で古いプログラムを新しいプログラムに置き換えるnoチャンスがあると確信しています。もちろん、増分置換を行う方法は、古いプログラムの構造とそれがサポートするユースケースに大きく依存しますが、そのサイズのプログラムでは、交換して個別に展開できるパーツを見つける可能性が高くなります。 DotNetスタックは、.Net言語を使用したCOMコンポーネントの簡単な開発など、移行をよりスムーズにするためのいくつかの機能をサポートしています（移植済みのパーツの代わりとして古いVBAプログラムに埋め込むことができます）。
移植して本番環境に導入したすべてのパーツが
古いコードと新しいコードを並行して維持する必要がない部分
新しいテクノロジースタックとの相性についてユーザーから貴重なフィードバックが得られる部分。これにより、コードの次の部分をより正確に移植し、残りの作業をより正確に見積もることができます。
彼らが書き換えを望んでいる理由を見つけてみてください。完全に書き直すだけでは意味がありません。時間がかかり、バグが多くなります。また、ほとんどの書き換え作業が失敗することも指摘してください。
書き換える正当な理由があります。修復できないハードウェアを使用する場合、または全体的なコストを下げるためにアーキテクチャを変更する場合。
とはいえ、現在のソフトウェアをリファレンスとして使用し、古いソフトウェアと書き換えの両方に対して実行できるテストスイートを作成して、書き換えが同じように動作することを確認します。
理想的には、できる限り小さな部分を書き直したいと思います。このようにして変更を分離し、書き換えが進行している間もサービスを提供し続けることができます。
しないでください。
「時代遅れのテクノロジー」による書き直しは良い考えに思えるかもしれませんが、そうではありません！
毎年、新しくてクールなテクノロジーがやって来ます。数年後、誰もがそれを時代遅れだと考えます。
毎年コードベースの基盤を変える人の一人になりたいですか？または、テクノロジーの古さを欠点とは考えずに、十分にテストされたテクノロジーに基づいてコードを作成する人になりたいですか？
テクノロジーが物事を行う方法に根本的に欠陥があるという正当な理由がある場合、コードを少しずつ書き換えることで価値を見出すことができます。毎回、コードの一部を維持する必要があり、その部分を最初から書き直します。
次回、プロジェクトで外部テクノロジーを使用する必要がある場合は、必要最小限の機能を公開するラッパーを通じてそれらにアクセスすることを検討してください。このようにして、技術的根拠が古くなったと判断した場合、ラッパーを書き換えることができます。アプリケーション全体を書き直す必要はありません。
アプリケーション全体を引き継ぐように設計され、適切に設計されたラッパーを介してアクセスするのが難しいように設計されているテクノロジーがある場合、The One True Frameworkであると主張します。なぜなら、One True Frameworkはそうではなく、薬物の使用と同じくらい多くの問題を引き起こすからです。
だから、私のアドバイスは：
- 大きな書き換えが悪い考えである理由を上司に説明してください。
- 代替ソリューション、増分書き換えを提案する
- テクノロジーの時代が、自動的に悪化しない理由を説明する
- ラッパーを介して外部テクノロジーにアクセスする利点を説明する
- The One True Frameworkであると主張するテクノロジーの欠点を説明する
あなたの上司は、書き直しを段階的に行う必要があることに同意します。上司はおそらく、コードが書き直されるときに、今年の新しくてクールなテクノロジーに直接アクセスしないことを理解するでしょう。代わりに、ラッパーを通じて十分にテストされた古いテクノロジーにアクセスします。そのため、十分にテストされた古いテクノロジーにアクセスするため、おそらくラッパーを書き直す必要はありません。ただし、その場合、ラッパーはそのまま残り、アプリケーション全体を書き換えるのではなく、ラッパーだけを書き換えることができます。
上司が同意しない場合に備えて、時間の見積もりを提供します。スキルレベルとコードの複雑さに応じて、書き換えに1〜10年かかります。非常に熟練したプログラマーは、月に2万行の非常に単純なコードを記述できるため、見積もりが低くなります。ただし、熟練度が低く、コードが単純でない場合は、1か月あたりのコードが2000行になることもあります。実際、バグバスティングの場合、この数値はさらに低くなる可能性があり、1か月あたり200行のコードとなる可能性があります。
幸運を。
上司に明確にする最初のことは、関係する時間枠です。 250,000行のコードを書き換えると、何年もかかります。彼らはこれを理解していますか？しかし、アプリケーションには誰も気にしないことがあり、誰も知らない機能があるかもしれないので、時間を節約できます。
時間枠について上司に同意します。そして、あなたは書き直すことはできませんが、アプリを少しずつ変更することができます。そのため、お客様と一緒に座って、要件の最初のビットを見つけ、それらの要件を実装するアプリの部分を交換してから、次のビットを実行できます。
上司がそれがどれほどの作業であるかを理解していなかった場合を除き、プロジェクトは中止されます。
PS。いくつかの実用的な発言：
要件があります。 250,000行の要件があります:アプリケーションの動作が変更された場合、ユーザーが非常に不満を感じることを保証できます。
「大きな書き換え」-まったく新しいアプリケーションを最初から作成することを意味します-は失敗します。既存のアプリを少しずつ変更して、ユーザーが常に機能するアプリを持っているようにします。
古い開発者との時間を使用して、問題なくアプリケーションをビルドできることを確認します。彼が去る前に、あなたは真新しいマシンを手に入れ、それに必要なすべてのソフトウェアをインストールし、すべてのソースをダウンロードし、ビルドボタンを押すとそれがビルドできるはずです。展開プロセスについても同じです。その男のマシンでのみ動作するビルドスクリプトをいじったり、ひどい場合はその男のマシンで---（existのみのビルドスクリプトをいじったりしたくはありません。
最も重要なことは、既存の250,000行のソースコードを、異なるプログラミング言語で可能な最新のコードと組み合わせ、それらを共存させる方法を理解することです。
開発に関して、あなたの会社には、250K LOCコードベースよりもはるかに大きな緊急の問題があるようです。この場合、正しいことは次のとおりです。
（ゼロからの）書き換えは絶対に避けてください。
これがひどいアイデアであることを雇用主に理解させるようにしてください。
あなたの質問は、あなたがこの混乱に対処するだけであることを暗示しているようです。これは、障害とバーンアウトの設定です。 OOクラスあたり平均100行のコードを含むコードベースでは、サイズが250K LOCである2500クラスが必要です。レガシーシステムがOO through-そして、他の人が指摘したように、あなたが一流のコーダーであったとしても、その書き直しにはまだかなり長い時間が必要です。雇用主が十分な忍耐力を持っている場合にのみ機能します（年単位で測定） 。
書き換え中に古いコードベースにパッチを適用して更新するように求められます（経営陣は常にそれが起こらないと言っているので、私たちは皆それが起こることを知っています）。リソースの制約があるため（1を参照）、適切なドキュメントやテストなしにこれらの変更を適用する必要があります。これにより、解決するよりも多くの問題が発生し、古いコードベースへのすべての変更に予想よりも時間がかかるため、クロールまでの書き換えが遅くなり、期限に影響します。
この古いコードベースにはドキュメントがありません。テストもないのではないかと思います。これはそれ自体悪いことですが、かつての責任ある開発者がドアを開けると、ドメインの知識が彼らと一緒になります。ドメインに関する知識やテストスイートのセキュリティがないため、変更を加えると新しいバグやリグレッションが発生する可能性が高くなります。これもあなたを遅くすることに貢献します。
このサイズの作業に必要な時間枠を正確に見積もることは、できれば非常に困難です。あなたからの正確な見積もりがない場合、経営者はおそらくあなたがコードを見ていないときにのみ意味がある完全に不合理な時間枠を課そうとするでしょう。
可能な場合は、特性評価テストのスイート（仕様/要件としても機能します）の構築を支援するよう同僚に依頼してください。そこから段階的に書き直してください。
テストを実行できる別の環境が必要です（本番環境に対して特性テストを実行しないでください！）が、これを行う利点は次のことができることです。
- 単一のコードベースに変更を配信し続ける（コンテキストの切り替えを少なくする）。
- 必要なドメイン知識を同時に取得します。
- 不可能なタスクへのコミットを避けます。テストの助けを借りて、アプリケーションのリライトとリファクタリングパーツのほとんどの時間を費やすことができます。スイート。機能や現在のバグに取り掛かっても大したことはありません。特性テストを変更し、レガシーコードを変更します。それが終わったら、リファクタリングを続行できます。おそらく、導入したばかりの機能または修正したバグに関連するモジュールから始めます。
また、件名に関する特定の本/記事への参照がある場合に与えられるリンクされた/関連する質問およびその他の回答を見てください（つまり、レガシーコードの操作とリファクタリング）。
最後に、あなたはあなた自身のためにいくつかの質問をしたいと思うかもしれません（そしておそらく会社の利益も）：
- 企業が1人の開発者に250K LOCの「所有」を許可するのはなぜですか？
- なぜ彼らはこの開発者を維持しようとしないのか（またはできないのか）。
- なぜ彼らはこれから何かを学ばないのですか？
それらはすべて私の本の赤旗です。あなたの管理との推論が失敗した場合は、履歴書を更新することを検討してください。
要件は、現在のアプリケーションの動作にエンコードされます。
コードを読んで実験し、現在の動作のドキュメントを作成します。理解できないことについては、元の開発者に説明を求め、ソースコードに直接説明コメントを追加してください。
レガシーコードの処理方法を知っています。私の質問は、コードをまったく処理する必要がないことから逃れることができるかどうかです。
いいえ、ごめんなさい。要件は古いソースコードでエンコードされており、どこにも文書化されていないため、レガシーコードを出発点として使用する方法はありません。あなたはhaveを掘り下げて、好きであろうとなかろうとそれに慣れます。
要件は元の開発者を念頭に置いてある程度存在する可能性がありますが、人間の記憶は誤りがあり、その記憶から要件を文書化しようとすると、重要なポイントを簡単に忘れてしまいます。