【要約】設計本の学びがコードレビューで活きた話｜フラグ引数・null戻り値・型の網羅性 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がコードレビューにおいて、設計上の不備を「なんとなく良くない」と感覚的にしか指摘できない課題に直面している。具体的な問題点は以下の通りである。
- ・ロール追加時にコンパイルエラーが発生しない。if文による分岐では、新ロール追加時の考慮漏れを検知できない。
- ・フラグ引数により、関数が複数の責務を抱えている。引数の値によって挙動が変わるため、単一責任の原則に反する。
- ・null戻り値により、成功・失敗の意図が不明瞭である。型だけでは、nullが成功を意味するのか判断しにくい。
// Approach
設計書籍の原則をTypeScriptの型システムに落とし込み、静的なチェックを強化する手法を採用した。具体的なステップは以下の通りである。
- ・Record型による網羅性の強制。TENANT_ACCESS_CONFIGをRecord<Role, ...>として定義し、全ロールの定義を強制する。
- ・フラグ引数の廃止。ロールごとの設定を外部オブジェクトへ切り出し、関数はアクセス判定の実行のみに集中させる。
- ・Result型による戻り値の明示。{ ok: true } | { ok: false; response: ... } というUnion型を定義し、成功・失敗を型で表現する。
// Result
リファクタリングにより、コードの堅牢性と可読性が大幅に向上した。具体的な成果は以下の通りである。
- ・新ロール追加時の安全性向上。型定義の漏れがコンパイルエラーとして即座に検知可能になった。
- ・関数の責務の明確化。フラグ引数が消滅し、関数の振る舞いが予測しやすくなった。
- ・エラーハンドリングの改善。呼び出し側がResult型の型定義に従うことで、成功・失敗の処理を迷わず記述できるようになった。
Senior Engineer Insight
> 実戦的な知見である。特にRecord型を用いた網羅性の強制は、大規模開発でのデグレ防止に極めて有効だ。nullを避けResult型を用いる手法は、開発体験（DX）と安全性を両立させる。ただし、過度な抽象化はコードの複雑性を増すため、プロジェクトの規模に応じたバランスが重要となる。設計原則を「言語化」してレビューに持ち込む姿勢は、チーム全体の技術水準を底上げする上で不可欠である。