タグ

2021年4月5日のブックマーク (5件)

  • コードレビューのコメントの書き方

    コードレビューのコメントの書き方 まとめ やさしさを持ちましょう。 あなたの考えの論理を説明しましょう。 問題を指摘して明確な方向性を示すことと、開発者自身に決定させることのバランスを取りましょう。 レビュアのあなただけに複雑なコードの意味を説明させるのではなく、代わりに開発者に対して、コードをシンプルにしたりコードにコメントを追加してもらうようにしましょう。 礼儀 一般に、コードをレビューしている開発者に対しては、非常に明快な態度を取り、助けに満ちた気持ちを示すとともに、丁寧に、尊敬の気持ちを持って接することが大切です。このことを実践する方法の1つは、決して開発者についてコメントをしないで、必ずコードについてコメントをすることを忘れないことです。このプラクティスには必ず従わなければならないというわけではありませんが、このように話さなければ相手を怒らせてしまったり、争いのもとになってしまう

    dondoko_susumu
    dondoko_susumu 2021/04/05
    “コードをレビューしている開発者に対しては、非常に明快な態度を取り、助けに満ちた気持ちを示すとともに、丁寧に、尊敬の気持ちを持って接することが大切です。”
  • コードレビューのスピード

    コードレビューのスピード なぜコードレビューは早くなければならないのか? Google では、開発者のチームが1つの製品を協力して開発する速度を最適化しています。これは、個人の開発者がコードを書くことができる速度を最適化するのとは逆です。個人の開発者の速度が重要なのは確かですが、チーム全体の速度と同じくらい重要というわけではありません。 もしもコードレビューが遅かった場合、以下のような問題が起こってしまいます。 チーム全体の速度が低下してしまう。たしかに、ある個人がレビューに速やかに返事をしなかったとしても、他の仕事を進めることはできます。しかし、各 CL のレビューや再レビューの遅れが積み重なれば、チームの残りのメンバーが行う新しい機能やバグの修正に、数日、数週間、数ヶ月の遅れが生じてしまいます。 開発者がコードレビューのプロセスに抵抗するようになってしまう。もしもレビュアが数日に1回し

    dondoko_susumu
    dondoko_susumu 2021/04/05
    “レビュー対象のコードが来たすぐ後にコードレビューを行なわなければなりません。 コードレビューリクエストに対して、返事をするまでに掛けることが許される最大の時間は、1営業日です。 (つまり、最低でも翌日最
  • レビューで CL をナビゲートする

    レビューで CL をナビゲートする まとめ ここまででコードレビューで期待するべきことが理解できたと思います。それでは、複数のファイルに分散したレビューを最も効率的に行うには、どのような方法で行えばよいのでしょうか? 要点は以下のとおりです。 その変更は全体として意味のあるものとなっているでしょうか? よい CL の説明が書かれているでしょうか? 変更の最も主要な部分を最初に読んでください。CL 全体としてよく設計されていますか? CL の残りの部分を読み、論理的に適切な順序で書かれているか確認しましょう。 ステップ1: 変更に対して広い視野を持つ まず、CL の説明をよく読み、全体として CL が何を行っているのかを理解します。この変更は当に意味のあるものでしょうか? そもそもこの変更が行われるべきものでないのなら、すみやかにその変更が行われるべきではない理由を説明する返事を書いてくだ

    dondoko_susumu
    dondoko_susumu 2021/04/05
    “レビュアは現在の CL をリジェクトして別の代替案を提案していますが、それを丁寧に行っていることに注意してください。このような丁寧さはとても大切なことです。たとえ相手に賛成しないときでも、私たちはお互い
  • コードレビューで何を期待するべきか

    コードレビューで何を期待するべきか 注意: 以下の各ポイントについて考えるときは、必ずコードレビューの基準を考慮するようにしてください。 設計 レビュー中に取り上げるべき最も重要なことは、CL の全体的な設計をどのようにするかということです。CL 中のさまざまなコードのインタラクションは意味のあるものですか? その変更はコードベースかライブラリ、どちらに帰属するべきものでしょうか? システムの残りの部分とよく統合されていますか? その機能を追加するのは当に今が適切なタイミングですか? 機能性 その CL は開発者が意図した通りのことを行っているでしょうか? 開発者は、そのコードのユーザーにとって、どんなよいことがあると考えていますか? ここで言う「ユーザー」とは、通常エンドユーザー (もし変更がエンドユーザーに影響する場合) と開発者 (将来このコードを「使う」必要があるユーザーのこと)

    dondoko_susumu
    dondoko_susumu 2021/04/05
    “コメントが役に立つのは、あるコードが存在するのがなぜかという理由 (why) を説明しているような場合であり、あるコードが何をしているのか (what) を説明するようなものであってはいけません。”
  • コードレビューの基準

    コードレビューの基準 コードレビューの主な目的は、Google のコードベースのコード全体の健全性が、時間の経過とともに改善されることを保証することです。コードレビューのツールとプロセスのすべては、この目的のために設計されています。 この目的を達成するには、一連のトレードオフの間でバランスを取る必要があります。 まずはじめに、開発者は自分たちのタスクを前に進めることができなければなりません。もしあなたがコードベースに対する改善を全く提出しなければ、コードベースが改善することは決してありません。また、レビュアがあらゆる変更を加えるのを非常に難しくしてしまえば、開発者が将来改善を加えようとするインセンティブが失われてしまいます。 一方で、各 CL が、時間が経過してもコードベースのコード全体の健全性が低下しないような高い品質を備えていることを保証することも、レビュアの義務です。しかし、それはや

    dondoko_susumu
    dondoko_susumu 2021/04/05
    “コメントの最初に “Nit: “ (訳注: 些細な点という意味、ニッチの単数形) のようなキーワードを付けて、作者に改善可能な点だが改善するか否かは作者に委ねる、ということを知らせてあげましょう。”