BIG Rewriteに参加したことがありますか？[閉まっている]

ジョエル・スポルスキーは、彼の有名な投稿の1つで次のように述べています。

ソフトウェア会社が犯す可能性のある最悪の戦略的ミスは、コードをゼロから書き直すことです。

チャド・ファウラーはこう書いた：

ビデオ、ウェブログの投稿、誇大広告を見たことがあるので、Rails（またはJava、.NET、Erlangなど）で製品を再実装することにしました。

気をつけて。これは、予想よりも長く、困難で、失敗しやすいパスです。

BIG Rewriteに参加したことがありますか？
この悲劇的なトピックについてのあなたの経験に興味があります。特に、（もしあれば）成功裏に完了した大きな書き直しに興味があります。

私は自分のキャリアの中でいくつかの書き直しに関与してきましたが、それらはすべて災害でした。同じ理由ですべて失敗すると思う

• 必要な労力の過小評価：誰かが書き直したいときはいつでも、それは古いシステムが古いテクノロジーを使用していて、維持するのが難しいからです。彼らが考慮していないことは、その年齢のために、30-40人年の開発努力がそれにあるかもしれないということです。5人のチームで6か月で全体を書き直すことができると考えるのはばかげています。
• 知識の喪失：古いシステムは長い間使用されてきたため、多くの処理を実行し、すべてに夢中になります。最新のドキュメントはなく、システムが実行するすべてのことを実際に知っている単一の権限ポイントもありません。特定の部門の特定のユーザーには知識があり、それらをすべて見つけることは困難または不可能です。
• 不十分な管理決定：私が関与した書き直しは、管理から同様の期待を持っていました。新しいシステムは「完了」する必要があり、古いシステムは特定の日付、期間に単純にオフにすることができます。他のオプションは受け入れられませんでした。彼らはこの巨大なプロジェクトのために新しい人を雇うためにすべてのお金を費やしているので、彼らは頭の中にこれを持っていると思います。現実には、より良いリスク軽減戦略は、古いシステムの主要機能を書き直し、最初のリリースで古いシステムの50〜75％に取り組み、それがどのように機能するかを確認することです。上記の＃1と＃2のため、見逃された機能のいくつかと、古いシステムを実際にオフにするために必要なものを見つけるので、これはおそらくはるかにうまくいくでしょう。

リライトは、スコープを正しく設定すると非常に成功する可能性があります。これらが "BIG"（TM）プロジェクトのしきい値を満たしているかどうかはわかりませんが、より成功した2つの書き換えについて説明します。

プロジェクト1

私が働いていた会社では、棚板印刷システムを使用して、プラノグラムと呼ばれるものから小売店の棚に表示されるラベルを生成していました。プラノグラムは業界標準のソフトウェアで生成され、当社のツールはそのドキュメントを読み取り、ターゲットストアのテンプレートを使用してシェルフストリップを作成します。テンプレートソフトウェアは、いくつかのクラスと3つのDLLにまたがるネストされた有限状態マシンの混乱でした。（その後）ペグボードを行うための特許出願中のアプローチを実装するときが来たとき、現在のコードは私たちがやりたいことをサポートできないことは明らかでした。

解決策：書き換えの対象をテンプレートエンジンのみにしました。適切なオブジェクト指向設計を使用して、現在の要件を処理し、新しいペグボードの要件に対処しました。書き換えの時間は1か月でした。ツールチェーン全体を全面的に書き直した場合、1年以上かかりましたが、それを行う必要はありませんでした。

プロジェクト2

私たちのチームが一から構築したWebアプリケーションは、元のデザインよりも大きくなり始めていました。私たちのクライアントには、ユーザーにとってサイトをより良くし、必要に応じて「Web 2.0」に準拠する新しい要件のスイートもありました。既存の設計を現在のフレームワークに靴磨きすることもできましたが、メンテナンスは悪夢でした。私たちはアプリケーションをよく知っていて、新しいバージョンの一部として、どの部分を前に持っていく必要があり、どの部分がなくなるのかを知っていました。

解決策： チームの完成には3か月かかりました。簡単ではありませんでした。最終製品は、エンドユーザーにとってより速く、よりスケーラブルで、より楽しいものでした。クライアントの期待を上回りました。ただし、既存のシステムでより迅速なバグ修正とバンドエイドパッチを行い、残りの半分は新しいシステムで作業できるように、チームを分割する必要がありました。広範なテストを実施し、プロセスの初期段階で組み込みました。これがうまくいった理由は、このアプリケーションとクライアントをよく知っていたからです。

