ログイン - はてなパスワードを忘れた方はパスワードの再設定を行ってください。 初めての方ははてなID登録 (無料) してください。 うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
中規模iOS開発とコードレビュー
フリマアプリFrilのリニューアルを題材に、iOS開発でのコードレビュー事例を紹介します
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビューの話