新しいシステム コンセプトや新しいテクノロジーが使用される場合、システムを構築して破棄する必要があります。最適な計画でさえ、最初から正しく実行できるほど全知ではないからです。したがって、1つを捨てることを計画してください。とにかく、そうするでしょう。
-- Fred Brooks、The Mythical Man-Month [私の強調]
捨てるものを作る。それが彼らが私に言ったことです。その後、彼らは私たち全員が今ではアジャイルになっているので、容赦なくリファクタリングする必要があると私に言いました。何を与える？
トラブルから抜け出す方法をリファクタリングする方が常に良いですか? そうでない場合は、いつそれを使い続けるか、いつあきらめて最初からやり直すかを決定するのに役立つ経験則を誰かが提案できますか?
テスト駆動開発を行っている場合は、リファクタリングを行うことでほとんどの問題を回避できます。大きな問題なく設計上の決定を変更し、10 年前のコードベースを救出しました。
唯一の例外は、アーキテクチャが最初から最後まで完全に間違っていることに気付いた場合です。たとえば、スレッドを使用してアプリを作成したものの、多数の非同期ステート マシンが必要であることがわかったとします。その時点で、先に進み、最初のドラフトを破棄します。
小規模なシステムであれば廃棄しても問題ありませんが、システムのサイズが巨大な場合は、そうするだけのリソースがありません。
ただし、実際のプロジェクトの非常に重要な機能のみを実装する小規模なパイロット プロジェクトを作成することはできます。いくつかの試行錯誤と学習と廃棄を経て、実際のプロジェクトに対する確かなコアとより良い理解が得られます。次に、必要なすべての機能を追加して、プロジェクトのサイズを大きくします。しかし、そこまで来たら、コアを捨てるわけにはいきません。リファクタリングのみ。
あなたが十分に無慈悲であれば、リファクタリングの最終結果は、ゼロから再構築した場合に得られるものにかなり近いものになりますが、プロセス中に動作しないシステムで立ち往生することはありません.
The Mythical Man Month の中心的なポイントの 1 つは、ソフトウェア開発の難しい部分は、どのように言うかではなく、何を言うかを理解することだということでした。
私が最近これを解釈した方法は、最初のドラフトから得られる最大の価値は、収集してテストの形で保存した要件であるということです。システムの実際の要件ではないことをテストしないように注意すれば、混乱から抜け出す方法をリファクタリングできます。
テストを投げ出さなければならない罠に自分自身をコーディングしない限り、実際の作業を大幅に失うことなく、必要なだけ多くのコードを投げ出してもかまいません。
ここでの私の一般的なアドバイスは、既存のシステムを悪い設計からより良い設計のシステムにリファクタリングすることです。これにより、システムが維持され、いつでも展開できるようになります。ゼロから始める場合は、展開できるようになるまでにしばらく時間がかかる場合があります。
既存のシステムがない場所で新しいコードを書くことについて話している場合は、コードを少し書くことをお勧めしますが、必要に応じて、デプロイされていないのでそれを破棄してやり直してください（ TDDを使用）。
アジャイルについて話すときは、両方を行うことができますが、一般的には、特定の問題を試し、それらについて学び、より適切な見積もりを行うためにのみスパイク（プロトタイプ）を行います。単純なスパイクを実行しているときは破棄し、実際にアプリケーションをコーディングしているときはリファクタリングします。
敬具
リファクタリングが時間の無駄になる時が来ます。ゼロからやり直すしかありません。デザインをかなり柔軟に保ち、まだすべてを知っているわけではないことを認識していれば、何も捨てる必要はありません。もちろん、クラスが冗長になる可能性はありますが、システム全体を破棄することはできません。
適切にリファクタリングできるようにするには、柔軟な設計が必要です。設計がない、または厳格な設計があるということは、リファクタリングができないか、継続的なリファクタリングによってコード ベースの保守性が低下するため、何かを捨てることになることを意味します。完全性を維持するための一連の小さなリファクタリングを完了することができるほど、細心の注意を払い、十分に訓練されている人間はほとんどいません。オールスターチームでない限り、この劣化は起こります!
TL;DR: ほとんどの問題はリファクタリングできます。ただし、一部の設計要素を超えてリファクタリングできない場合があります。それが起こったら、もう一度やり直す時です - うまくいけば、あなたが持っているコンポーネントのいくつかを再利用することができます.
異なる状況では、異なるアプローチが必要です。個人的には、可能な限り、より良い設計にリファクタリングすることを好みます。リファクタリングは、書き直しよりもバグが少なくなります。
ただし、1 つを破棄する予定がある場合でも、2 つ目のバージョンが正しい軌道に乗っていることを確認するために、多数の受け入れテストを作成することをお勧めします。次に、ユーザーの観点から機能が変更されないようにしながら、次のバージョンに少しずつ移行できます。リファクタリングのように聞こえますが、少しずさんだと思います。
The Mythical Man Month の後半のエッセイで、Brooks は、実際に 1 を捨てるつもりなら、2 を捨てることになることを発見したと警告しています。
私は個人的にこれが実際に起こるのを見ました。私たちはプロジェクトのバージョン 1 を平凡なプログラマーに簡単に捨てるものとして割り当てました。最終的にバージョン 2 に書き直す必要がありましたが、それも破棄されました。私はバージョン 3 を見たことがありません。会社は倒産しました。
Brooks が「1 つを捨てる計画を立てても、いずれにせよ」と言うのは、「発見される残りのバグの数は 'n+1' です」というステートメントに似ていると思います。つまり、これは実用的なアドバイスではなく、マーフィーの法則に関するはははだけの真面目な声明です。そこから得られる教訓は、プロトタイプには価値があること、優れた文章は書き直すことであり、機能していないものを放棄することを恐れてはならないということです。
ただし、Joel Spolsky がいくつかのエッセイで述べているように、コードは読むよりも書くほうが簡単で、維持するよりも書くほうが楽しいため、破棄して最初からやり直すという選択肢が魅力的であるため、判断を下す必要があります。 、だからあなたの自然な傾向は、それが本当に最善のことではない場合でも、常に最初からやり直すことです.
新しい問題や機能を解決しようとするときにプロトタイプを作成します。その後、学んだことを基に再構築します。実際、それはリファクタリングによく似ています...何ですか？多分それは同じことですか？うーん...
捨てることが最善の方法である場合もあると思いますが、それは害になる可能性があります。うまく機能することがわかった 1 つのことは、1 つを捨てることですが、テクノロジーを適切に選択することです。
たとえば、私は Ruby on Rails で大規模なコードベースを作成しましたが、過去 2 ～ 3 年で RoR は大きく進歩しました。また、修正が必要なアーキテクチャの決定もいくつか行いました。ということで、一つ捨てて、一から作り直しています。ただし、まだ Ruby と Rails で書いているため、古いコードの 70 ～ 80% 程度を使用できます。
これに役立った主な要因は、Rails では、ビジネス ロジックとプレゼンテーション レイヤーを分離して、適切に構造化されたコードを記述する必要があることです。最初は完璧にはできませんでしたが、すべてがかなりうまく分離されていて DRY であるため、コードを Rails v2.1 に移植し、問題のある領域を再構築し、いくつかの「問題のある」機能を書き直しました。かなり痛みのない経験。
つまり、最初から優れたテクノロジを選択することで、1 つを捨てることができましたが、まだ機能する古いテクノロジの 70 ～ 80% を使用できます。
この組織の開発マネージャーとして、私は製品コードを書くことを「許可されていません」。
私はそのルールを (乱用) 使用して、1 つまたは他の問題点に対処する迅速で汚れた概念実証コードをノックアウトし、それをソース管理にチェックインして、「適切な」開発者に指摘し、「これがその方法です。やった、今度はちゃんとやれ」
これで「捨てる」に限りなく近づいたわけで、ノックするのに最大で数時間かかったと思います。エラー処理、境界チェック、および優れたコードを作成するためのその他すべての作業に時間を費やすことは、この種の作業では時間の無駄になりますが、本番コードを作成するために報酬を得ている人は、自分の時間を費やすことができます。コードレビューの時間に関しては、「これはプロトタイプにすぎない」などの言い訳はありません。
廃棄するものを構築することは、仕事を適切に行わないことの言い訳として頻繁に使用されます。つまり、プロセスの中で実際に十分な問題に遭遇して、誰かの時間を有効に活用するのに十分なほど学習していないということです。ちゃんとやっても捨ててしまうのは、もっともったいないですよね。
何人かの人々が以前に言ったように、どんなソフトウェアにおいても最も重要な機能はそれが出荷されることです。それを念頭に置いて、私はいつでも「人々にお金を払ってもらうためのもの」を構築します.
ブランチの概念をサポートする任意の構成管理システムで破棄するものを構築するのは簡単です。現場にあり、給与の源となっている既存のシステムに根本的な設計変更を導入している場合。あなたはもっと良いブランチです。プロトタイプ; そしてダメなら捨てる。
大規模なレガシー キャッシュ カウ システムをリファクタリングすると、昔ながらのハッキングにつながることがよくあります。リファクタリングは、ハッキングよりもはるかに優れているように思えます。