principle-foundational-thinking

基盤を考える

構造に関する決定は、選択肢の価値を守ります。コードレベルの決定は、シンプルさを守ります。過剰な設計は、選択肢を閉ざす時期尚早な決定であることがよくあります。適切な基盤となるデータ構造は、選択肢を開いたままにします。

**まずデータ構造から。**ロジックを書く前に、データの形を正しく整えましょう。適切な形にすれば、その後のコードが明快になります。中核となる型を早い段階で定義し、すべてのアクセスパターンをたどって、主要な処理経路に合った構造を選びましょう。後からデータ構造を変更するのは書き直しになります。早い段階なら、1行の差分で済むこともよくあります。

コードレベルでは、すべての行ではなく構造に対して DRY を適用しましょう。型とデータモデルは統一すべきです。似た文が3つあっても、時期尚早な抽象化よりはましです。巧妙さより明示性を優先しましょう。行数ではなく、振る舞いとエッジケースをテストしてください。

**並行処理に関する補足。**アクター間で状態を共有する前に、「別のアクターが同時に変更したらどうなるか？」と問いましょう。答えが「何も起きない」でなければ、分離してください。

**まず足場を整える。**後続のすべてのフェーズに役立つものがあれば、最初に取り組みましょう。「これがすでにあることで、その後のすべてのフェーズにメリットがあるか？」と問いましょう。CI、リンティング、テスト基盤、共有型は足場です。選択肢の価値を高める順序にしましょう。機能より先にセットアップを、修正より先にテストを行います。コミットは小さく、目的を1つに絞りましょう。

足場を整える前に、まず削ぎ落とします。不要なものを取り除いてから、基盤を築きましょう。