プロジェクト3

ここに失敗を含めなければなりません。災害/危機の状況で使用するための情報管理ツールを必要とするクライアントをサポートしていました。元の開発者がSwingを完全に理解せずに作成したJava Swingアプリケーションを継承しました。つまり、Swingを処理してUIを適切に管理するというSunの推奨事項に従わなかったため、無限のイベントループやその他の奇妙で追跡が難しい問題が発生することになります。その結果、バグ、ユーザーインターフェイスの問題などが多く含まれていました。これは非常に複雑なアプリケーションでした。正気を保つために、私たちはよく書かれていないSwingアプリを、よく書かれたSwingアプリに書き直そうとしました。

解決策： 3か月と見積もった約4.5か月で書き換えを完了しました。UIおよび処理できるデータ量の両方で、アプリケーションのパフォーマンスが向上しました。その後、2004年に津波が発生しました。彼らが追跡しなければならなかった人数の膨大な数は、Swingが本当に必要なものにとって間違ったテクノロジーであることを示しました。パフォーマンスチューニングに追いつくことができず、最終的には、彼らが社内にいたOracleチームによって作成された、丸石で結ばれたWebアプリを優先してツールを放棄しました。確かに当時の知識に基づいてやったことを正当化することはできましたが、書き直しは十分に積極的ではなかったため、追跡する必要がある可能性のある人数の要件もクライアントに伝えることができませんでした低い。

結論

書き換えが必要な場合があり、正しく計画すれば正常に完了することができます。システムの一部を対象にしたリライトを使用すると、ホールセールのリライトよりもさらに向上できます。最後に、プロジェクトが失敗する原因は、必ずしも書き換え自体ではありません。千里眼になることは決してありませんが、最悪のシナリオを思いつくことができます。考えられる最悪のシナリオの2倍をサポートするようにシステムを設計することを学びました。危機管理システムの場合、それだけでは十分ではありませんでした。実際の数値は、与えられた最悪のシナリオの20倍でした。しかし、それは考えられる最悪のシナリオではありませんでした。

• 書き換えのための書き換えはあなたの友達ではありません。目に見えない複雑さは常に多く、見苦しいものはクライアントのトレーニングツールであることがわかります。 最悪の攻撃をキャッチできるように、常に現在の進捗状況を定期的にクライアントに表示してください。
• ターゲットベースの書き換えは、コードベースの最悪の違反に対処するのに役立ちます。範囲を制限して問題の大部分に対処できる場合は、全体を書き直さないでください。

私はVB6から.NETへのいくつかの書き直しに関与しました。2つの場合、書き換えはスムーズに進み、実際に予定より早く終了しました。他の書き換えは予想よりも時間がかかりましたが、大きな問題なしで完了しました。

私たちの特定のケースでは、書き直しは当社が下すことができる最悪の決定ではありませんでした。最終結果は実際にはオリジナルよりもはるかに安定しており、私たちをはるかに良い場所に置いています。

既存のシステムを完全に書き換える際の最大の落とし穴の1つは、「新しいシステムが行うことを指定する必要はありません。非常に簡単で、古いシステムが行うことを正確に行うだけです！」 。

問題は、おそらく古いシステムが何をするのか誰も正確に知らないことであり、古いシステムのさまざまなユーザーがそれを動作させるべきだと考える方法に従って新しいシステムを動作させるのに無数の時間を費やすことです。古いシステムの元の要件もほとんどの場合利用できません。

私のものは「成功」の物語です。私のプロジェクトには、独立して管理/記述された4つのサテライトサイト（異なるアプリケーションを含むサブドメイン）を持つプライマリサイトが含まれていました。4つのプライマリユーザーベース（すべて個別のアクティブディレクトリ内）があり、共通の認証システムはありませんでした。3つは定評のあるサイロ化されたアプリケーションであり、4つ目の衛星は真新しく、最も確立されたサイトからコードベースの多くをコピーしていました。

