𝗛𝗼𝘄 𝗪𝗲 𝗗𝗲𝗰𝗶𝗱𝗲 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗥𝗲𝗳𝗮𝗰𝘁𝗼𝗿 𝗮𝗻𝗱 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗥𝗲𝘄𝗿𝗶𝘁𝗲

📅3 hours ago⏱2 min read

リファクタリングすべきか、書き直すべきか、その判断基準

すべての開発者が、この瞬間に直面します。

コードベースの動作が遅い。新機能の追加に時間がかかりすぎる。新しく入ったメンバーがシステムを理解するのに苦労している。そして、誰かが最終的に「全面的な書き直し（リライト）」を提案します。

チームは通常、2つのグループに分かれます。一方はゼロからやり直したいと考え、もう一方は過去のリライトの失敗を恐れます。どちらの主張にも一理あります。

リライトは魔法の解決策ではありません。計画よりも時間がかかることがよくあります。結局、2つのシステムを同時にメンテナンスすることになり、新しいバージョンでも同じ間違いを繰り返してしまうことさえあります。

リライトが理にかなっているのは、以下のような特定のケースです：

• データモデルがビジネスの要件に対して根本的に間違っている。 • 使用している技術が廃れており、セキュリティアップデートも提供されていない。 • ビジネスニーズが大きく変わり、元のシステムが時代遅れになっている。 • 現在のチームの誰も、システムの仕組みを理解していない。

ただし、そのような場合でも、「ビッグバン」方式での一括置き換えは避けてください。「ストラングラー・フィグ・パターン（Strangler Fig Pattern）」を採用しましょう。古いシステムと並行して、新しいシステムを少しずつ構築していくのです。

多くの場合、本当に必要なのはリファクタリングです。

リファクタリングが適切な選択となるのは、以下のような場合です：

• 速度は遅いものの、まだ新機能を追加できる。 • チームが現在のコードを理解している。 • 乱れている部分が特定のモジュールに限定されている。 • ビジネス上、新機能のリリースを止めることができない。

選択する前に、なぜコードが悪化したのかを問い直してください。

問題が技術的負債であるなら、最もひどい部分をリファクタリングしてください。もし問題がコードレビューの不足や文化の欠如にあるなら、リライトをしても解決しません。古い習慣のまま、新しい「ぐちゃぐちゃなコード」を作り上げるだけになってしまいます。

決断を下す前に、以下の質問を自分たちに投げかけてみてください：

• 最もひどい部分を、切り離して修正できるか？ • 現在のビジネスニーズに対して、データモデルが破綻しているか？ • 最初からやり直した場合、どのような知識を失うことになるか？ • ビジネス側には、長期的な移行期間に耐えうる安定性があるか？

「やり直す」ことは気持ちが良いものですが、「リライトを完了させる」ことこそが困難なのです。多くの場合、構造化されたリファクタリング計画の方が、より安全で効果的です。