基本的に構造のないプロジェクトを修正するにはどうすればよいですか？
私は5年以上、主にソロでソフトウェアプロジェクトに取り組んできました。それは最初はめちゃくちゃでした（私はそれに取り組んでいる3番目または4番目の開発者です）。それはめちゃくちゃではありませんが、今でも信じられないほど混乱しています。それを制御下に置くことの進歩の速度は氷河期であり、私はそれが入っている状態に落胆し始めています。どうすれば実際にそれを修正し始めますか？
プロジェクトの詳細：これは、ほぼ完全にVisual Basic Classic（VB6）で記述された販売プログラムであり、MySQLバックエンドとレポートエンジンがC＃で記述されています。 C＃レポートモジュールは作業する喜びです。このモジュールは過去2、3年で書かれたばかりで、その前にすべてのレポートがCrystal Reports 9で行われていました（そうです、それに依存するいくつかのレポートがあります）。
しかし、実際のプログラム自体は完全な災害です。 LOCの合計は9万件とは限らず、約10万行のコメントがあります（ほとんどがドキュメントではなく、コメント化されている古いコードです）。 158のフォームファイルと80のモジュールファイル。プログラムのいくつかの機能は単に非推奨になり、（ええと、時々）プログラムから関連するコードを削除せずにそのように示されるため、それらのどれが実際に使用されるのかわかりません。コードの50％だけが実際に生産的に使用されていると思います。
1つのあいまいなクライアントが依存している何かを壊しているかどうかわからないからといって、多くのコードに触れるのは怖いです。それは、数え切れないほどの頻度で起こります。コード全体に地雷が散らばっているようです。
プロジェクトには実際には何の構造もありません。これまで私が改革に忍耐を持っていたいくつかの場所を除いて、それはオブジェクト指向ではありません。フォーム上のデータを取得する必要がある場合は、データベースオブジェクトをインスタンス化し、関数内でクエリを宣言し、それを実行して、データセットで行うことを行います。
私がプロジェクトに取り組み始めたとき、使用中のソース管理はありませんでした。自分が取り組んでいる他の人にそれを使うように励まそうとしましたが、私は新しい人で、人々にSubversionを使わせようとする試みはすべて失敗しました。同社の主任開発者は、ここ数年でようやくMercurialのバグに遭遇し、現在、すべての開発者がすべてのプロジェクトでソース管理を使用していることを確認しているため、少なくともある程度は進歩しています。
フルタイムでプロジェクトの改革に取り組むことができれば、まともな進歩を遂げることができ、プロジェクトを完全に変えるのにどれくらいの時間がかかるかさえ予測できると思いますが、それは積極的に使用されており、絶えず火を消したり、バグを修正したり、機能を追加したりするなど、常に尋ねられます。
では、どうすればこのプロジェクトを本当に修正し始めることができるでしょうか？ VB6を別の言語でツール化してみませんか？暇なときにプログラムを書き直してみませんか？またはこれは完全に絶望的ですか？
更新
この投稿の後、私は熱意を新たにしてプロジェクトに戻りましたが、そのような遅い進捗率を見てから数か月以内に絶望的な状態に戻りました。その後、このサイクルを来年かそこらに2、3回繰り返しました。
その後、別の仕事に移りました。何年ものvb6と、他のテクノロジーでのペリフェラルの経験だけがあった後、検索は困難でしたが、途中で多くの拒絶に直面しました（1年間で約12のインタビュー）。このような状況にある他の人への私のアドバイスは、この要因だけに任せることを検討することです。このような行き止まりの位置に留まることによってあなたのキャリアに与えることができる損害を考慮してください。
ソース管理になっているので、コメント化されたコードを削除できます。
私はここで同じような状況で開始しました（ソース管理なし、実際の構造なし、ほとんどすべてがイベントハンドラーで実行される80KLOC VB6アプリ）。
約2年後には、半分以上がC＃に変換されました（通常、重要な新機能が必要な場合）。すべての新しいC＃コードには、単体テストのカバレッジがあります。ただし、C＃への変換には明らかに時間がかかります。重要な新しいモジュールを追加しないのであれば、私はその道を歩みません。
私がしたことの1つは、データベースから自動生成される基本的なデータアクセス層を作成することでした。少なくとも、テーブルの列名が変更され、コード内のすべての場所が見つからないという問題が発生しました。また、ビジネスロジックをフォームイベントハンドラーからモジュールにゆっくりと移動しました。
ただし、アプリケーションが内部専用であるという利点がありました。展開先のサイトは1つしかなかったので、あなたよりも大きなリスクを負う可能性があります。私がミスをした場合、それを修正することは通常大したことではありませんでした。そんな贅沢はないようですね。
私はあなたの最善の策は次のアプローチを取ることだと本当に思います：
- 耐え難いほど詳細に少しずつ学びます。これにより、誤って何かを壊す可能性が低くなります。
- 分離と構造を改善するために容赦なくリファクタリングしますが、VB6はそれを吸収するだけなので、オブジェクト指向プログラミングのような新しい方法論をそこに入れようとしないでください。
- それを学習体験として扱います。劣った方法を見たことがないなら、どのようにして別の方法がより良いと思いますか？
- 作成する主要なモジュールがない限り、新しい言語/フレームワーク/プラットフォームで書き直さないでください。それでも、慎重に検討してください。
プログラムの目標は、会社に利益をもたらす製品になることです。それは完璧な芸術作品である必要はありません（そして私は完璧主義者なので、それを認めるのは本当に難しいです）。時々、実用主義を採用する方が良い場合があります。
大量のレガシーコードを維持しているCOBOLプログラマーがたくさんいると思われます。彼らがみんな新しい言語でそれを書き直すのに熱心に取り組んでいるとは思えません。 :)
あなたがする必要があるのはリファクタリングです。何も壊していないという確信をあなたに与えるユニットテストなしでは、このような状況ではリファクタリングはほとんど不可能です。したがって、単体テストの作成から始めます。ユニットテストのコードの動作を文書化します。テストを実施したら、コードの再構築を開始できます。
David Aganの " Debugging "のルールの1つが思い浮かびます。あなたはたまたま、大量のテキストを処理できるマシンを自由に利用できます。これを使用して、使用されなくなったコードを正確に把握し、容赦なく削除します。間違えた場合、それがソース管理の目的です。
それは簡単な部分です。次に考える必要があるのは、どのように象を食べるかです。一度に一口。 Martin Fowlerの " Refactoring "を取得し、ファイルごとに機能ごとに実行します。何かを完全にスクラップして、要件と思われるものから書き直さないでください。登山家のように作業し、次の安全装置が設置されるまで、以前の安全装置を取り外さないでください。
まだ十分な比喩はありましたか？重要なのは、ゆっくりと着実に進めれば、関数の名前の変更や分割などの多くの改善が行われ、何年にもわたるデバッグと機能のリクエストを通じて構築されたコードの良い部分を破壊することなく、コードの悪い部分を改善できることです。 。コードを常に出荷可能にしておく必要があります。より現代的な言語への移植中にそれが可能であれば、それを試してください。
私はそれを言うのが嫌いですが、パッチ/エンハンスメントの無限のサイクルを続け続けることを超えて、「完全に絶望的」に行き、何も壊れないことを願っています。あなたが説明したようなVB6プロジェクトが多すぎて、C＃/。NETにリファクタリング/書き換え/やり直そうとする試みがひどく失敗し、多くの場合、その試みの担当者が解雇されました。
遅かれ早かれ、根本からの完全な書き直しが必要になるということです。 VB6とそれをサポートするWindowsのバージョンは減少傾向にあります。 VB6の癖を知っていて、このようなプログラムに積極的に取り組む開発者を見つけることは、ますます少なくなっています。このような巨大なプログラムではVB6の内部制限に達し、奇妙なエラーが発生します。
この時点で、全体、根拠、再設計、および書き直しに対する十分なコンセンサスとコミットメントがある場合は、作業を開始し、進行中のメンテナンスを他の誰か（請負業者、ジュニアプログラマー、あなたに役立つもの）に委任します。人々がこれを始めるのにまだ十分に確信していない場合は、痛みが十分に大きくなるのを待つか、緑の牧草地に移動してください。
ここで良い答えがいくつかあります。1つ追加したいと思います。すべてを書き直そうとする代わりに、おそらくそのモジュールの少なくとも一部をVB.NETに1：1で移植する機会があるでしょう（もちろん、これを行うときは非常に注意する必要があります）？私の経験では、このような移植は、既存のすべての機能をゼロから再構築するよりも5〜10倍少ない労力で実行できます。そして、移植した後はthenリファクタリングを開始できます-優れた単体テストツール、自動リファクタリングツール、本当のOOPなど.
私も同じような状況で、古い16ビットC++プログラム（150k LOC）を32ビットの世界に移行する必要があり、使用されている元のGUIフレームワークはもう利用できませんでした。書き換えが非現実的であることを理解するのに少し時間がかかりましたが、C++、C++/CLI、C＃を使用して.NETの世界に移植することを決定した後、それを実現するのに約9か月しかかかりませんでした（約1 dev）そのプロジェクトにフルタイムで取り組んでいます）。また、GUIパーツの単体テストはありませんでした。これらのパーツのテストはすべて手動で行いました。
アプリケーションのユニットテストに重点を置いていますが、VB6では非常に重要なことですが、Steven McConnellはそのようなプロジェクトへの取り組み方について優れた本を書いています。
それを見てください：
Steven C. MCCONNELL：レガシーコードの効果的な使用、第2版。 Microsoft Press、2004年6月。
基本的に、彼のポイントは、少しずつゆっくりと服用することです。彼はまた、何かを壊す可能性が非常に低い、場合によっては短期間で少し悪くなるリファクタリング手法を使用することから始め、コードがよりクリーンになり、それをサポートする単体テストがあるため、より高度な手法の使用を開始することをお勧めします。