プログラミングにおける応急処置（クラッチ）— その正体、原因、正当化されるケース

プログラミングにおける“応急処置”とは

応急処置（クラッチ）とは、動作はするものの“急ごしらえ”で作られたソフトウェア解決策です。特定の問題に対処しますが、その原因を排除せず、プロジェクトのアーキテクチャに従わず、環境のわずかな変更で壊れる可能性があります。この比喩は的確です。実際の松葉杖のように、そのようなコードは“歩く”助けにはなりますが、“脚”を治すわけではありません。

開発者はバグ、バージョンの非互換性、プラットフォームの特性、緊急のクライアント要件を“暫定対応で凌ぎます”。典型的な応急処置は条件付き応急処置です。iOS 15の場合はパディングを追加、Huaweiの場合はボタンを非表示にする。このようなチェックは増殖し、コードをプラットフォームとバージョンのブランチからなる“レイヤーケーキ”に変えてしまいます。

応急処置にはさまざまな規模があります。応急処置条件を含む1行のコードから、ライブラリの動作を“修正”するラッパーモジュール全体まで。応急処置が常に悪いわけではないことを理解することが重要です。適切な手に渡れば、製品を時間通りにリリースするためのツールです。問題は、応急処置がコードに永久に残るときに始まります。

応急処置が発生する理由：原因と背景

主な理由は、理想的な解決策とプロジェクトの実際の制約との間の衝突です。開発者は正しい方法を知っていますが、時間、お金、または技術的な制限がそれを妨げます。結果として、“とりあえず動く”妥協策が生まれます。

開発者が意識的に応急処置に頼る4つの主な理由を見てみましょう。これらの理由を理解することで、応急処置を間違いではなく、管理が必要な実用的なツールとして扱うことができます。

締め切り

最も一般的な理由です。リリースは明日で、バグは特定のモデルでのみ再現し、アーキテクチャ的に修正するには2週間かかります。条件付き応急処置なら1時間で問題を解決できます。リリース後、チームは戻ってきて正しく書き直すことを約束します。“一時的な解決策ほど永続的なものはない”—これはまさにそのような応急処置についての言葉です。

バージョンの非互換性

ライブラリAはAndroid 12を必要としますが、アプリはAndroid 10をサポートしています。解決策は、OSバージョンをチェックして実行パスを選択するラッパーを書くことです。これは応急処置です。なぜなら、ライブラリを更新するときにラッパーを書き直す必要があるからです。しかし、代替案（ライブラリや古いデバイスのサポートをやめること）はさらに悪い可能性があります。

// API 29互換性のための応急処置
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

バグのあるサードパーティ依存関係

プロジェクトが依存しているライブラリにバグがありますが、その更新には数週間かかる可能性があります（PR、コードレビュー、公開が必要）。待つ代わりに、チームはラッパーを書き、ライブラリの動作をその場でパッチします。修正版のライブラリがリリースされたら、ラッパーは削除されます。削除しない場合、それはすでにアーキテクチャ上の問題です。

システムの不完全な理解

レガシープロジェクトの新しい開発者は、コードがなぜそのように動作するのか理解していません。理解しようとする代わりに、既存の条件の上に新しい条件を追加します。これは最も危険なタイプの応急処置です。なぜなら、作者がそれが応急処置であると認識していないからです。唯一の治療法は、コードレビューと新しいチームメンバーに対するペアプログラミングです。

応急処置が正当化されるケース：実用的アプローチ

すべての応急処置が悪いわけではありません。実際の開発では、コードの絶対的な純粋さは達成不可能であり、しばしば非現実的です。実用的なアプローチは、一時的な解決策がプロセスの一部であることを認識しますが、認識、文書化、および除去計画を要求します。応急処置は、クリーンなアーキテクチャ解決策よりも速くビジネス上の問題を解決する場合に正当化されます。

正当化される応急処置の基準：特定の問題に対処し、所有者（除去を担当する人）がおり、リファクタリング計画が存在すること。これら3つの条件のうち少なくとも1つが欠けている場合、応急処置は技術的負債に変わります。トラッカーのチケット付きのTODOコメントのようなツールが、最小限の文書化方法です。

