refactoring - 書き直しますか、それとも修復しますか？

Question

皆さんもきっとそこに行ったことがあると思います。目的にかなわないきしみのある古いコードベースが存在するプロジェクトに取り組み、それを最初から書き直すか、既存のものを修復するかを決定しなければなりません。

失敗のリスクが非常に高いため、ゼロからの再書き込みを決して試みてはならないというのが一般的な通念です。この問題に直面したとき、あなたは何をしましたか?

score 10 · Accepted Answer

作業するたびに、コードを少しクリーンアップするだけです。単体テストフレームワークがまだない場合は、セットアップします。新しいコードはすべて、テストを作成する必要があります。バグの結果として修正した古いコードは、テストにもスライドしてみてください。

クリーンアップが進むにつれて、より多くの厄介なコードをカプセル化されたビンに一掃できるようになります。その後、将来的にそれらを 1 つずつ選択できます。

javadoc や doxygen などのツールをまだ使用していない場合は、コードのドキュメント化とわかりやすさの向上にも役立ちます。

完全な書き直しに対する議論はかなり強力です。元のプロジェクトの時間枠でコード化された大量の「小さなバグ」と動作が、再び忍び込みます。

score 10 · Accepted Answer

それは本当にそれがどれほど悪いかによって異なります。

それが小さなシステムであり、それを完全に理解している場合、書き直しはおかしなことではありません。

一方、文書化されていないミステリーコードが 1,000 万行もある巨大なレガシーモンスターの場合は、完全に書き直すのは非常に困難です。

考慮すべき点:

ユーザーにとって見栄えが良ければ、ユーザーはそれがどんなスパゲッティの混乱であっても気にしません。一方、それが彼らにとっても悪いことである場合は、合意 (および忍耐) を得る方が簡単です。
書き直す場合は、一度に 1 つずつ実行してみてください。乱雑でまとまりのないコードベースでは、これが困難になる場合があります (つまり、1 つの部分だけを置き換えるには、依存関係のあるコードの大きな氷山を書き直す必要があります)。 .

新しい版を一度に 1 つずつリリースできない状態で、大規模なシステムの巨大な書き直しプロジェクトに取り組むことは本当に躊躇します。

score 5 · Accepted Answer

Joel Spolsky のエッセイ「Things You Should Never Do」を参照してください。要約すると、書き直すと、現在のコードを必要な方法で機能させるために学んだすべての教訓が失われます。

参照:泥の大きな玉

score 3 · Accepted Answer

複雑なものの書き直しが成功することはめったにありません。魅力的ですが、割合の低い戦略です。

単体テストの下でレガシーコードを取得し、それをリファクタリングします。また、機会があれば、その小さな部分を段階的に完全に置き換えます。

score 2 · Accepted Answer

実際に非常に悪い場合を除き、リファクタリングします。

ジョエルはこれについて多くのことを言っています...

少なくとも、目の前の古いコードでコードを書き直して、ゼロからやり直すのはやめましょう。古いコードはひどいものかもしれませんが、それには理由があります。それを無視すると、おそらく何年も前に古いコードで修正されたのと同じバグが表示されることになります。

score 2 · Accepted Answer

以前の仕事で書き直した理由の 1 つは、元のコードベースに取り組むのに十分な経験を持つ開発者を見つけることができなかったことです。

最初に基礎となるデータベース構造をクリーンアップし、次にフルタイムの従業員や請負業者を見つけやすくするために何かを書き直すという決定が下されました。

それがどのように機能したかはまだ聞いていません:)

表面的にはもっと楽しいように見えるので、人々は書き直しに行く傾向があると思います。

ゼロから再構築します！

今回はちゃんとやる！

等

score 2 · Accepted Answer

Baley と Belcham による新しい本、Brownfield Application Development in .NETが出版されています。最初の章は無料で、プラットフォームにとらわれない観点からこれらの問題について説明します。

score 2 · Accepted Answer

修復、またはさらに重要なことに、リファクタリングします。Joel がそう言ったからです。また、それがあなたのコードであれば、最後にこのコードに触れて以来、おそらくさらに多くのことを学んだからです。.NET 1.1 で作成した場合は、3.5 SP1 にアップグレードできます。古いコメントアウトされたコードをすべて削除します。このコードを最初に書いたときよりも、開発者として今の方が 100 倍優れています。

唯一の例外は、コードが非常に時代遅れのテクノロジを使用している場合です。この場合、新しいバージョンを作成した方がよい場合があります。10,000 行のコードを含む VB6 アプリを見ていて、Access データベースのバックエンドが、データベースの仕組みについてよく知らない人 (8 年前のあなたかもしれません) によって設定されていることが明らかな場合は、おそらくプルできます。わずかな時間とコードで、より迅速な C#/SQL ベースのソリューションをオフにします。

score 1 · Accepted Answer

状況によっては、別のオプションがあります。ライセンス内のサードパーティコードです。

私はそれが賢明な選択であるいくつかの会社に相談しましたが、一見「IPを捨てる」ことは経営にとって大きな障壁になる可能性があります。私の現在の会社では、コアフレームワークの代わりにサードパーティのコードを使用するという実行可能なオプションを真剣に検討しましたが、そのアイデアは、技術的な理由よりもビジネス上の理由で最終的に拒否されました。

あなたの質問に直接答えるために、私たちはついにレガシーフレームワークを書き直すことを選択しました-私たちが軽視しなかった決定です！14か月後、私たちはこの選択をまったく後悔していません。バグの修正に費やした時間を考えるだけで、私たちの新しいフレームワークはほぼそれ自体で報われました。マイナス面としては、まだ完全な機能ではないため、最後の「フロントエンド」アプリケーションを移植できるようになるまで、2つの別々のフレームワークを並行して維持するといううらやましい立場にあります。

score 1 · Accepted Answer

それはそれほど白黒ではありません...それは本当に多くの要因に依存します（より重要なのは、「お金を払っている人があなたに何をしてほしいか」です）

私が働いている場所では、開発フレームワークを書き直しましたが、一方で、移行できない古いシステムをいくつか変更し続けています (クライアントの技術と時間の制限のため)。この場合、私たちはコーディングスタイルを維持しようとしますが、ビルド方法が原因で多くの回避策を実装する必要がある場合があります。

score 1 · Accepted Answer

Michael Feathers による「レガシーコードを効果的に使用する」を読むことを強くお勧めします。これは、コードをリファクタリングして単体テストを可能にする方法に関するコーチングアドバイスです。

refactoring - 書き直しますか、それとも修復しますか？

11 に答える 11

Related

Reference