大きな書き換えに関与したことがありますか？
Joel Spolsky が彼の有名な投稿の1つで述べています：
ソフトウェア会社が犯す可能性のある1つの最悪の戦略的誤り：コードを最初から書き直す。
チャド・ファウラー が書きました：
ビデオ、ウェブログの投稿、誇大広告を見て、Rails（またはJava、.NET、またはErlang）で製品を再実装することにしました。など）。
注意してください。これは、予想よりも長く、難しく、障害が発生しやすいパスです。
大きな書き換えに関与したことがありますか？
私はこの悲劇的なトピックについてのあなたの経験に興味があります。特に、（もしあれば）正常に完了した大きな書き直しに興味があります。
私は自分の経歴で何度か書き直しに関わっていましたが、それらはすべて惨事でした。同じ理由で失敗する
- 必要な労力の広大な過小評価：誰かが書き換えを必要とするたびに、それは古いシステムが古いテクノロジーを使用しており、保守が難しいためです。彼らが考慮に入れていないのは、その年齢のせいで、30〜40人年の開発努力があるかもしれないということです。その後、5人のチームで6か月ですべてを書き直すことができると考えるのはばかげています。
- 知識の喪失：古いシステムは古くから存在し、多くのことを実行し、すべてに夢中になっています。最新のドキュメントはなく、システムが行うすべてのことを実際に知っている単一の権限ポイントもありません。特定の部門の特定のユーザーに関する知識があり、それらすべてを見つけることは困難または不可能です。
- 不十分な管理決定：私が関わってきた書き換えは、管理から同様の期待を持っていました。新しいシステムは「実行」されるべきであり、古いシステムは特定の日付、期間に単にオフにすることができます。他のオプションは受け入れられませんでした。彼らはこの巨大なプロジェクトのために新しい人々を雇うためにこのすべてのお金を費やしているので、彼らは彼らの頭の中でそれを得ると思います。実際には、より良いリスク軽減戦略は、古いシステムの主要な機能を書き直すことです。たとえば、最初のリリースで古いシステムの50〜75％に取り組み、それがどのように機能するかを確認します。上記の＃1と＃2があるため、見逃されていた機能の一部と、古いシステムを実際にオフにするために必要な機能を確認すると、これはおそらくはるかにうまく機能します。
書き換えのスコープは非常に成功しますifスコープを正しく設定します。これらが "BIG"（TM）プロジェクトのしきい値を満たしているかどうかはわかりませんが、成功した書き換えのいくつかを説明させてください。
プロジェクト1
私が働いていた会社では、棚板印刷システムを使用して、プラノグラムと呼ばれるものから小売店の棚に表示されるラベルを生成しました。プラノグラムは業界標準のソフトウェアで生成され、ツールがそのドキュメントを読み取って、ターゲットストアのテンプレートを使用して棚板を作成します。テンプレートソフトウェアは、いくつかのクラスと3つのDLLにまたがる入れ子になった有限状態マシンの混乱でした。 （当時）特許出願中のペグボードアプローチを実装する時期が来たとき、現在のコードでは、私たちがやりたいことをサポートできないことが明らかでした。
解決策：書き換えのスコープをテンプレートエンジンのみにしました。適切なOO設計を使用して、現在の要件を処理し、新しいペグボードの要件に対応しました。書き換えの時間は1か月でした。ツールチェーン全体で1年以上かかりますが、その必要はありませんでした。
プロジェクト2
私たちのチームがゼロから構築したWebアプリケーションは、元のデザインを超え始めていました。私たちのクライアントには、ユーザーにとってサイトをより良いものにする一連の新しい要件があり、可能であればより「Web 2.0」に準拠しています。既存のデザインを現在のフレームワークに組み込むこともできましたが、メンテナンスは悪夢でした。私たちはアプリケーションを熟知しており、新しいバージョンの一部として、どの部分を前に進めなければならないか、どの部分が廃止されるかを知っていました。
解決策：チームが完了するまでに3か月かかりました。それは簡単なことではありませんでした。最終製品は、エンドユーザーにとってより速く、よりスケーラブルで、より楽しいものでした。私たちはクライアントの期待を上回りました。そうは言っても、残りの半分が新しいシステムで作業している間に、より迅速なバグ修正とバンドエイドパッチが既存のシステムで行われるように、チームを分割する必要がありました。広範なテストを実施し、プロセスの早い段階で組み込みました。これがうまく機能した理由は、このアプリケーションとクライアントをよく知っていたからです。
プロジェクト
ここに失敗を含める必要があります。私たちは、災害/危機的状況で使用するための情報管理ツールを必要とするクライアントをサポートしていました。私たちはJava Swingアプリケーションを継承しました。Swingを真に理解せずに元の開発者が作成したものです。つまり、Swingを処理し、UIを適切に管理するためのSunの推奨事項に従っていないため、結果として無限のイベントループやその他の奇妙で問題の追跡が困難になります。その結果、バグやユーザーインターフェイスの問題などが発生しました。これは非常に複雑なアプリケーションでした。健全性を維持するために、不十分なものを書き直そうとしましたSwingアプリを適切に記述されたSwingアプリに書きます。
解決策：3か月と見積もったところ、約4.5か月で書き換えが完了しました。 UIとアプリケーションが処理できるデータ量の両方で、アプリケーションのパフォーマンスが向上しました。その後、2004年に津波が発生した。彼らが追跡しなければならない人々の数の絶対的な大きさは、Swingが彼らが本当に必要としているものに対して間違ったテクノロジーであることを示していました。私たちはパフォーマンスチューニングに追いつくことができず、彼らは最終的にツールを放棄し、社内にあるOracleチームによって作成された石畳のWebアプリを支持しました。確かに、私たちが当時持っていた知識に基づいて私たちがしたことを正当化することはできましたが、書き換えはあまり積極的ではなく、クライアントに、可能な人数の要件を伝えることに失敗しましたおそらく追跡する必要が低すぎた。
結論
書き換えは必要な場合があり、正しく計画されていれば正常に完了する可能性があります。システム全体の一部を対象にした書き換えを使用すると、全体を書き換える場合よりもさらに効果を上げることができます。最後に、プロジェクトが失敗する原因は、必ずしも書き換え自体であるとは限りません。私たちは千里眼になることはできませんが、いくつかの最悪のシナリオを考え出すことができます。考えられる最悪のシナリオの2倍をサポートするようにシステムを設計する方法を学びました。危機管理システムの場合は、それだけでは不十分でした。実際の数は、与えられた最悪のシナリオの20倍でした。しかし、それは私たちが考えることができる最悪のシナリオではありませんでした。
- 書き換えのための書き換えはあなたの友達ではありません。目に見えない複雑さは常にたくさんあります。また、醜いものはクライアントのトレーニングツールであることがわかります。 常に定期的にクライアントに現在の進捗状況を表示します。これにより、最悪の攻撃を見つけるのに役立ちます。
- Targetedの書き換えは、コードベースの最悪の違反に対処するのに役立ちます。スコープを制限して問題の大部分に対処できる場合は、全体を書き換えないでください。
私はVB6から.NETへのいくつかの書き換えに関与しました。 2つのケースでは、書き換えがスムーズに行われ、予定よりも早く完了しました。他の書き換えは予想よりも時間がかかりましたが、大きな問題はなく完了しました。
私たちの特定のケースでは、リライティングは、当社が下すことができる最悪の決定ではありませんでした。最終結果は実際にはオリジナルよりもはるかに安定しており、はるかに良い場所に私たちを置きました。
既存のシステムを完全に書き換える際の最大の落とし穴の1つは、「新しいシステムで何をする必要があるかを指定する必要がないことです。非常にシンプルです。古いシステムでやっていることを正確に行うだけです！」 。
問題は、ほとんどの場合、古いシステムが何をしているか正確に誰も知らないということです。古いシステムのさまざまなユーザーが機能するはずであると考える方法に従って、新しいシステムを機能させるために無数の時間を費やすことになります。古いシステムの元の要件もおそらく利用できません。
鉱山は「成功」の物語です。私のプロジェクトには、独立して管理/作成された4つのサテライトサイト（さまざまなアプリケーションを持つサブドメイン）を持つプライマリサイトが含まれていました。 4つの主要なユーザーベース（すべて別のアクティブディレクトリ内）があり、共通の認証システムはありませんでした。 3つは定評のあるサイロ化されたアプリケーションであり、4つ目の衛星はまったく新しいものであり、最も確立されたサイトからコードベースの多くをコピーしたものです。
目標： 4つのドメインにまたがるアカウントを認証し、ドメインの1つで（セルフサービスを使用して）アカウントを完全に管理できる企業全体のIDシステムを実装します。 .Netはすでにサテライトに実装されているため、「リードイン」として機能した従来のASPサイトを書き換え、ID管理を追加する必要があり、すべてのサイトでサービスに影響がないことを確認するための回帰テストが必要です。
リソース： 3人の主要アーキテクト-プログラマー、ID管理、プロジェクトマネージャー。約20人の開発者、10人のアナリスト、10人のテスター。
完了までの時間（開始から終了）： 1.5年
起動成功：ほぼ失敗
Longevity Success：すごい
私はID管理アーキテクトだったので、すべてのサテライトが相互作用するデータベース、サブシステム、および論理インターフェースを設計しました。 「プログラマー」アーキテクトは、すべてのサテライトに関する広範なビジネス知識と、その時点までのアプリケーションとその開発の経験を備えた主要開発者でした。
社内のさまざまな部門の50名程度のさまざまな人たちと数か月にわたって要件を収集した後、論理アーキテクチャをなんとかして解決し、コードの作成を開始しました。変更の性質上、私たち自身のウェブサイトとそれに含まれるすべての機能を.Netに書き直す必要がありました。場合によっては、リファクタリングの問題でした。多くの場合、それを取り巻くプロセスの完全な書き直しを伴いました。 2つのケースでは、元の機能を重要ではないとして単に放棄しました。プロセスで2つの期限に間に合いませんでした（しかし、結局、私が提案した当初の期限に達しました-かろうじて）。打ち上げ日には何も機能しませんでした。土曜日にローンチしたため、影響はごくわずかでしたが、丸一日かけてログを調べ、部分を書き換え、サーバーの負荷を評価しました。より多くのテストが役立つかもしれません。より完全なSDLCがさらに役立つ可能性があります（SDLCがありましたが、混合されていました）。
1日目の終わりまでに、すべてのサイトが稼働し、すべてが機能していました（私は名目上の成功と言えるでしょう）。過去2.5年の間に、すべてが素晴らしい成功を収めました。すべてのサイトが共通のフレームワークベースの共通のアーキテクチャ上にあることで、開発とクロス開発者の作業がはるかに簡単になりました。 2.5年前に（私たちの書き換え中に）私がサイトに書き込んだ機能は、それ以来、いくつかの衛星サイロで見られたり採用されたりしています。
ログ記録、ユーザー追跡、稼働時間の増加、認証/承認/識別を担当する単一のアプリケーションを増やしました。サテライトサイロはアプリケーションに完全に集中でき、ID管理アプリケーションに認証/承認の問題が存在することを信頼できます。
私たちのプロジェクトは多くの欲求不満、心痛、そして災害でした。結局、それは成果をあげて、それからいくらか。原則として、Joel Spolskyによる書き換えの評価に100％同意しますが、常に例外があります。書き換えを検討している場合は、それが必要なものであることを確認する必要があります。もしそうなら、それに伴うすべての痛みに備えてください。
私は今、巨大なコードの書き換えに関与しています...唯一の問題は、私がそれに取り組んでいる唯一の問題です！現在のソフトウェアのメンテナンスコストは法外で、多くのバグがあり、1人のFT従業員がメンテナンスを行っているため、独自のソフトウェアを構築することにしました。
予想よりはるかに遅いですが、最終的には独自のコードベースがあり、将来必要な変更を簡単に実装できるようになるので、最終的にははるかに良いと思います（ソフトウェアは、最新の状態に保つために頻繁に変更する必要があります）現在の時間）。また、書き直しの際にデザインにいくつかの大きな変更を加えています。
それはすべて異なります。私の場合、ジョエル・スポルスキーのアドバイスに従い、私は間違っていました。それは保険のウェブサイトに関するものでした。サイトはひどいものでした、そして私がやったこと、そして私がやるべきことはここにあります：
悪い戦略：私は4人の生徒のグループを以下のように監督しました：
- 生徒＃1-データベースアクセス/クエリを書き直して安全にした
- 学生＃2-すべてのCSSを「上」に移動
- 生徒＃3-すべてのページをw3c互換にした
- 生徒＃4-保留中のすべてのバグを解決しました
- 自分自身：すべてのphp警告とくだらないもの（重複するコードなど）を削除
2ヶ月かかりました。その後、サイトを再設計しました。その後、多言語で対応しました。全体として、くだらないコードの大部分を維持する必要があり、データベース構造は同じままでした。だから私はまだ1年間まだらくたなものに取り組んでおり、完全な書き直しを決定するまで完成することはありません。
良い戦略：
- サイト全体を調べて、優れた「製品要件文書」を作成します。
- データベースを適切に再設計する
- 私の独自のフレームワーク（すでに機能している）をゼロから始める
- サイトを再設計しました。
- 多言語を実行します。
かかった時間：2か月（たぶん少ない）。
- 良いコード。
- 良いメンテナンス。
- 生産性。
- 「これはできません。ウェブサイトはそのような製品を扱うことができません」のような答えはありません。
だから、私の最後の言葉：それはすべてあなたが書き直さなければならないものの複雑さに依存します。
投稿を適切な英語に修正することをためらわないでください、ありがとうございました
オリビエポンス
以前の仕事で完全な書き直しに参加しました。そして、私たちはそうしたことをとても嬉しく思いました。たまに、コードベースが非常に腐敗しているために、最初からやり直した方がよい場合があるとしましょう。
これは内部アプリケーションでした-実際、メインのビジネスアプリケーションです。
バージョン2を書いているときは、古いシステムを維持していました。正しく思い出せば、約1年かかりました（2人のプログラマ、3人目のプログラマ）。ただし、データベースに触れる必要はなかったので、少なくともデータの移行は問題になりませんでした。
私は過去3年間、大規模な書き換えを行ってきました。当初、プロジェクトには2年かかると見積もられていました。基本的なアイデアは、ハードウェアの交換、既存のOSの使用、ビジネスロジックの書き換え（cからCPPへ）、新しいIOカードの作成、および新しいUIの作成です。
その過程で、私たちはひどい決定をしました。 CPPの実際の経験はなく、それをうまく教えるメンターもいませんでした。 win32をベースにして、自分でUIフレームワークを構築してみました。ハードウェアは安く、BSPにはバグがありました。ソフトウェアは非常に柔軟性がありましたが、メンテナンスが困難でした。昨年、自社開発のUIを廃止し、.netでUIを開発しました。また、永続化メカニズムとデータ通信プロトコルも完全に書き直しました。
多大な労力を要しましたが、プロジェクトはほぼ終了し、最初のユニットはフィールドでテストされています。このプロジェクトには、成功するために何らかの変更を加えるための大きなリスクがありました。このプロジェクトには良い点がいくつかあり、（VSSの代わりに）SVNを使い始めました。時間をかけてユニットテストを作成し、夜間ビルドを実装しました。また、スクラムを使用してプロセスを改善しました。
振り返ってみると、ビジネスロジックの書き換えは必要なかったと思います。最も醜い部分だけをリファクタリングすればよかったのです。また、UIを最初から作成する場合は、コアビジネスでない限り、UIを作成しないでください。
私が働いていた会社がコードベースの大規模なリファクタリングを始めました。
チームの半分はリファクタリングに取り組み、残りの半分は既存の製品の維持と改善を続けました。
ご想像のとおり、リファクタリングが実際に機能するようになることはありませんでした。これは、継続的に実行されるプロセスであり、実際に表示するものはありませんでした。
アイデアは、リファクタリングされたコードベースの方がうまく機能し、チームが既存の製品に追加した新機能を「導入」して「追いつく」ことができるというものでした。
しかし、それは結局会社の没落となった。
10年以上前、私は彼らの老朽化したコア製品の「再設計」を行うことを決定した会社で働いてきました。それ以来、「再設計」という言葉に言及することは罰せられる違反です。予想よりもはるかに時間がかかり、明らかにコストがかかりました。また、新製品は当初の計画よりもはるかに古い製品に似ていました。
実際、私は大きなリファクタリングを始めています。 4MLocsはおそらく800KLocs以下にダウンサイジングする必要があります。このプロジェクトには、多くのコピーと貼り付け、言語機能の誤解、繰り返しの無駄なコメント、不適切な決定、一時的なハッキング、そしてハッキングの恒久化（回避策を含む）、完全な知識の欠如基本コンピュータサイエンスまたはソフトウェアエンジニアリング。おそらく、32人の悪いプログラマーの保守チームは、リファクタリング後に2人の良いプログラマーに置き換えられます。
私は3週間でブログエンジンを書きました。 8時間で書き直します。
計画を立て直すことは、書き換えを成功させるためのkeyです。内部と外部のシステムを知ることも利点です。