コードコメントについて

あたりの議論について、久々に思い出した。

ちょうどコードレビューでそういうコメントを見かけたので、上記を引用させていただいた。

@jnchitoさんの言うこれが、「本当にそう」としか言えない。

不要なコメント

説明的なコメント（コードを見ればわかるコメント）

見てもわからないコードはコメントで逃げるのではなく、見ればわかるコードにリファクタリングする

ですよねー😅

レビュワーや未来の自分にコメントなしで伝わるような書き方を心がけたいものです。

以下余談。

最近感じた気づきとして、GitHubのPRをコミュニケーションの場と捉えている人とそうでない人がいるのだなというのがある。

私はPRはコミュニケーションの場であると考えているしそう教えられたと思っている。（明示的にコミュニケーションの場だ、と言われたかどうかは不明だけど同義のことを言われた気がする）

自分がレビュワーになった時に実感するのだけど、すばやく全体像を理解できないと本質的なレビューや議論になかなか進めない。なので、いかにレビュワーの認知負荷を減らせるか、不要な質問の往復を減らせるか、というのをレビュー依頼する際に割と気にしていたりする。

あと細かいところで言うと、動作検証の結果とかテストの実行結果を添付するのはPRを出した人の責務である「ちゃんと動くコードですよ」を担保するためなのだから絶対必要だよね、とか。

レビュワーの責務は、動作検証の項目や手順の考慮漏れがないかとか、コードの中で気になることがないかをチェックする、というようなところだと思っている。

ちゃんと動作することを確認するのはレビュイーの責務であり、レビュワーの責務外なのかなーと。

そうじゃないとレビュワーが破綻すると思うのでこのように考えているが、これは組織によりけりかなというところなので、私がレビュー依頼する際にレビュワーに求める役割はこう、という感じ。

この辺りがずれちゃうとお互い不幸になるので、事前に期待する観点のすり合わせをしておくことが大事だなと思った。