# Code review コードレビューの自分なりの考え
システム仕様通りに作っているかどうか、チーム全体の統一性を保つために、コードレビューを行うべきだが、なんでするか、どうするかを自分なりに考えました。
コードレビューとは、開発内容を作業ブランチにマージする前にプルリクエストを作成して、責任者がソースコードをチェックすること。
# コードレビューのメリット
- システム仕様の確認と把握
- メンバーのスキルが向上
- 設計などの情報が共有
- コーディングスタイルの統一
- チーム内コミュニケーションが活発に
# コードレビューによるチーム内トラブルを回避すべき
コードレビューでやり方や書き方についての議論がヒートアップしてしまうことはよくあります。責任者と指摘された開発者ともに平穏な気持ちで言葉遣いを注意しながら行うべき
やり方は統一すべきですが、チームで開発する以上、完璧を目指すべきではありません。どうしても納得できない場合は妥協を選んでチーム開発が円滑に進められることを優先すべき
コードレビューでチームトラブルを避けるために、コーディングルールを明示し、雑談も交えてチームコミュニケーションをとるべき
# コーディングルールについて
コメントが必要に応じて書いてるか、ネーミングがわかりやすいか、アルゴリズムが簡潔にしているか、重複設計があるかの点において Lint config ファイルを設定したり、ドキュメントでチーム内に共有したりすることが重要。
必要以上に細かく決めないこと、他のメンバーの意見を受け入れてプロジェクトによってルールを調整することも大事
タブは半角かスペース 2 つなのか、4 つなのか、改行は LF か CRLF か、プログラムフォーマットツールは何にするかなどなどをチーム内共有することで、意見交換で勉強にもなる
# コードレビューの手順
- 開発仕様を確認
- 自分の開発環境で実行し、エラーが出ないかもチェック
- 開発ルールに従っているかソースコードを確認
- 仕様以外のものは一緒に混ざっているか
- アルゴリズムは簡潔でわかりやすいか
- 例外処理の対応ができているか
# コードレビューの注意点
- プログラムと人を否定しない
すべての人とすべてソースに意味がある、立場が違う、考えが違うだけ
高圧的な態度や高揚して人を否定することは許されないもの、新人であろうかベテランであろうか尊敬する、勉強させていただく気持ちで接する
- 相手の考えを聞く、自分の考えを伝える
一方的な押し付けは気持ちよくないもの、相手は考えがあってプログラムを書いたから、その考えを理解してから自分の考えを伝える
- 良いところを認める
上には上がある、勉強になった、良かった時は素直に認める、褒める、シエアする
2022-10-10