principle-minimize-reader-load

読者の負荷を減らす

保守性とは、コードを理解するために読者が費やす作業のことです。次の2つの軸を意識してください。

1. たどるレイヤー。 質問から答えにたどり着くまでに、いくつの間接層があるか。
2. 把握すべき状態。 読者が頭の中に保持しなければならない、隠れた状態や変更可能な状態がどれだけあるか。

理由： コードは書かれるよりもはるかに多く読まれます。LOC、循環的複雑度、「クリーンアーキテクチャ」は代理指標にすぎません。重要なのは読者の負荷です。この2つの軸は独立しています。グローバル変数が50個あるフラットなファイルも、6層のアダプタースタックと同じくらい推論が難しい場合があります。両方に気を配ってください。これは人間にとってのコンテキストウィンドウを守ることに相当します。読者の作業記憶にも限りがあります。

パターン：

• コストに見合う効果がないレイヤーはまとめます。呼び出し元が1つしかないラッパー、2つ目の実装がないアダプター、結局必要なかった投機的な間接化などは、インライン化します。
• 隣接するレイヤー間で抽象化を変えます。同じメソッドや引数を繰り返すレイヤーは、情報を圧縮せずに読者の負荷を増やします。単に受け渡すだけのレイヤーはまとめます。
• インターフェースに十分な情報の圧縮を求めます。 複雑さをほとんど隠さない広範なインターフェースでは、読者は公開面と実装の両方を理解しなければなりません。意味のある判断を隠す境界を優先します。
• 状態のスコープを小さくします。 ミューテーションより純粋関数（戻り値を返す）、フィールドよりローカル変数、モジュール状態よりフィールド、グローバル変数よりモジュール状態を優先します。同期するのではなく、導出してください。
• 不変条件は各利用側ではなく境界で明示し、 読者が一度で把握できるようにします。
• レイヤーや状態を追加する前に、それによって別の場所の読者の負荷を少なくとも同じだけ減らせるかを考えます。

テスト： 新しい読者が「Xはどこから来るのか？」と「何がXを変えられるのか？」に30秒以内で答えられますか？できない場合は、レイヤーか状態を減らしてください。