書き換えに時間がかかりすぎる場合はどうしますか？
Joelが、書き換えは常に悪いと言っていることは知っていますが、そもそもコードを書いた人が自分たちが何をしているのかを知っていたと仮定しています。
私は中規模の（とにかく1人の開発者にとっては〜18k LoC）C++プロジェクトを持っています。これは、C++を本当に知らなかったときに始めました。したがって、間違っていることがいくつかあります。間違っていることがそれを説明する唯一の方法です。それは書き直され、明白で単純である必要があります。
しかし、私は書き直しに長い時間を費やしてきましたが、オリジナルのバグは修正されていません。ただし、バグ自体のいくつかは元のツールのアーキテクチャの問題です-そしてそれのいくつかは私が修正する必要があるものであり、とにかくコードのほぼすべての行に触れる必要があります。
一方で、古いプログラムのバグを修正することは、私が取り組んできた新しいデザインでは不可能であるため、多大な無駄な努力になると思います。一方で、元のプログラムはあまり更新されていないので、ユーザーを無視しているような気がします。
私は何をすべきか？
あなたは セカンドシステム効果 に苦しんでいるようです。
古いシステムに戻ることをお勧めします。次に、リファクタリング（私はこのあたりほど多くのファンではありません）を選択するか、元のシステムの機能をできるだけ少なくするために使用可能な最小限の代替品を作成するかを選択します。しかし、「これがすべてを正しく行うための私の壮大なデザインです！」から離れてください。そのようにして、多くの不注意な開発者を燃やしたドラゴンがいるからです。
特に大規模なプロジェクトでは、コードのすべての行を書き直さなければならないケースはまれです。結局のところ、コードのevery行でコードが間違っているのはなぜですか？たとえば、次の行の何が問題になっていますか？
int a = b + c;
一方、重要なのは定期的にリファクタリングを行うことです。
一部のリファクタリングの変更は小さい場合があります（ローカル変数
piの名前をproductIdに変更します。これは、piが誤解を招くためです）。他の変更は、代わりにアプリケーションの構造全体を変更することを強制し、数千行のコードに影響を与えます。
この場合の最も重要な考えは、リファクタリングを行う確かな理由があることです。数か月でさえ使用されないコードをリファクタリングする顧客に数千ドルを費やすことは良い考えではありません。反対に、変更がほぼ不可能で、変更ごとに非常に高いコストがかかるコードのリファクタリングに数千ドルを費やすのは、コードを何年も使用することを意図している場合はそれほど悪くありません。
いずれの場合も、小さなリファクタリングを行うことで、全体の書き換えを回避できます。 1週間、コードの一部をリファクタリングし、他の部分をさらにリファクタリングできるようにします。数か月後、コードの別の部分などのリファクタリングを開始します。
2つのこと：
- システム内の全機能の20％しか実際に使用されていないと言われているので、書き換え時間を短縮したい場合は、それらの20％のみで作業し、完了したらリリースすることを検討してください。段階的に作業します。
- 古いシステムに関する知識を活用して、新しいシステムをより良く、より集中し、ユーザーフレンドリーにする必要があります。古いシステムを少しずつ模倣するだけでは、ユーザーに価値のあるものは何も得られません。
これはちょっとした警官の答えですが、自分があまりにも対立していることに気付いた場合、それ自体が最悪の敵になる可能性があります。どちらの観点にもメリットがあると思います。それに対するあなたの気持ちを検索し、それにコミットし、そしてそれに従ってください。結局、それはあなたが完了したかどうかについてです。あなたが出産した場合、誰かがあなたを迫害することはないと思います。
私の経験では、ボトムアップで非常に単純に間違っているプロジェクトがある場合、最善の方法は、すべてに火をつけて、座って書き直すだけでなく、下着を少し走り回ることです。しかし、プロジェクト全体の完全なボトムアップのクリーンルームの書き直し。
確かに、いくつかのプロジェクトは提出にリファクタリングできますが、いくつかは…
それほど多くはありません。
特に古いプロジェクトでは;最新のツールを使用してクリーンな状態から始めることは、通常、行ごとの書き換えを試みるよりも高速でエラーが発生しにくいです。少なくとも私の経験では。