- 自己紹介
- 本編
- 議論
- 議題が終了した場合はTodoアプリの仕様決め
-
- Step-to-Rails-Expert.rb主催者
- LICTOOR株式会社所属
-
- Step-to-Rails-Expert.rbスタッフ
- 業務でRailsを利用している
-
- taskey Inc.所属
- 会社で唯一のバックエンド
- れびゅーない
- onkcopだけ
- danger?
-
- rails2年目
- 前職でrailsメインで使っていた。
- 今のチームでレビューをうまく回したい
-
- feedforce エンジニア
- Rails Developers Meetup の運営とか
-
10~50のコメント数でクローズ
-
時間がないときは実力者が最終的に手を入れてしまう(その後フィードバック)
-
席が近いと話した方が楽な場合も多い
-
デザイナーさんのcssもレビューするときがある(ソース把握の意味もこめて)
-
その Issue や、タスクの完了条件を事前に明確にしておく。(正しさの判断をなるべく人に寄せない)
-
絵文字使ったり画像使ったり表現を柔らかにする
-
nitとかimo(in my opinion)とか使う
略語の全集?
ただし、共有認識でない場合共有が面倒・・・(最初に共有すべき) -
reauest changesとcommentで用途を分ける(必須/できれば)
-
疑問系で伝える(断定表現・命令表現を避ける)
OSSとかだと、PR投げたときにまず褒めてくれることが多い(ただし最後に落とす) -
コードレビューのお役立ちリンク
下から目線のコードレビュー
-
pivotaltrackerは重み付けができる(trelloはできないできない)
-
重み付け、見積もり、velocityの計算などができるので高機能だが、専任のプロマネがいないと厳しい・・
- approveが2つ以上つかないとマージされない
- 自分以外のメンバーの承認がないとダメ
- レビューの時間を取る
- レビューするときは代案を出す
こう書いた方が良い/資料のurl/snippetなどを提供してあげた方が時間も短縮できるし指摘される方も嬉しい