目標： 4つのドメインでアカウントを認証し、1つのドメインで（セルフサービスで）アカウントを完全に管理できるエンタープライズ全体のIDシステムを実装します。.Netは既にサテライトに実装されているため、「リードイン」として機能する従来のASPサイトを書き直し、ID管理を追加する必要があり、すべてのサイトはサービスに影響がないことを確認するための回帰テストが必要です。

リソース：プログラマー、ID管理、プロジェクトマネージャーの3人の主要なアーキテクト。約20人の開発者、10人のアナリスト、10人のテスター。

完了までの時間（開始から終了まで）： 1 . 5年

打ち上げ成功：ほぼ失敗

長寿の成功：素晴らしい

私はID管理アーキテクトであったため、すべてのサテライトが相互作用するデータベース、サブシステム、および論理インターフェイスを設計しました。「プログラマー」アーキテクトは、すべてのサテライトに関する広範なビジネス知識と、それまでのアプリケーションとその開発の経験を持つリード開発者でした。

私たちの会社のさまざまな部署から50人ほどの人々が集まって数ヶ月の要件を収集した後、論理アーキテクチャをなんとかしてコードを追い出し始めました。変更の性質のため、私たちは自分のWebサイトと.Netに含まれていたすべての機能を書き直さなければなりませんでした。場合によっては、単にリファクタリングの問題でした。多くの場合、それを取り巻くプロセスの完全な書き換えが含まれていました。2つのケースでは、元の機能を重要ではないと単純に放棄しました。私たちはプロセスの2つの期限を逃しました（しかし、私が提案した当初の期限に間に合いました-かろうじて）。起動日には何も機能しませんでした。土曜日に開始したため、影響はごくわずかでしたが、丸1日かけてログを調べ、断片を書き換え、サーバーの負荷を評価しました。より多くのテストが助けになったかもしれません。

初日の終わりまでに、すべてのサイトが稼働し、すべてが機能していました（名目上の成功だと思います）。過去2.5年間にわたり、すべてが大成功を収めています。すべてのサイトを共通のフレームワークベースを持つ共通のアーキテクチャ上に置くことで、開発とクロス開発者の作業がはるかに簡単になりました。2.5年前（書き換え中）にサイトに書き込んだ機能は、その後、いくつかのサテライトサイロで見られ、採用されました。

ロギング、ユーザートラッキング、アップタイムの増加、認証/承認/識別を担当する特異なアプリケーションを増やしました。サテライトサイロは、アプリケーションに完全に集中でき、ID管理アプリケーションに認証/承認の問題が存在することを信頼できます。

私たちのプロジェクトは多くのフラストレーション、心痛、災害でした。最終的に、それはいくつかの成果を上げました。私は一般的なルールとしてのジョエル・スポルスキーの書き換えの評価に100％同意していますが、常に例外があります。書き換えを検討している場合は、絶対に必要なものであることを確認する必要があります。もしそうなら、それに付属するすべての痛みに備えてください。

私は今、大規模なコードの書き換えに関与しています...唯一の問題は、私がそれに取り組んでいる唯一の人です！現在のソフトウェアのメンテナンスコストは非常に高く、多くのバグがあり、1人のFT従業員がそれをメンテナンスしているため、独自のビルドを行うことにしました。

予想よりはるかに遅いが、最終的には独自のコードベースがあるため、将来的に必要な変更を簡単に実装できるため、はるかに優れていると思う現在の時間）。また、デザインを書き換える際に、デザインに大きな変更を加えています。

以前の仕事で完全な書き直しに参加しました。そして、私たちはそうしてとても幸せでした。時々、コードベースが非常に腐敗しているので、もう一度やり直したほうが良いと言ってみましょう。

実際には、メインアプリケーションである内部アプリケーションでした。

バージョン2を書いたとき、古いシステムを維持しました。正しく思い出せば、約1年かかりました（2人のプログラマ、3人目のプログラマ）。ただし、データベースに触れる必要はなかったため、少なくともデータの移行は問題ではありませんでした。

それはすべて依存しています。私の場合、ジョエル・スポルスキーのアドバイスに従いましたが、間違っていました。それは保険のウェブサイトについてでした。このサイトは恐ろしいものでしたが、ここで私がやったこと、それから私がすべきでした：

悪い戦略：私は4人の学生のグループを監督しました：

