半年ほど前に初めて開発リーダを担当した際に、
- 時間に余裕がない
- メンバー間の実力のばらつきがある
というつらい状況をなんとか乗り切るために
コミュニケーションコストを省くことに重きを置いた開発ルールを
あらかじめ決めておいたら案外上手くいったのでその時のメモを
ブランチ運用
途中参加やgitやgithubを使った開発に慣れていないメンバーへのインプットの手間を削減するため
また、複雑なブランチ運用故に起こる不慣れなメンバーのミスを回避して
フォローに時間を取られないようにするため
- どの作業はどのブランチから切るか
- 切るブランチの命名規則
- 元となるブランチの意味
PRの書き方
レビュイー側の負担を大きくして
ボトルネックになりがちなレビュアーの負担を減らすため
慣れてる人にとっては当たり前でも
不慣れな人にとっては当たり前にできない基本的なことも書いて
コミュニケーションコストカットするため
- チケットのリンクを貼る
- 処理の流れの概要を書く
- 特に見てもらいたい箇所を書く
- 複雑な部分の解説や意図をソース上やPR上でコメントする
- 途中で仕様変更があったりした場合は議論された最終的な結論を書く
- 実装の際に参照したドキュメント(設計書など)を書く
- フロントの実装の場合は一緒にスクショを添える
テストコードの書き方や参考記事のリンク
テストコードは経験値の差が大きく影響するので知見を共有して
可読性の高いコードを書かせるため
(テストコードのレビューは時間がかかるから。。。)
- 行数が膨れ上がりやすいのでディレクトリ切って
describe(対象)単位でファイル分割する - 最低限抑えてほしい異常系の観点
- 可読性やメンテナンス性を上げる
- letを使ってすっきりしたコードにする
- スタブやモックを使ってメソッドのテストを疎結合にする
- など
全体的な作業の進め方
全体的なタスクの状況や実装状況を把握するために
- チケットのステータスをこまめに更新する
- 未着手/進行中/レビュー中/完了のステータスをすぐに反映する
- ブランチ切ったらすぐに[wip]つけたPRを作る
- こまめにpushする
質問の仕方
コミュニケーションコストを下げるために
- 質問の意味がわかるように前後のコンテキストを一緒に
- ログに残す意味も兼ねてissueやPR上でやり取りを
- 急がない場合はメンションつけてissueやPRに書いてslackでも投げて待ってる間に別の作業をする
- 動作は問題ないけどコードが気に入らない、とかは一旦完成させてPR上で相談する
- 質問は極力まとめる
- １つ気になる点があったら他にもないか一通り見てからまとめる
- 不明瞭な部分はそのまま進めず確認する(手戻りがないように
便利なもの集
作業効率を上げるために
- コマンドラインのタブ補完を使う
- ショートカットを活用
- オススメのエディタのプラグインなど