僕がコードレビューの時に気をつけていること｜su-
いきなりがっつりとした記事を書くよりは慣れるために軽めの話を。 こんにちは、すーです。 今回は普段僕がコードレビュ(GitHubのPull Requestのレビュー)の時に気をつけていること、大切にしていることを書いてみます。 (※以降話は主にGitHubのPullRequest(PRと略します)上での話がメインだと捉えてもらえますと) 自分がレビューをするときまずは自分がレビュワーだった場合に、気をつけていることを。 ・ PRの概要、関連するIssueの内容をしっかり読む まずはじめにPRの概要や、関連するIssueの内容を確認します。 何も見ずにいきなりコードに目をやってしまうと的外れなレビューをしてしまう可能性もありますし、コードの善し悪しだけを追いがちになってしまいます。 どういう意図や背景があってこのPRが出されたのかを確認するのはとても大事になります。 ・ コメントに`[MUS
レビューは人に叩かれる場所ではない - Qiita
元記事 自分のコードが批判される不安 一般にエンジニアは、自分の仕事の進行状況(コードの品質や生産性)を他人に見られ、評価されることを恐れます。 あるソースコード管理システムをGoogleが開発した際に、次のようなissueをもらっていました。 「特定のブランチを非表示にする機能を Google Code の Subversion に付与してもらえますか?」 「最初は世界に隠されていて、準備ができたときに公開されるオープンソース プロジェクトを作成できるようにすることはできますか?」 「こんにちは、コードをすべてゼロから書き直したいのですが、履歴をすべて消去してもらえますか?」 これらには「自分のコードや仕事の質を見極められる(誤解される)不安」が見て取れると思います。 自分のコードは完璧な部分だけ見て欲しい 完成されていないコードをみて自分を判断して欲しくない 昔の自分が書いたクソコード
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
