Goコードレビュー は何をしますか？
目標：変更によってコードベースがより健全になること。完璧である必要はありません。 個人的な好みで変更をブロックしないでください。
ステップ1：変更を取得する
- ユーザーが差分、PR、またはファイルを提供した場合は、それを使用します。
- gitリポジトリの場合：
git diff --stat main...HEAD、次にgit diff main...HEAD（mainが存在しない場合はmasterまたはorigin/mainを試してください）。 未コミットの作業の場合：git diffおよびgit diff --staged。 - 変更の目的が不明な場合は、短い一文で質問してください。
ステップ2：コンテキストを読む
- 変更された関数を含むファイル全体を開き、差分行だけでなく全体を確認します。
- 変更されたエクスポートされた関数の呼び出し元を見つける：
grep -rn "FuncName(" --include=*.go go.modでGoのバージョンを確認します。一部のアドバイスはこれに依存します （ループ変数はGo 1.22以降、イテレーションごとです）。
ステップ3：ツールを実行する（コマンドを実行できる場合）
go build ./...
go vet ./...
go test -race ./... # リポジトリが遅い場合は変更されたパッケージのみ
golangci-lint run ./... # インストールされているか、リポジトリに設定がある場合のみ
実際の失敗を報告します。フォーマットについては、「gofmtを実行してください」と一度だけ言い、すべての行を列挙しないでください。 コマンドを実行できない場合は、その旨を一行で伝えてください。
ステップ4：この順序でレビューする
まず大きなものから。設計が間違っている場合は、それを最初に言い、細かい点はスキップします。
- 設計 – この変更はここ（このパッケージ、このサービス）に属するか？システムの残りの部分に適合するか？今が適切なタイミングか？
- 機能性 – 作者が意図したことを実現しているか？それはエンドユーザーや将来の開発者にとって良いことか？エッジケースと並行性を考慮しているか？
- 複雑性 – 読者がすぐに理解できるか？過剰エンジニアリング（将来を想像したコード、現在の問題に対するものではない）に注意する。
- テスト – 同じ変更にテストはあるか？コードが壊れた場合にテストは失敗するか？テストはシンプルか？
- 命名 – 明確で、長すぎず、Goスタイルに沿っているか？
- コメント – 何ではなくなぜを説明する。古くなったコメントや完了したTODOは削除されているか？
- スタイル – gofmt、スタイルガイド。個人の好みはNitのみ。
- 一貫性 – スタイルガイドが周囲のコードよりも優先される。ガイドに記載がない場合は、周囲のコードに従う。
- ドキュメント – README、godoc、設定/環境変数、移行が更新されているか（動作が変更された場合）。
- すべての行 – すべての人間が書いたコードを読む。生成コード（
*.pb.go、モック、sqlc出力）はスキップしてもよい。 - コードヘルス – システム全体はこの変更で良くなるか悪くなるか？
- 良い点 – 実際に良い点を挙げる。
各領域のGo固有のチェックについては、references/go-checklist.mdを参照してください。
常にそのエラー、並行性、リソースのセクションをチェックしてください。ほとんどのGoのバグはそこにあります。
重大度ラベル
- ブロッカー – バグ、データ競合、goroutineリーク、セキュリティ問題、壊れたテスト、誤った設計。マージ前に修正必須。
- Should fix – 実際の問題だが緊急ではない。作者は議論できる。
- Nit – 小さな任意の改善。常にコメントを「Nit:」で始める。
- 質問 – 理解できない点。理解できなければ他の人も理解できない。より明確なコードを求める。
問題をでっち上げないでください。良い変更には短いレビューを。 バグかどうか確信が持てない場合は、ブロッカーではなく質問を使用してください。 一部のファイルや側面のみのレビューを求められた場合は、レビューした部分を明示してください。
出力形式
## サマリー
変更内容を1〜2文で。判定：承認 / コメント付き承認 / 変更が必要。
## ブロッカー
- `path/file.go:42` – 何が問題か、なぜ重要なのか。
```go
// 修正提案
```
## Should fix
## Nits
## 質問
## 良い点
## 確認した内容
実行したツールと結果、レビューしたファイル、スキップしたもの。
空のセクションは省略してください。各コメント：問題、理由、修正。簡潔に保つ。