[B! CodeReview] toshiwoのブックマーク

Reviewable - GitHub Code Reviews Done Right

Not affiliated with GitHub. GitHub and its logos are trademarks of GitHub, Inc.

toshiwo 2014/11/16

リンク

レビューフレンドリーな開発のしかた - tomykaira makes love with codes

2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。自分が普段の開発でこころがけていることをまとめてみます。前提レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。レビュアーはレビュイーよりも、変更について詳しくありません。レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して

toshiwo 2013/12/16

リンク

コードレビューいろいろ - steps to phantasien

コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque

toshiwo 2012/08/19

リンク

git - Workflow for GitHub-based code review - Stack Overflow

I'm considering using GitHub as our primary tool for doing code review. With features like in-line commenting and compare view, it seems to have a lot of features that tools like Gerr it have on offer. Has anyone else used GitHub for this? If so, what is your workflow? And what have your experiences been doing so, both positive and negative? As I get some thoughts on this and sort out what will wor