正当化される応急処置の例

明日のデプロイメントの前に修正が必要なリリースブランチの重大なバグ。クリーンな解決策にはアーキテクチャのリファクタリングが必要で、2週間かかります。応急処置：nilチェックを追加し、修正をホットフィックスとして送信します。正当化の条件：トラッカーにリファクタリングチケットが作成され、所有者が割り当てられ、応急処置にコメントが付けられていること。2週間後、チームはタスクに戻ります。

// TODO: IT-1234 — AuthServiceリファクタリング後にこの応急処置を削除
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

一時的な応急処置とアーキテクチャ上の問題の区別方法

認識された応急処置とアーキテクチャ上の問題（技術的負債）の境界は、2つのパラメータによって決まります。決定の認識とそれを排除する計画の有無です。応急処置は常に、既知の寿命を持つ一時的な解決策です。技術的負債は、放置された多くの応急処置の結果です。

応急処置が問題になる時

応急処置の数が臨界量を超えると、状況は悪化します。新しい応急処置ごとにシステムの“脆弱性”が増加します。ある場所での変更が別の場所を壊します。最終的に、開発は遅くなり、バグは増殖し、新しい開発者は作者の助けなしではコードを理解できなくなります。この時点で、応急処置は一時的な解決策ではなくなり、アーキテクチャ上の問題になります。

応急処置の危機の兆候

コードにOSバージョン、デバイスメーカー、特定のライブラリの有無をチェックする5つのネストされたチェックがある場合、それは応急処置ではなく、アーキテクチャ上の問題です。1つの修正を追加することで関連モジュールに3つのリグレッションが発生する場合、応急処置はもはや局所的ではありません。“また応急処置か”という理由でコードレビューが定期的に却下される場合、リファクタリングを計画する時期です。

• 同じ応急処置が3箇所以上で繰り返されている — 統一された解決策を作成する時期
• 応急処置が除去計画なしに3スプリント以上存続している — すでに技術的負債
• 新しい開発者がコードの動作を理解できない — 応急処置が文書化されていない
• 応急処置の除去がエラーの連鎖反応を引き起こす — 応急処置への依存がアーキテクチャ上のものになっている

応急処置のリファクタリング：戦略と実践

応急処置のリファクタリングとは、一時的な解決策をアーキテクチャ的に正しい解決策に置き換えるプロセスです。これには時間がかかるため、優先順位付け戦略が必要です。すべての応急処置をすぐに排除する必要はありません。良い戦略は、各応急処置を2つのパラメータで評価することです。コードのその領域での変更頻度とユーザーへの影響です。

優先順位付け戦略

高優先度 — 頻繁に変更されるモジュール（ビジネスロジック、汎用UI）の応急処置で、開発を遅らせ、リグレッションを引き起こすもの。中優先度 — めったに変更されないが、ユーザーへの潜在的な影響があるモジュール（支払い処理、認証）の応急処置。低優先度 — 安定して動作し、修正が予定されていないレガシーコードの応急処置。

段階的な除去プロセス

ステップ1： 棚卸し — 応急処置に関連するすべてのTODOとFIXMEを見つけます。ステップ2： 評価 — どれがまだ関連しているかを判断します。ステップ3： 計画 — 高優先度のものから始めて、スプリントに応急処置のリファクタリングをスケジュールします。ステップ4： 置き換え — クリーンな解決策を実装し、応急処置とそのTODOコメントを削除します。ステップ5： 検証 — テストが合格し、リグレッションがないことを確認します。

# プロジェクト内のすべてのTODO応急処置を検索
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

新しい応急処置の防止

応急処置と戦う最善の方法は、不必要に作成しないことです。応急処置を書く前に、自分自身に3つの質問をしてください。妥当な時間内にクリーンな解決策を実装できますか？応急処置ではない代替案はありますか？チームに戻ってきて書き直す時間がありますか？少なくとも1つの質問に対する答えが“いいえ”の場合、コードを“凌ぐ”前に、もう一度考えてください。