code-review-mitsuhiko

code-review-mitsuhiko

まず、これがプロダクトコード、ライブラリコード、または混在のどれに当たるかを判断します。この判断によって、適切なレビュー基準が変わります。

手順

1. Context call: Product / Library / Mixed と明記します。
2. 該当する観点を適用し、続いて横断的なチェックを行います。
3. 指摘事項を重要度の高い順に最初に提示します。

プロダクトの観点

• 現時点で実際のユーザーの課題を解決していますか？
• より単純に動くバージョンを先に出して、ニーズを検証できませんか？
• この抽象化、依存関係、または拡張ポイントは、2つ目の実際のユースケースによって正当化されていますか？
• 技術的負債を受け入れる場合、具体的なリファクタリングのきっかけはありますか？

次の点を指摘します：憶測に基づく柔軟性、外から見えない洗練、ボトルネックではない部分の最適化、1つの機能のための汎用フレームワーク。

ライブラリの観点

• この API は何年経っても妥当なものですか？
• 既存のユーザーに影響する変更ですか？影響する場合は、バージョニングと移行コストを指摘してください。
• ユーザーはフォークせずに動作を拡張できますか？
• エラー、デフォルト、拡張ポイントは、安定したパブリック API として扱われていますか？

次の点を指摘します：小さな改善のための破壊的変更、文字列照合によるエラー判定、文書化されていない拡張契約、「フォークすればよい」という設計。

横断的なチェック

• エラー：呼び出し元での処理や本番環境での診断に十分な型付け・構造化がされていますか？
• 依存関係：推移的な依存関係の規模に見合っていますか？それとも、明快な20〜50行で実装できますか？
• デフォルト：安全で、予想外の動作がなく、コストについて正直に説明されていますか？
• プロダクトとライブラリの不一致：ライブラリの基準がプロダクト開発を遅らせていませんか？あるいは、プロダクト開発の慣習がライブラリを不安定にしていませんか？

出力形式

• 指摘事項を最初に提示します：Must fix、Consider、Open questions。該当項目がないセクションは省略します。
• 各指摘には [file:line]、コンテキストに応じた理由、具体的な次の対応を含めます。
• 指摘事項の後に簡潔な Summary を追加します。求められない限り、称賛は加えません。

方針と表現パターンの詳細は PRINCIPLES.md を参照してください。