成長したエンジニアのための意思決定ツリー

すべてのエンジニアリングチームは、遅かれ早かれ同じ劇的な言葉に直面します。

これを書き直すべきだ。

それは通常、バグや締め切りの遅れ、停電中に書かれたように見えるファイルを読みながら感情的な疲労を感じた瞬間に発せられます。

書き直しはすっきり感じられます。リファクタリングは責任感があります。

一方は英雄的に聞こえます。もう一方は洗濯のように聞こえます。

しかし、この判断は感情によるものではありません。リスク、経済性、そして時間に関わるものです。

大人のように一つずつ見ていきましょう。

最初の質問

そのシステムは動作しているか

美しくなくても。エレガントでなくても。誇らしい気持ちにならなくても。

動作しているかどうか。

システムが安定していて、価値を生み出していて、顧客が日常的に依存している場合、あなたは技術的な問題ではなく、収益を生むエンジンに向き合っています。

収益を生むエンジンを書き直すことは勇敢さではなく、手術です。

システムが動作しているが苦痛がある場合はリファクタリングを。

システムが根本的に現在の要件や将来の要件を満たせない場合は書き直しを。

動作していて、ただスタイルが気に入らないだけなら、タブを閉じて水を飲みましょう。

2番目の質問

問題は構造的なものか局所的なものか

局所的な問題とは、醜い関数、混乱したモジュール、長いファイル、貧弱な命名、重複したロジックのことです。

構造的な問題とは、正しくないドメインモデル、壊れた抽象化、誤ったアーキテクチャ境界、不可能なスケーリング制約のことです。

リファクタリングは局所的な問題を非常にうまく修正します。

書き直しが正当化されるのは、アーキテクチャ自体が進展を阻害している場合のみです。

デリバリーを止めることなく少しずつ改善できるなら、リファクタリングを。

小さな変更が基盤の誤りのために混乱を招くなら、書き直しが必要かもしれません。

ここでは正直になりましょう。ほとんどの問題は局所的なものです。

3番目の質問

現在のシステムを完全に理解しているか

ここでほとんどの書き直しプロジェクトは静かに死にます。

現在のシステムが混乱している場合、その混乱には誰も文書化していないビジネスルールが含まれていることがよくあります。

レガシーコードはしばしば、本番インシデントの化石記録です。

動作を完全に理解せずに書き直すと、よりクリーンなシステムは生まれません。回帰の発生源が生まれるだけです。

答えが「いいえ」で、深く理解していない場合、最初のステップは書き直しではありません。

最初のステップは学ぶことです。

学びながらリファクタリングを。テストを追加し、動作を文書化し、不確実性を縮小しましょう。

古いシステムを他人に明確に説明できるようになってから、書き直しを。

4番目の質問

デリバリーの速度低下が許容されるか

書き直しは集中力を消費します。並行する世界を生み出します。古いシステムと新しいシステムを同時に維持することになります。

数ヶ月間、機能デリバリーが遅くなることを会社が許容できない場合、書き直しは幻想です。

リファクタリングは段階的な進捗を可能にします。出荷しながら改善できます。

ビジネスが勢いを必要とするなら、リファクタリングを。

ビジネスが意図的にプラットフォームのリセットに投資していて、誰もがコストを理解しているなら、書き直しは戦略的になり得ます。

しかし、それは開発者の気分の揺れではなく、ビジネス上の判断でなければなりません。

5番目の質問

テストはあなたを守るのに十分強いか

リファクタリングは安全網に依存します。

意味のあるテストがない場合、リファクタリングは危険に感じられ、書き直しが魅力的に感じられます。

しかし、ここに不快な真実があります。

テストなしでの書き直しは、より高いテーブルでのギャンブルです。

今日システムを自信を持って変更できないなら、ゼロから再構築しても魔法のように自信が生まれるわけではありません。

まずテストに投資しましょう。

安全が存在するようになれば、判断はより明確になります。

6番目の質問

痛みは増大しているか、それとも安定しているか

一部のコードは醜くても安定しています。静かにその役割を果たしています。

他のシステムは四半期ごとに遅くなり、変更しにくくなり、より脆弱になります。

変更のコストが複利で増えている場合、あなたはアーキテクチャ的負債に直面しています。

その場合、パッチを当て続けることは、ゼロから始めるよりも高くつくかもしれません。

コストが平坦で予測可能なら、時間の経過とともにリファクタリングするのが通常十分です。

変更コストを測定しましょう。推測してはいけません。

実践的な意思決定ツリー

簡略化したバージョンはこちらです。

動作していて価値を生み出しているか
はい
その場合、リファクタリングを優先

アーキテクチャが重要な将来の目標を阻害しているか
はい
書き直しを検討

現在の動作を深く理解しているか
いいえ
まず学び、リファクタリングを

ビジネスはデリバリーの遅れを許容できるか
いいえ
リファクタリングを

テストは強いか
いいえ
劇的なことをする前にテストを強化する

変更コストは複利で増えているか
はい
書き直しは戦略的かもしれない

何かに気づきましょう。

書き直しは複数の関門を通過した後でのみ登場します。

それは意図的です。

感情的な罠

書き直しは摩擦を即座に取り除くため、生産的に感じられます。

新しいフォルダを開きます。ファイルはきれいです。抽象化は純粋です。あなたは整備士ではなく建築家のように感じます。

しかし、ソフトウェアは絵画ではありません。現実の中に埋め込まれた進化するシステムです。

古いコードは本番トラフィックを生き抜いてきました。ミスの繰り返しからあなたを守る傷跡を含んでいます。

リファクタリングはその歴史を尊重します。

書き直しはそれを消し去ります。

消し去ることが必要な場合もあります。多くの場合、それはエゴです。

より健全なパターン

リファクタリングか書き直しかではなく、レイヤーで考えましょう。

テストで既存のシステムを安定化させる。

境界をゆっくりと抽出する。

インターフェースの背後でモジュールを置き換える。

新しいコンポーネントで古いコンポーネントを絞め殺す。

時間が経てば、劇的な書き直しイベントなしにシステムは新しくなります。

ビジネスはリセットを感じることはありません。エンジニアは進捗を凍結することはありません。

これは映画的ではありません。また、破滅的でもありません。

不快な結論

ほとんどのチームは書き直しを必要としません。

彼らが必要としているのは規律です。

テスト、より明確な境界、より小さなプルリクエスト、そして忍耐です。

書き直しは稀な戦略的手段です。

リファクタリングは日常のエンジニアリングです。

書き直したくなったとき、最後の質問をしましょう。

私は構造的な制約を解決しようとしているのか
それとも、まだ理解していない複雑さから逃れようとしているのか

その答えが、あなたがエンジニアとして行動しているのか
それともただ感情をリファクタリングしているのかを決定します。