いつ書き換えるべきですか？
可能性のある複製：
BIGが答えを書き換えるのはいつですか？
Joel Spolskyの有名な（または悪名高い）記事 絶対にすべきでないこと、パートI で、彼は次の理由により、書き換えを行うことは常に間違った動きであると主張しています。
- それは自動的にあなたを後ろに置きます（あなたの競争相手/スケジュール/など）
- コードはおそらくプログラマーが信じているほど悪くはありません（他の誰かが書いたものは常に混乱していますが、他のものよりも大きな混乱があります-そしてそれでも）
- ゼロから書き直すよりも、実際に何が問題なのかを修正する方が、おそらくより/より////より簡単です。
- ゼロから書き直す場合、以前のバージョンで修正されたバグを元のコードに再導入することになるでしょう。
代わりに、コードの問題を修正することをお勧めします。
私はこれが彼の投稿の良い要約だと思います、そして私はそれが一般的に真実であると仮定します。
チームの一連のルール/ガイドラインを収集しようとしています。そのうちの1つ（Joelの記事に基づく）は
We don’t re-write ... ever!
- But we can refactor large portions of the code.
(this exception takes care of ugly/problematic code issues)
出てきた質問の1つは、「テクノロジーが変更され、古いバージョンのサポートが得られなくなった場合はどうなりますか」です。これは、私がSisyphean Upgradeパスと考えているものです。
たとえば、OracleがSQL * Forms 2.x/3.xからForms 6i以降に移行したとき、古い.inp形式で独自に開発されたフォームは、現在のバージョンのOracleおよびOracle Formsではサポートされていませんでした。
そのため、サポートされていないツールでサポートされていないデータベースを使用するか、フォームを最初から書き直すか（またはサードパーティのツールで変換してから、細かい櫛でやり直した）かを選択できました。これを移植と呼びます。特に、新しい技術への関数ごとの変換を機能ごとに追加せずに忠実に行ごとに行っている場合はそうです。
その後、ルールは次のようになりました。
We don’t re-write ... ever!
- But we can refactor large portions of the code.
- And we can port the code to a new platform when we *truly* have no other
choice.
（そして、実際には、移植の2倍のコストで問題から抜け出すことはできません）
私が見逃した他の例外はありますか？
ジョエル・スポルスキーが吐き出したと強く主張するように...
あなたは文字通りそれを取るべきではありません！
彼は一般的な問題と一般的な状況について劇的な議論を描くのが好きですが、現実の世界と同様に、どんなに小さくても常に灰色の領域があります。
彼は人々に考えさせ、私が完全に同意する「書き直しハッピー」であることへの嫌悪感を生み出すつもりです。書き換えの状況の95％はそれを保証しませんが、もちろん、「私たちのクライアントはLinuxサーバーに移行していて、Monoをインストールしません。他のテクノロジーでこの.NETアプリを書き換える必要があります。 」
彼が言ったことはあなたが質問を投稿するのに十分心配していたという事実は彼が彼の仕事をうまくやっていることを意味します。彼はあなたに考えさせました、そしてそれは私が信じている彼の究極の目標です。
私の見解は、次のとおりです。リファクタリングよりもゼロから始める方が簡単な場合は、書き直す必要があります。たとえば、リファクタリングの作業に、手続きで書かれた数ヶ月の改造が含まれる場合OOPコードを適切にOOPあなたができる前にstartコードをリファクタリングするには、everythingを変更する必要があるため、書き換えがより良いオプションです。別の例は、ユニットテストがゼロでインフラストラクチャがある場合です。ユニットテストをサポートしていません（つまり、緊密に結合されたコード、問題の分離なし）。テストスイートがないとコードのリファクタリングを開始できませんが、テストスイートを作成するには、アプリケーションの本質を理解し、かなり深刻な変更を加える必要があります。そもそもこれらのテストを作成できるようにします。これは一種の無限ループです。テストなしではリファクタリングはできませんが、リファクタリングなしではテストは存在できません。
深刻なリファクタリングcannotが文字通り[〜＃〜] nothing [〜＃〜]のために発生する多くの状況にあったので、私は書き換えに関するJoelの記事に激しく反対します。リファクタリングをサポートするために正しく行われます。このような状況では、多くの場合、選択肢は次のとおりです。1）アプリケーションを書き直すか、2）何も触れないでコードを傾斜させます。
また、レトロフィットできないコードに深刻なアーキテクチャ上の変更を導入する必要がある場合は、書き直しを検討する必要があります。ここでも、典型的な例は、韻や理由なし、単体テストなし、分離なしで一緒にスローされたアプリで動作します。 、ハードコーディングされたSQL、至る所にマジックナンバーがあります。そのような獣を変更しようとすると、特にSOLIDのような適切な設計概念を導入したり、適切なORMを導入したり、すべてのロジックがすべてWebFormsであるときにASP.NET MVCに移動したりする場合など、Sisyphusがボルダーをプッシュしようとしているようですコードビハインド。
「技術的負債」のテーマ全体を維持するために、私はこれを発表しました。
リファクタリングは（技術的な）借金の整理を行っており、（通常は長い）期間にわたってゆっくりと借金を返済しています。
書き換えは（技術的な）破産です。
実際の財政と同じように、借金が非常に大きいため、同じ間違いを繰り返さない限り、破産がすべてを一掃してやり直すための最良の（唯一ではないにしても）オプションです。
おそらく...しかし
コードのすべての行が変更された場合、追加の例外がおそらくあるでしょう-ある時点で「大規模なリファクタリング」と「書き換え」は区別できません！
しかし、私が不思議に思っているのは：まだ遭遇していない状況に対して厳格なルールを作成する目的は何ですか？ジョエルの例は極端なケース（NetScape）は一般的なケースではありません。設計が間違っていたり、アーキテクチャーやプラットフォームが変更されていたりする場合は、書き換えが有効なオプションとなる場合があります。あなたのチームがその時点まで到達しない場合、ルールの議論は息の無駄です。その時点に到達すると、状況が非常に異なるため、今日思い付いた困難なルールが適用されなくなる可能性があります。
私は彼の記事を読みましたが、1、2、および4は良い点ですが、3は循環論法です。また、彼のコード例はcloseでも、私が見た中で最悪のコードではありません。確かに、ある時点で、ゼロから書き直す価値のあるコードが存在する必要がありますか？絶対にやらないと言うことも1つですが、どこに線を引くかを合理的に決定する方法を考え出してみると、より役に立ちます。
データベースではなくファイルを使用する古いソフトウェアスタックをアップグレードしたい場合、バグのあるカスタムコンパイラを使用してCOBOLにプライベート言語を記述し、コメントはなく、テストも行わず、制御のフローにGOTOのみを使用する場合状態のグローバル変数、およびエンタープライズアプリケーション全体が1つのレイヤーにあり、すべてが他のすべてに依存しています（ただし、ユーザーはそれを気に入っています）。私はこれを作り上げていますが、そのような状況では、書き換えるより修正するほうが本当に安いでしょうか？
ポイント3は、最初からやり直す方が（移植を含めて）費用がかからないということです。あなたの場合、行ごとのポートが実際に機能しない場合は、基本的に書き換えを認め、それに応じて計画することができます。
設計が保守不可能なスパゲッティ（単一のプログラマー/小さなコードベースプロジェクトの一般的な問題）に変わり、プロジェクトの初期段階にある（または影響を受ける部分が十分に小さい）場合は、ゴミを取り除いて再起動することをお勧めします。
しかし、それこそが、書き直すべき唯一の理由です。
そして、書き直しを始めるとき、新しいデザインがどうなるかについて明確な計画を立てて、STICK TO ITを行うと、最初に何が必要でどこが間違っていたのかをすでに理解していて、その後からデザインを作成する必要があります（keep古いバグレポートと新しいプロジェクトで状況を再現coughunittestscough再生成バグを修正）
既存の以前のプロジェクトを次のメジャーバージョンとして再作成する場合それをサイドプロジェクトとして保持するとし、メインプロジェクトをアクティブに保ち、書き換えが失敗した場合のバックアップをサポートし、一致した場合にのみ書き換えを出荷する古いものが到達した、または失敗したときに破棄する要件。 Joelの記事はM $がWordを書き直そうとしたが失敗したが、古いコードベースをアクティブにしていたので、開発時間の損失に加えて問題はなかったと述べた。