関数型コアスタイル

基本方針

実装では、可能な限り純粋関数を中心に設計する。

同じ入力に対して同じ出力を返せる処理は、DB、HTTP、ファイル、時刻、乱数、環境変数、ログ、spawn などの副作用から分離する。副作用は、外部入出力を扱う境界や、処理の順序を組み立てる層へ寄せる。

ただし、関数型風に書くこと自体を目的にしない。近くのコードより読みにくくなる chain や、意図を追いにくくする抽象化は避ける。

実装時の判断

• データ変換は、可能なら純粋関数として切り出す
• usecase や handler に、細かい変換処理を散らさない
• 可変の配列や list へ順に値を追加している場合は、map / filter / filter_map / flatMap / collect / partition / chunks などで自然に表現できないか確認する
• nullable、optional、result、either、例外などのエラー・欠損表現は、その言語とコードベースで自然な形にそろえる
• 例えば Rust の Option / Result、Scala の Option / Either、TypeScript の discriminated union のように、言語ごとの型表現で分岐を明瞭にできる場合は使う
• match、if let、switch、早期 return の方が読みやすい場合は、無理に chain にしない
• 可変状態は必要な範囲に閉じ込め、関数外へ漏らさない
• エラーは panic、throw、暗黙のログだけにせず、呼び出し側が扱える値や型で表現できないか考える
• 既存コードの命名、分割、エラー処理、テストスタイルを優先する

副作用の境界

副作用を完全になくすのではなく、境界を明確にする。

• 入力値から出力値を作る処理は、できるだけ副作用なしの関数にする
• 値の意味、不変条件、状態遷移は、外部入出力から切り離して表す
• 保存、取得、外部呼び出し、spawn などは、処理の順序を組み立てる境界へ寄せる
• DB、HTTP、外部 API、ファイルなどの型や都合を、ドメインロジックへ直接漏らさない
• request / response の変換や表示上の都合は、中心のロジックから分ける

言語やフレームワークによって層の名前が違う場合は、同じ責務を持つ境界に読み替える。

テストしやすさ

純粋関数として切り出せる処理は、fake や mock を使わずにテストできる形にする。

特に次の処理は純粋関数にしやすい。

• payload の組み立て
• 検証結果の変換
• 表示用データの整形
• retry policy の計算
• 状態遷移の判定
• domain rule の適用

差分レビュー

実装後、差分に対して行う。差分だけを渡された第三者でも同じ結果になるように、対象を列挙してから、対象ごとの問いに答える。誰がこのレビューを行うかは、このスキルでは決めない。実装の進め方を管理する側に従う。

手順:

1. 差分から対象を列挙する: 新規・変更した関数・メソッド / 可変状態を導入・変更した箇所。
2. 対象ごとに下の問いに答える。「問題なし」で済ませず、根拠を 1 行で言い切る。言い切れない対象は、本文の該当節へ戻って設計から見直す。
3. 問題が見つかった対象は修正し、修正した対象にもう一度この手順を適用する。

関数・メソッドごとの問い:

• 純粋性: 同じ入力に対して同じ出力を返せるか。返せないなら、その副作用（DB、HTTP、時刻、乱数、ログなど）はこの関数の責務か、境界へ寄せられるか
• 変換の置き場所: usecase / handler に細かいデータ変換を抱えさせていないか。純粋関数として切り出せる変換が、副作用のある関数に混ざっていないか
• 読みやすさ: コレクション操作や optional / result / either の使い方は、近くのコードと比べて読みやすいか。関数型風にしたことで意図が追いにくくなっていないか
• テスト: fake や mock なしでテストできる単位に分かれているか

可変状態を導入・変更した箇所ごとの問い:

• その可変状態は関数の外へ漏れていないか。より小さい範囲に閉じ込められないか
• 順に値を追加する loop なら、map / filter / collect などで自然に表現できないか。chain にしないほうが読みやすいなら、その理由を言い切れるか