コードレビューのときに見ているところ - 詩と創作・思索のひろば

あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト

[Windymelt]

コメントをPRではなくコードに書いてほしいのめちゃわかる（コードは残るから）

[otchy210]

あと、TODO にチケット ID 書いてもらうと良い。「後でやる」と心の中で思ったならッ！その時スデにチケットは切っているんだッ！

[manhole]

レビュー時は、プルリク本文やコードに書かれていないことに敏感になろうと心がけています。

[Error401]

「コメントにWHATは書くな」は本当に悪い風潮。内容の理解が容易になるWHATは書くべき。

[surume000]

モデリングというのは設計くらいの意味かな

[iekusup]

ほー。

[pmint]

結局「自分が書くなら」と比べることになりそうだけど、「許容できるか」で考えないといけない。まあコピペしやすそうならいいコードなんじゃないのかな。訊ねられてもそう答える。

[to4iki]

“読み手の負荷が高くないか”

[degucho]

全ての行で意図の説明ができるか、かなあ

[opnihc]

読み手の負荷が高くないかは最優先だな。トリッキーなロジックもここに含む

[tasukuchan]

“議論”

[Palantir]

こういうの財産だよね。ISOとかが定めないかね

[taruhachi]

既存コードの改修に関するコードレビューのようなのでもう一点、既存コードの流儀に沿っているかどうか、アドホックな改修になってないかを追加したい。局所的対応をしたくなるので陥りがち。