【要約】引き継いだコードの「この案件だけの作法」を、git logから掘り起こしてレビュー観点にした話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が交代し、ドキュメントが欠落した大規模システムにおいて、コード特有の作法が不明確であるという問題に直面した。
- ・汎用的なAIレビューは、入力値検証などの基本事項は指摘できる。
- ・しかし、クエリの組み立て方や認可の作法といった「案件特有のバグパターン」は、暗黙知のため指摘されない。
- ・結果として、単体試験やE2Eテストを通過しながらも、実機で不具合を起こすリスクが残る。
// Approach
git logの差分をLLMに解析させ、プロジェクト固有のレビュー観点を抽出する手法を採用した。
- ・コミットメッセージから「修正・不具合」を含むものを抽出し、差分を精読させる。
- ・修正が集中するファイルを特定し、観点の優先度を決定する根拠とする。
- ・観点ごとに「いつ、どのような障害が起きたか」という実績を紐づける。
- ・チェックリストを「汎用」と「固有」に分離し、章立てを機能名ではなく「壊れ方」で行う。
// Result
300件超の単体試験と60件超のE2Eテストを通過した新規実装に対し、固有のチェックリストを適用した。
- ・仕様の不一致やクエリの上限不足など、要対処7件のバグを検出した。
- ・これらは汎用的なレビューでは捕捉できなかった、プロジェクト特有の脆弱性である。
- ・同じチェックリストで2周レビューを行うことで、さらに重篤な認可関連の指摘を得られた。
Senior Engineer Insight
> レガシーコードの保守における「暗黙知の形式知化」の解として、極めて実戦的である。単にAIにレビューさせるのではなく、履歴という「事実」から観点を抽出させるプロセスが、実効性を高めている。ただし、コミットメッセージの質に依存するため、開発プロセスの整備も重要だ。また、レビューを「1回」と見なさず、複数回の往復を前提とした見積もりを行う姿勢は、現場のリアリティを捉えている。