私たちはソフトウェア会社ではありません。完全な書き直しはまだ悪い考えですか？
Joel Spolskyの記事「 あなたがしてはいけないこと、パートI 」の背後にある理由は理解していますが、最終目標がソフトウェアの生産である状況では常にそれが参照されているのを見ます。 eコマースサイトを管理している開発者の場合はどうなりますか？私の仕事は小売プラットフォームを書くことではなく、それを使用することです。実際、これは、そのような書き直しではなく、大きなデータベースとWebデザインの移行です。
私たちのサイトのベースとなっているソフトウェアは、クラシックASPで記述されており、顧客が現在のショッピングサイトに期待する多くの機能が根本的に欠けています。これらの機能を少しずつ追加していくのではなく、よりモダンなプラットフォームへの移行を開始する必要があるというのが私の直感です。何年にもわたって行ったカスタマイズは失われますが、率直に言って、切り替えたいパッケージには、この機能の多くが既に存在します（そしてほぼ確実に実装されています！）。
私はNetscapeの精神の犠牲になっているのでしょうか、それとも、自分のツールが私たちが必要とすることを実行させる以外に、自分の時間を他の場所で費やすほうがいいと思うのですか？
明確に言うと、これはブログプラットフォームを切り替えることと同じです。私が行う「開発」とは、基本的にはWebサイトのフロントエンドを書き換えることですが、バックエンドは私の制御の範囲外です。
WordPress=開発が何年も前に停止していて、コメント、静的ページ、パーマリンクなどの「モダン」機能が欠落していたとしましょう。確かに、これらのものを追加するプラグインを作成できましたが、しばらくして、プラットフォームを、最初からそれらの（必要な）機能がすべて組み込まれたものに切り替える方がいいのではないでしょうか。
アップグレードする前に...
以下の場合にのみ、それは良いアイデアになるでしょう。
- itあなたの顧客が要求した機能を追加します、
それ現在のソリューションの既存の機能を失わないでください。
（一部のユーザーはそれらを形成するように求めます、そしてあなたが小さな会社である場合、顧客を残すことは非常に高価です-そして波を始めるかもしれません）
それは、非表示/非表示の要件と副作用を追加しません。
- それには環境制約がありません（またはそれらを計算で考慮します）、
- 新しいターゲットミドルウェアが積極的に開発され、サポートされています。
- あなたは慎重に以下のコストを検討します（そして、その後比較的短期的な利益を確認します）：
- 開発、
- 展開、
- トレーニング、
- メンテナンスとサポート
- メンテナンスとサポート
- メンテナンスとサポート。
現在よりも保守が難しくないことを確認してください。
さらに、あなたは現在のテクノロジーについて言及しますが、何に移行したいのかを伝えます。テクノロジーを変更すると、さらに危険です。
アップグレードを決定した場合...
必ず：
- backupあなたのデータ、
- ビジネス復旧計画をリハーサル...：
- to現在の作業ステータスに戻すには、問題が発生した場合にできるだけ早く、
- to顧客とのコミュニケーション（失敗した）移行と問題、およびそれらのデータのステータスについて。
アップグレードする場合（可能であれば）、繰り返し実行してください！
- データベースを更新するか、新しいデータベースを作成します。
- データをコピーしてください。
- バックアップを定期的に更新して、最新のコピーで作業します、
- 古いコピーをバックアップする（安全に暗号化されるなど...）
- 別の環境で開発する、
- 多くの内部テスト、
- 信頼できる顧客のフォーカスグループを使用したテスト。
ミドルウェアの完全な切り替えが必要な場合は、これらの2つのソフトウェアソリューション間の移行の成功事例がないかどうかを確認し、他の人が行ったことと、彼らが遭遇した落とし穴と問題点を注意深く読んでください。
品質のリファクタリングと監視
乱雑なコードについてのみ（またはほぼ完全に）である場合は、しないでください。代わりに：
- コメントされていない汚いコードを整理する方法 に関する私の回答を読んでください（特定のコードスニペットだけでなく、より大きなコードベースにも適用され、推奨される資料が役立つかもしれません！）
- 時間とともにrefactor
- 連続積分および連続検査システムを使用してモニター品質とリファクタリングの影響、
- そして、顧客に連絡して、不足している機能を明確に尋ね、顧客ごとに非常に健全なビジネスケースを構築して、小規模な改善プロジェクトに価値があるかどうかを確認します。
開発にはコストがかかり、メンテナンスはさらに必要です。特別な理由がないものをビルドすることはユーザーに喜ばしいことですが、メンテナンスとサポートが必要になることを忘れないでください。
また、ソフトウェア会社ではない場合、開発中および展開後にこのタスクをサポートする十分な訓練を受けたスタッフがいますか？スタッフの一部がタスクの途中で去った場合はどうなりますか？
ジョエル・スポルスキーが書いた失敗したプロジェクトは主要な事業でした。彼が提供したいくつかの例では、書き換えの成功の例がいくつかあります。
- Mac OS X
- Windows NT
現在、Windowsは複数回書き換えられており、そのたびに、変更が十分に受け取られるかどうかに関係なく、ヒットまたはミスされます。たとえば、NTはWindowsをエンタープライズ（以前はUnixが住んでいた）で使用できるようにしたことでヒットしました。一方、Vistaはほとんど受け入れられていませんでした。しかし、どちらの場合も、マイクロソフトは賭けをヘッジしました。
Spoelskiの主張は、ソフトウェアの書き換えは非常に危険な命題であるということです。プロジェクトの複雑さが増すにつれて、リスクは指数関数的に高まります。
Brooksとmake 1を捨てるコメントの対置点は、何かの最初のバージョンが学習プロセスであることです。それを学習プロセス以上のものとして扱うことを試みることによって、あなたは長い間、悪いコードに身を固めるでしょう。 Pragmatic Programmerおよび他の多くのソースでは、悪い決定をクリーンアップするための小さなリファクタリングは少ない全体の書き換えよりも危険です。
さて、あなたの状況であなたはあなたの前の選択肢を見る必要があります。次の課題があります。
- 現在のソフトウェアは古いプラットフォームに基づいています
- 新しいプラットフォームは、現在のプラットフォームで発生した問題をより完全に、より完全に解決します
- プラットフォームの変更は危険です
- 書き換えには計画が必要、または書き換えが失敗する失敗
書き換えを検討する前に、いくつかの質問に自分で答える必要があります。
- このソフトウェアはすでに寿命が近づいていますか？（つまり、有効期間が限られている場合、プラットフォームの変更に関連するコストとリスクは価値がないかもしれません）
- ソフトウェアは単純ですか？ソフトウェアが大きいほど、または複雑になるほど、できることは多くなりますそして意志うまくいかない。
- ターゲットプラットフォームは必要なすべてを実行できますか？これを評価するには、疑わしいことだけを実行して、それが可能かどうかを確認するだけの価値があります。それは可能かもしれませんが、あなたが今持っているものと同じくらい醜いです。決定を下した後よりも、制御されたテストで調べる方が良いでしょう。
- 顧客がリリース間でどれくらい待つことができますか？完全な書き換えが同じリリースサイクルで（またはより迅速に）実行できる場合、それはおそらく簡単です。しかし、ほとんどの顧客はあなたの問題を気にせず、あなたの問題を彼らの問題と見なしていません。あなたは完全な書き直しをしている間、彼らは待ちたくないでしょう。
私はこの演習を2回以上行っており、書き換えを支持することもあれば、現状維持を支持することもありました。何度か、アプリの一部だけを書き直した場合、顧客に価値を提供しながら、苦痛を大幅に軽減できることを発見しました。
段階的に移行
ゼロから書き直さないことのポイントは、不安定な仕様、暴走するバグリストなどによって製品全体を台無しにするリスクがあり、作業に表示できるものが何もない状態で費やす時間/コストが難しいことです。正当化する。
既にASPを使用しているので、サイトの新しい部分をASP.NETに実装し、古いページを更新しながら徐々に新しいフレームワークに移動することをお勧めします。私たちはこれをレガシー製品で行い、18か月以上で完全に移行しましたが、顧客の需要に対応するために2、3週間ごとにアップデートを出荷することができました。
完全な書き換えの全体的な考え方は、既存のコードのどこにも価値のあるものはなく、単一のものではないということです。実際、アイデア全体に欠陥があり、地球から削除する必要があります。
私の経験では、これはめったに当てはまりません。通常、これは時代遅れであり、時代遅れではないプラットフォームへの移行を介してペイントの新しいコートを与える必要があります。以前のアプリケーションはほぼすべて、学習行動と最適化の化石層を表しています。これらは、機能的なピークに到達するための段階的な改善の層を重ねています。このプロセスは危険にさらされても無視してください。
あまりにも頻繁に私は、人々が「完全な書き直し」にコミットし、その後、長年の運用で収集したレッスンや改善を組み込まずに、アプリケーションをその改善サイクルの1日目に書き直しているのを見ています。はい、そのようなものは、他の点ではクリーンなコードベースにひどく悪質になっていますが、元のコードベースでは不十分だったために存在しました。はい、書き直しますが、元のアイデアから欠けていることが判明したものを組み込みます。最高のソフトウェアはこのようにして生まれます。下位のリリースで学んだ教訓をより完全なリリースに組み込むことによって。
これはです書き換えを行うことは悪い考えであるという従来の知識。そして正当な理由で。完全な再書き込みは一般に悪い考えであり、しばしば見事に失敗します。
しかしアドバイスを述べるより良い方法は...「完全に書き直すことは常に良い考えである場合を除いて、常に悪い考えです」。
yourアプリケーションに最適なものについてのあなた（またはあなたのチーム）の個人的な判断を従来の知識に置き換えないでください。従来の知識の単純なビットは、all状況には適用できず、適用されません。書き直しが必要かどうか、他のユーザーが提供する警告に留意して、自分で評価するのはあなた次第です。 あなたほどあなたのアプリケーションとプロジェクトの目標について知っている人はいません。
完全に書き直しているように聞こえない、既存の機能をすでに実装している新しいプラットフォームにビジネスを移行している、ということは、まったく新しいシステムを完全に書き直すよりもはるかに健全ですアップ。頑張れ！ ...そして、バックアップ計画、リカバリ計画があることを確認し、移行を何度もリハーサルしてテストし（適切な分離されたテスト環境で）、新しいプラットフォームでユーザビリティテストを実行します。
多くのビジネスは、あるプラットフォームから別のプラットフォームに移行しています。私のCOBOLメインフレームシステムから移行している金融会社があり、それは単なるデータベースとUIデザインの移行よりもはるかに大きいことを知っています。しかし、それも不可欠です。
問題は、どの戦略が「最良」であるかについてです。ここでの応答からわかるように、両方に長所と短所があります。では、どうやって決めるのですか？私の答えは、適切なリスク分析を行う必要があるということです。また、結果を2つのレベルで比較検討する必要があります。それは、短時間の視点と長い視点の2つです。これは、システムまたは製品の予想寿命に関係しています。それはすべて、最も経済的なルートを取ることに要約されます。そのためには、関連するコスト（リスクの観点から）のコストとリスクの量（時間）を知る必要があります。これは簡単な作業ではありませんが、知識に基づく推測ではなく、有効なビジネス上の意思決定を行う場合に実行する必要があります。
カテゴリーの答えに注意してください。
ジョエルのアドバイスに反して、私は書き換えの支持者です。これは主に、フラットアウトの誤りであるシステムが多すぎて、あまりにも長い間「間違った」処理が行われていたためです不可能修正する必要があるすべてのものをリファクタリングする。そして、私は「すべて」を意味します。データベースは古く、コードは貧弱で、再利用できません。古いHTML/CSSを使用するまでです。何かがそれほど悪い場合、リファクタリングは、漏れやすいパイプをダクトでテーピングするようなものです。 /ある時点で交換する必要があり、後で交換するよりも早く交換することで、時間と費用を節約できます。私は「書き換えは悪である」というマントラに従うことの影響を直接見てきましたが、最終的にはシステムがクラッシュし、見事にクラッシュし、会社を破産させました。誰もそのことを見ることができなかったからですだったひどいし、書き換えが唯一の節約の恵みだったでしょう。
OPの質問に答えるために、サイトが将来にわたって持続可能ではない場合、サポートされなくなった非常に古いテクノロジを使用している場合（人々に維持するのを困難にする）、リライトを検討するときがきました。ソフトウェア会社であるかどうかは、何を保存するか（ [〜＃〜] longterm [〜＃〜] 、短期的な思考の罠;システムを停滞させ、そもそも失敗させるのはその落とし穴です！）書き換えを行うことによって、末期状態のシステムを維持するための追加の手荷物を上回るでしょう。
厄介なJava Struts Webアプリケーションで同様の問題に直面しています。サイト全体をすぐに書き直す予定ですが、既存のコードの拡張を止めることはできません。代わりに、より良いアーキテクチャで、古いページに触らなければならないとき、または緊急のタスクがないときに、古いページを移行します。