シリーズ: Gstack (5/7)
Code Review と Ship：偏執的レビューからワンクリック納品まで
コードレビューにはよくある病があります：やっている人は皆真剣にやっていると思っているが、実際には同じ種類の問題しか見ていない。
命名は明確か？ロジックに明らかなエラーはないか？エッジケースを処理し忘れていないか？これらは良い質問ですが、どれも表面的なものです——実際に production で問題を起こすのは、通常もっと深いところにあるものです：
N+1 クエリ。
Race condition。
Trust boundary violation。
Missing index がクエリを高トラフィック下でタイムアウトするほど遅くする。
Retry logic に idempotency がなく、エラー後の再試行で状態が壊れる。
このような問題は、同僚がレビューしても気づかないかもしれません——人間の脳は 5 つの failure scenario を同時に実行するためには設計されていないからです。
Gstack の /review がやることはまさにこれです：体系的に、漏れなく高リスクポイントをスキャンする。
/review：偏執的シニアエンジニアのレビューチェックリスト
/review は「コードを見て」ではありません。背後には構造化されたレビューフレームワークがあり、毎回これらの次元をカバーします：
パフォーマンスとデータベース
- N+1 クエリはないか？ループ内でデータベースリクエストを発生させていないか？
- 新しいクエリに対応する index はあるか？高頻度クエリはデータ量が増えると遅くなるか？
並行性と状態
- 安全でない race condition はないか？
- クロスリクエストの共有状態は適切に保護されているか？
信頼境界
- 外部入力は検証されているか？
- ユーザー入力に悪意のある payload でロジックを回避できる可能性はないか？
エラー処理
- Retry logic に idempotency 保護はあるか？
- 外部 API 呼び出しが失敗した時、システム状態は整合性を保っているか？
- Partial failure の可能性はないか——一部は書き込まれ、一部は書き込まれていない状態？
リソース管理
- 接続、ファイル、メモリは使用後に適切に解放されているか？
- 孤立したアップロードやデータの孤立問題はないか？
実行後、/review は問題を「Critical」「High」「Medium」に分類し、各問題の具体的な場所と修正提案を出します——「ここに問題があるかもしれない」ではなく、「47 行目のこのクエリはユーザー数が 10K を超えると遅くなり始める。理由は index がないためで、user_id の composite index を追加することを推奨」という具体的なものです。
Greptile 連携：2 層レビューで見逃しなし
repo に Greptile（自動化 PR レビューツール）を接続している場合、/review はステップを 1 つ追加します：Greptile のコメントを読み込み、分類して処理します：
- 有効な問題：critical findings に追加し、修正されるまでリリースしない
- 修正済みの問題：自動的に確認応答
- 誤検知（false positive）：自動的に却下し、説明を添付
この設計の意義は：Greptile がパターンをスキャンし、Gstack が判断する——2 層フィルタリングで見逃し率を低下させます。さらに Gstack は確認された誤検知を記録し、次回同じパターンに遭遇した時は自動的にスキップします——使えば使うほど賢くなり、毎回同じ説明をし直す必要がありません。
/ship：Release Engineer の SOP
/ship は「コードを push して」ではありません。完全なリリースチェックリストの自動化版です：
- Sync main — ブランチが main と同期されているかを確認し、マージコンフリクトを回避
- Run tests — すべてのテストを実行し、regression がないことを確認
- Resolve Greptile issues — Greptile がマークしたオープンイシューを処理
- Push branch — remote にプッシュ
- Open PR — プルリクエストを作成し、明確な説明を添付
5 つのステップが 1 つのコマンドで。
シンプルに聞こえますが、こんなことはありませんか：コードを書き終えて興奮してすぐ push し、テストが走っていない、ブランチが sync されていない、PR の説明が空——そしてレビュアーに差し戻されて、機能を書くより多くの時間を後始末に費やすことに。
/ship の存在は、この「機械的な正しいフロー」をあなたの状態に依存しなくさせるためのものです——深夜に締め切りを追っていても、Slack に割り込まれた直後でも——リリースチェックリストの実行品質には影響しません。
/review と /ship の正しい組み合わせ順序
必ず先に /review、次に /ship——同時に実行せず、review をスキップして直接 ship もしないでください。
理由は明確です：/ship はフローが正しいことを確認しますが、コードの品質は確認しません。N+1 クエリがあってもお構いなしで、ブランチが sync されているか、テストが通っているかだけを気にします。
正しいフロー：
実装完了
↓
/review ← 問題を見つけ、修正
↓
問題が修正され、critical findings がすべて処理された
↓
/ship ← リリースチェックリストを実行し、プッシュ
時には「今回の変更は小さいので review は不要」と確信していることもあります——スキップしても誰も止めません。でも何か問題が起きたら、振り返って実行しなかったことを後悔するでしょう。
知っておく価値のある細かい話
/review が実行する時、git diff を読みます——今回変更されたコードだけを見ており、codebase 全体ではありません。
これは重要で、2 つのことを意味します：
- codebase が大きくても遅くなりません——変更の範囲だけを見るから
- 見つける問題は「今回の変更が引き起こした問題」であり、「codebase 全体のすべての問題」ではない
だから大規模なレガシー codebase があっても、/review を実行すると数百の古い問題が出力されるのではないかと心配しなくていいです——今回あなたが変更したものだけに注目します。
コードの品質が確認でき、納品フローが自動化されました——次は Gstack の最もユニークな部分：AI に本物の目を与え、アプリを見せる。
→ QA と Browse：AI に目を与えて、アプリを本当に「見せる」
シリーズ総覧に戻る
この記事は Gstack シリーズの第 4 回で、/review と /ship に焦点を当てています。完全な読書ルートと他の記事のトピックは Gstack 入門コース に戻って確認してください。