• 学生＃1-データベースへのアクセス/クエリを書き直して安全にします
• 学生＃2-すべてのCSSを「上」に移動しました
• 学生＃3-すべてのページをw3c互換にしました
• 学生＃4-保留中のすべてのバグを解決しました
• 自分：すべてのPHP警告とくだらないものを削除しました（コードの重複など）

2か月かかりました。次に、サイトを再設計しました。それから多言語でやりました。全体として、不正なコードの大部分を保持する必要があり、データベース構造は同じままでした。だから、私は今も一年間、くだらないものに取り組んでおり、完全な書き換えを決定するまで、それは決して終わりません。それは実際には起こりません。

良い戦略：

• サイト全体を調査し、適切な「製品要件文書」を作成します。
• データベースを適切に再設計する
• 私の独自のフレームワークでスクラッチから始めてください（すでに動作しています）
• サイトを再設計しました。
• 多言語を行います。

かかっていた時間：2か月（おそらくそれ以下）。

• 良いコード。
• 良いメンテナンス。
• 生産性。
• 「これはできません。ウェブサイトはそのような製品を処理できません」のような答えはありません。

それで、私の最後の言葉：それはすべてあなたが書き直さなければならないものの複雑さに依存します。

英語を正しくするために投稿を修正することをheしないでください、ありがとうございました

オリビエ・ポンス

私が働いていた会社がコードベースの主要なリファクタリングを開始しました。

チームの半分はリファクタリングに取り組み、残りの半分は既存の製品の維持と改善を続けていました。

ご想像のとおり、リファクタリングは実際に何かが機能するようになることはありませんでした。それは、それ自体で表示するものがまったくない継続的な進行中のプロセスでした。

アイデアは、リファクタリングされたコードベースを使用する方が良いことであり、チームが既存の製品に追加した新しい機能を「ドロップイン」して、「追いつく」ことができます。

しかし、結局それは会社の没落でした。

私は過去3年間、大きな書き直しをしてきました。元のプロジェクトは2年かかると見積もっていました。基本的なアイデアは、ハードウェアの交換、既存のOSの使用、ビジネスロジックの書き換え（cからCPPへ）、新しいIOカードの作成、新しいUIの作成です。

途中で、いくつかのひどい決定を下しました。CPPに実際の経験はなく、それをうまく指導するメンターもいませんでした。win32に基づいて自分でUIフレームワークを構築してみました。ハードウェアは安価であり、BSPにはバグがありました。ソフトウェアは非常に柔軟でしたが、保守が困難でした。昨年、私たちは自家製のUIを捨て、.netでUIを開発しました。また、永続化メカニズムとデータ通信プロトコルを完全に書き直しました。

多大な労力を要しましたが、プロジェクトはほぼ終了し、最初のユニットは現場でテストされました。このプロジェクトには、成功するための変化をもたらすための大きなリスクがありました。このプロジェクトには前向きなことがいくつかありました。（VSSの代わりに）SVNを使い始め、ユニットテストを書くのに時間をかけ、ナイトリービルドを実装しました。また、より良いプロセスのためにスクラムの使用を開始しました。

振り返ってみると、ビジネスロジックの書き直しは必要なかったと思います。最もmostい部分だけをリファクタリングするべきでした。また、UIをゼロから作成する場合は、コアビジネスでない限り実行しないでください。

実際、私は大きなリファクタリングを始めています。4MLocはおそらく800KLoc以下にダウンサイジングする必要があります。このプロジェクトには、多くのコピー＆ペースト、誤解された言語機能、多くの繰り返しの無用なコメント、不適切な決定、一時的なハッキング、および永続的なハッキング（回避策を含む）、コンピューターサイエンスまたはソフトウェアエンジニアリングの基本原則に関する完全な知識の欠如があります。おそらく、32人の不良プログラマのメンテナンスチームは、リファクタリング後に2人の優秀なプログラマに置き換えられます。

3週間でブログエンジンを作成しました。8時間で書き直しました。

リライトを成功させるには、事前に計画することが 重要です。システムの内外を知ることも有益です。

10年以上前に、老朽化し​​たコア製品の「再設計」を行うことを決めた会社で働いてきました。それ以来、「再設計」という言葉に言及することは処罰の対象となります。予想よりもはるかに長い時間がかかり、明らかにコストがかかりました。また、新製品は当初の計画よりも旧製品にはるかに似ていました。