コードレビューは否定の道
ソフトウェア開発におけるコードレビューでは、基本的に否定の道によるコードの改善が提案される
バグになりそうな点、バグっているところ
仕様にそっていないところ
保守性がよくなさそうなところ
今後問題になりそうなところ
よく分からかったところ
もっと良い書き方があるところ
褒めや良い点の指摘はあまりない
人は、「ここが何となく嫌だ」「ここに違和感がある」の方が意見しやすい
なので、コードレビューを受ける側はそういう心構えが必要
失敗や辛いことを好む姿勢
批判を耐えきることさえできれば、中傷は大きなプラスになる
しかし、結局のところは、本人に任せて、外野は「明らかにバグになる箇所」や「明らかにパフォーマンス劣化を起こす箇所」などの指摘と理解を深めるための質問に徹するべきであり、「アドバイス」はしないほうがいい
答えを教えない
すぐれた質問とは、答えを求めるたぐいものでは決してない
コードレビューであーだこーだ議論して進まないのはビュリダンのロバ
アドバイスが間違っていた場合の罰則が存在しないかぎり、アドバイスを生業としている人間のアドバイスは真に受けるな
他人からの否定的な意見やアドバイスに対する付き合い方について
「xxxした方がいい」は役に立たない
PullRequest門番制度への懐疑