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

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

[peroon]

他人が見て分かりやすいコミットの仕方

[potato777]

レビュアーの負担を減らすためにpull request前にはrebase。

[gigi-net]

参考になる

[masayki]

あとで

[ruedap]

理想的な流れだと思った。このコミットの仕方は面倒で徹底できてないけど、できるだけやりたい

[deeeki]

“レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです” "レビューはおたがいさまな作業です。 レビュアーを思いやりの精神を全員が持つと円滑に開発がまわるでしょう"

[katsyoshi]

memo

[raimon49]

自動マージができない場合はレビュアーがOKを出してブランチの内容を把握しているレビュイーに手動マージしてもらうというポリシー。なる。