基本的に構造のないプロジェクトを修正する方法は？

私は、5年以上にわたってほとんどソロでソフトウェアプロジェクトに取り組んできました。始めは混乱でした（私が取り組んでいる3番目または4番目の開発者です）が、混乱は少なくなりましたが、まだ非常に混乱しています。それを制御できるようになるまでの進行速度は氷河期であり、私はそれが現在の状態に落胆し始めていると感じています。

プロジェクトの詳細：これは、ほぼ完全にVisual Basic Classic（VB6）で記述された販売プログラムで、MySQLバックエンドとレポートエンジンがC＃で記述されています。C＃レポートモジュールは、作業するのが楽しいです。過去数年で書かれたばかりで、Crystal Reports 9ですべてのレポートが作成されました（はい、まだ依存しているレポートがいくつかあります）。

ただし、実際のプログラム自体は完全な災害です。LOCの合計は90,000ほどではなく、コメントの行数は10,000になります（ほとんどはドキュメントではなく、コメントアウトされた古いコードです）。158個のフォームファイルと80個のモジュールファイル。プログラムの一部の機能は単純に非推奨になり、（場合によっては）関連するコードをプログラムから削除せずにそのように表記されるため、それらのどれだけが実際に使用されているのかわかりません。実際に生産的に使用されているのはコードの50％だけだと思います。

あいまいなクライアントが依存している何かを壊しているかどうかわからないという理由だけで、多くのコードに触れることを恐れています。コード全体に地雷が散らばっているようなものです。

プロジェクトには実際には構造がありません。私がこれまで改革する忍耐を持っていたいくつかの場所を除いて、それはオブジェクト指向ではありません。フォーム上のデータを取得する必要がある場合は、データベースオブジェクトをインスタンス化し、関数内でクエリを宣言し、それを実行して、データセットで必要な処理を行います。

プロジェクトの作業を開始したとき、使用中のソース管理はありませんでした。私が取り組んでいる他の人々にそれを使用するように奨励しようとしましたが、私は新しい人であり、人々にSubversionを使用させるための私の試みは失敗しました。同社の主任開発者はここ数年でようやく水銀のバグを発見し、すべての開発者が現在すべてのプロジェクトでソース管理を使用していることを確認しました。

プロジェクトの改革にフルタイムで取り組むことができた場合、まともな進歩を遂げることができ、おそらくプロジェクトを完全に改造するのにどれくらいかかるかを見積もることさえできると思いますが、それは積極的に使用されています火を消す、バグを修正する、機能を追加するなどのように常に求められます。

では、どうすればこのプロジェクトを実際に修正し始めることができますか？別の言語でVB6を使用してみませんか？空き時間にプログラムを書き直してみてください。またはこれは完全に絶望的ですか？

更新

この投稿の後、私は熱心にプロジェクトに戻りましたが、そのようなゆっくりした進歩を見た後、数ヶ月以内に絶望に陥りました。それから、このサイクルを来年かそこらでさらに2、3回繰り返しました。

それから別の仕事に移りました。vb6の長年の経験と、他のテクノロジーの周辺経験だけでしたが、検索は難しく、途中で多くの拒否に直面しました（1年間で約12件のインタビュー）。この状況にある他の人への私のアドバイスは、この要素だけを残すことを検討することです。このような行き止まりの位置にとどまることによってあなたのキャリアに与えるダメージを考えてください。

ソース管理になったので、コメントアウトされたコードを取り除くことができます。

私はここで同様の状況で開始しました（ソース管理、実際の構造、イベントハンドラーでほぼすべてが行われる80KLOC VB6アプリ）。

約2年で、私は半分以上をC＃に変換しました（通常、重要な新機能が必要な場合）。すべての新しいC＃コードには、単体テストのカバレッジがあります。ただし、C＃に変換するには時間がかかります。重要な新しいモジュールを追加しない場合は、そのルートをたどりません。

私がしたことの1つは、データベースから自動生成される基本的なデータアクセスレイヤーを作成することでした。少なくとも、テーブルの列名が変更され、コード内のすべての場所が見つからなかったという問題をキャッチしました。また、ビジネスロジックをゆっくりと、フォームイベントハンドラーからモジュールに移動しました。

ただし、アプリケーションは内部のみであるという利点がありました。展開するサイトは1つしかなかったので、あなたよりも大きなリスクを冒すことができました。私が間違いを犯した場合、それを修正することは通常大したことではありませんでした。そんな贅沢はないようですね。

私は本当にあなたの最善の策は次のアプローチを取ることだと思います：

1. 耐え難いほど詳細にすべてを学びます。これにより、不注意で何かを壊す可能性が低くなります。
2. 分離と構造を改善するために容赦なくリファクタリングしますが、オブジェクト指向プログラミングのような新しい方法論を急いで試そうとしないでください。
3. 学習体験として扱います。劣等な方法を見たことがないなら、別の方法がより良いことをどのように知っていますか？
4. 主要なモジュールを作成しない限り、新しい言語/フレームワーク/プラットフォームでの書き換えを気にしないでください。それでも、慎重に検討してください。

