2019/01/23 コードレビュー

[aloerina01]

コードレビューのベストプラクティス | POSTD

• レビューで注目すること
  • アーキテクチャ
  • 単一責任の原則、OpenClosedの原則
  • 効率
  • スタイル
  • メソッド名、変数名、関数の長さ、クラスの長さ
  • docstring, メソッドの引数の数
• レビューの方法
  • 質問する
  • 褒める、グッドプラクティスを強化する
  • より細かいポイントについて直接議論してみる
  • 理由を説明する
  • 指摘はコードに対して行う(実装した人に対してではなく！)
  • 修正の重要性を提案する

コードレビューを怖がっていた新卒エンジニアが始めた対策 | GMOアドパートナーズグループ TECH BLOG byGMO

• レビューが怖い新人エンジニアの目線を思い出せる話
• 「リーダブルコード」と「プログラマが知るべき97のこと」がおすすめされてた。後者は知らなかった

コードレビューの際に気をつけること - Qiita

• レビュワーのレベルを2タイプで表現していた
  • diffとして見えている問題の指摘ができるレベル
  • diffとして見えていない問題の指摘ができるレベル
• 後者の要素を「副作用の考慮」と「将来生じる問題の予測」と表現していた

そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操

• コードレビューでクオリティを上げるのはコスパが悪いだけでなく危険まであるとのこと
• どうやら上で書いた「diffとして見えない問題の指摘ができるレベル」でないケースでの危険性の話をしている
• コードのクオリティの定義が曖昧なままで結局よくわからない話だった

[aloerina01]

思ったことメモ

• コードレビューでできること、できないことを見極めて目的を分ける
  • コードレビューで品質のコントロールには限界があるけど、いくらかはできる
  • レビュー観点の共有はできる
• レビューの基準をつくるのはむずかしい、というか無理そう
  • こういうことを考えてレビューしたよっていう「着眼点」みたいなことは羅列できるかも
  • 列挙であって網羅ではない