Skip to content

Latest commit

 

History

History
93 lines (63 loc) · 3.47 KB

9th_20170731.md

File metadata and controls

93 lines (63 loc) · 3.47 KB

Step-to-Rails-Expert.rb 第9回

本日の流れ

  • 自己紹介
  • 本編
    • 議論
    • 議題が終了した場合はTodoアプリの仕様決め

参加者の名前

  • ebi

  • two_sann

    • Step-to-Rails-Expert.rbスタッフ
    • 業務でRailsを利用している
  • kuntao

    • taskey Inc.所属
    • 会社で唯一のバックエンド
      • れびゅーない
    • onkcopだけ
    • danger?
  • tackeyy

    • rails2年目
    • 前職でrailsメインで使っていた。
    • 今のチームでレビューをうまく回したい
  • 秒速@284km

    • feedforce エンジニア
    • Rails Developers Meetup の運営とか
  • @sinsoku

議題リスト(テーマ: レビュー・教育)

意見を正しく伝える際に気をつけていること(穏便に伝えたい)

どのようなフローでPRからマージしているか

  • 10~50のコメント数でクローズ

  • 時間がないときは実力者が最終的に手を入れてしまう(その後フィードバック)

  • 席が近いと話した方が楽な場合も多い

  • デザイナーさんのcssもレビューするときがある(ソース把握の意味もこめて)

穏便に意思疎通をとるコツについて

  • その Issue や、タスクの完了条件を事前に明確にしておく。(正しさの判断をなるべく人に寄せない)

  • 絵文字使ったり画像使ったり表現を柔らかにする

  • nitとかimo(in my opinion)とか使う
    略語の全集?
    ただし、共有認識でない場合共有が面倒・・・(最初に共有すべき)

  • reauest changesとcommentで用途を分ける(必須/できれば)

  • 疑問系で伝える(断定表現・命令表現を避ける)
    OSSとかだと、PR投げたときにまず褒めてくれることが多い(ただし最後に落とす)

  • コードレビューのお役立ちリンク
    下から目線のコードレビュー

プロジェクト管理ツールについて

  • pivotaltrackerは重み付けができる(trelloはできないできない)

  • 重み付け、見積もり、velocityの計算などができるので高機能だが、専任のプロマネがいないと厳しい・・

レビューでお決まりの指摘をしないために使うGemを知りたい(例えばRubocopなど)

全般

レビューを効率的に行う制度などを知りたい

  • approveが2つ以上つかないとマージされない
  • 自分以外のメンバーの承認がないとダメ
  • レビューの時間を取る
  • レビューするときは代案を出す
    こう書いた方が良い/資料のurl/snippetなどを提供してあげた方が時間も短縮できるし指摘される方も嬉しい