プログラムの目標は、会社に利益をもたらす製品になることです。それは完璧な芸術作品である必要はありません（そして私は完璧主義者なので、それを認めるのは本当に難しいです）。時には、プラグマティズムを採用したほうが良い場合があります。

大量のレガシーコードを維持しているCOBOLプログラマがたくさんいると思われます。彼らが新しい言語で書き直そうと狂ったように働いているのではないかと思う。:)

あなたがする必要があるのはリファクタリングです。リファクタリングは、単体テストがなければ、何も壊していないという自信を与えるような状況ではほとんど不可能です。したがって、単体テストの作成から始めます。コードの振る舞いを文書化します-しかし、紙だけではなく、より多くのコードで-単体テスト。テストを実施したら、コードの再構築を開始できます。

デビッド・エイガンの「デバッグ」からの1つのルールが思い浮かびます：考えるのをやめて、見てください。大量のテキストを処理できるマシンを自由に使用できます。これを使用して、使用されなくなったコードを正確に把握し、容赦なく削除します。間違えた場合、それがソース管理の目的です。

それは簡単な部分です。次に考える必要があるのは、象をどのように食べるかです。一度に一口。Martin Fowlerの「リファクタリング」を取り上げて、機能ごと、ファイルごとにそれを実行してください。何かを完全に廃棄して、要件と思われるものから書き直さないでください。登山者のように作業し、次の安全装置が設置されるまで、以前の安全装置を絶対に外さないでください。

まだ十分な比phorがありましたか？重要なのは、関数の名前を変更したり分割したりするだけの多くの改善により、ゆっくりと着実に行うと、長年のデバッグと機能要求によって構築されたコードの良い部分を破壊することなく、コードの悪い部分を改善できることです。コードは常に出荷可能のままにしておきます。より現代的な言語への移植中にそれが可能であれば、それを試してください。

私はそれを言うのは嫌いですが、パッチ/エンハンスの無限のサイクルを続けるだけでなく、何も壊れないことを願っています。あなたが説明しているような非常に多くのVB6プロジェクトを見て、それらをC＃/。NETにリファクタリング/リライト/リドゥしようとすると、ひどく失敗します。

問題は、遅かれ早かれ、ゼロからの完全な書き直しが必要になるということです。VB6とそれをサポートするWindowsバージョンは減少しています。VB6の癖を知っていて、このようなプログラムに積極的に取り組む意欲のある開発者を見つけることはまれになっています。VB6の内部制限は、このような巨大なプログラムで発生し、奇妙なエラーを引き起こします。

この時点で全体、基礎、再設計、および書き直しに対して十分なコンセンサスとコミットメントがある場合は、作業を開始し、進行中のメンテナンスを他の誰か（請負業者、ジュニアプログラマ、あなたに合ったもの）に委任します。人々がまだこれを始めるのに十分に確信していないならば、痛みが十分に大きくなるのを待ってください、さもなければ、より緑の牧草地に移ります。

ここでいくつかの良い答えは、私は一つのことを追加したいと思います。すべてを書き直そうとする代わりに、おそらくそのモジュールの少なくとも一部をほぼ1対1でVB.NETに移植する機会があります（もちろん、これを行うときは非常に注意する必要があります）。私の経験では、このような移植は、既存のすべての機能をゼロから再構築するのに比べて、約5〜10倍少ない労力で実行できます。あなたはそれを移植した後と、その後、あなたはリファクタリングに開始することができます-などの良いユニットテストツール、自動リファクタリングツール、実際のOOPのように、.NETの世界で利用可能なすべてのこれらのツールで

私は同様の状況にあり、古い16ビットC ++プログラム（150k LOC）を32ビットの世界に移行する必要がありました。32ビットの世界では、使用中の元のGUIフレームワークはもう利用できません。書き換えは非現実的であると理解するのに時間がかかりましたが、C ++、C ++ / CLI、C＃を使用して.NETの世界に移植することを決めた後、それを実現するのに約9か月しかかかりませんでした（約1 devそのプロジェクトにフルタイムで取り組んでいます）。また、使用可能なGUIパーツの単体テストはありませんでした。これらのパーツのテストはすべて手動で行いました。

非常に重要なことですが、VB6では非常に難しいアプリケーションの単体テストに重点を置いていますが、Steven McConnellはそのようなプロジェクトに取り組む方法について優れた本を書きました。

それを見てください：

Steven C. MCCONNELL：レガシーコードの効果的な使用、第2版。Microsoft Press、2004年6月。

基本的に、彼のポイントは、少しずつゆっくりとそれを取ることです。彼はまた、何かを壊す可能性が非常に低いリファクタリング技術を使用することから始め、時には短期的にはそれを少し悪化させ、コードがよりクリーンになり、それをサポートする単体テストがあるので、より高度な技術の使用を開始することを推奨します。