新しい人が入ってきた時とか、自分が新しいチームに入った時とかに、自分の開発スタイルを共有しておいたほうが良いと思うので、スッと渡せるようにここにまとめておく。
ぼくの開発スタイルは以下のようなものである。
- PRを小さくシンプルにすること
- スピードで質を担保すること
- レビューが3往復以上になったらペアプロすること
- ドキュメントは極力書かないこと
- PRを盛り上げること
PRを小さくシンプルにすること
PR（プルリクエスト）はできるだけ小さくシンプルにする。
そのほうがレビュワーの負担も減るし、コンフリクトのリスクも減るし、進捗率がわかりやすくなる。
具体的にはPRは大きくても7ファイル100行以内の差分に抑える。
それを超えるようであれば分割するし、なんなら1ファイルとか1行だけの差分でPRを作ることもよくある。
ただ、import先の修正とか、単純作業による一括変換で差分が大きくなっている場合は例外とする。
そのへんはレビュワーの負担も抑えられるのでよし。
逆にクソでかPRを出してくる人には積極的に分割を勧めるので、そこはご容赦ください。
PRは大きくなればなるほどレビュー漏れが発生するので、コードの品質を保つためにも必要なことだと思ってる。
スピードで質を担保すること
個人的にスピードを上げて試行回数をあげることで、不具合や考慮もれに気づいて質を高めていくスタイルが好きだ。
自分の性格が大雑把でせっかちなことも影響してると思う。
PRを小さくして、細かく何度もレビューを繰り返すことで気づくことは意外と多い。
もちろんスピードをあげることで時間が余って、そこでコードの見直しやリファクタに時間を当てることもできる。
スピードの基準の定義は環境によって異なるので一概には言えないけれど、1人あたり2PRが毎日マージされて、週1でリリースできていれば良いかなと思う。
もちろんスピードを求めるにはCIが整っていたり、不具合を検知できるテストが整っている必要があるので、スピードが出ていないと感じるときはそこから手をつけると良いかもしれない。
ぼくは常にスピードで品質を担保していきたい。
レビューが3往復以上になったらペアプロすること
特に新しい人が入ってきたときや、逆に自分が新しいチームに入ったときは、知見が足りなくてPRのレビューが3往復以上になることがある。
そういうときは、更にレビューを重ねるよりも実際に横でペアプロしてもらったほうがお互いに楽になることが多いので、積極的にペアプロを提案するようにしている。
自分が出したPRでも、シニアエンジニアが出したPRでもペアプロをお願いするように心がけている。
ペアプロをすることによる知見は意外と大きくて、
- コードを書くときに何を考え、何を気をつけているのかがわかる
- どんなツールやコマンド、ショートカットを使って作業しているのかがわかる
- 困ったときに何をどんな検索ワードで調べて、参照しているのかがわかる
など、コードを見るだけではわからない大事なことを共有できる。
一緒にコードを書いていけば、レビューをする手間も省けるので一挙両得だ。
毎回ペアプロをすることはできないが、レビューが3往復を超えるという一種のアラートが発生していたら、ペアプロによって対処していきたい。
ちなみに、ペアプロの細かいやり方については以下を参考にしてる。
uasano.hatenablog.com
その他の参考にしてる記事はこのへん
ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
ドキュメントは極力書かないこと
開発に伴う設計書やクラス図、モデル図などは極力書かないようにしている。
なぜなら、そういった知見はコードに全て含めるべきだと思っているからだ。
ドキュメントは、作成したその瞬間からメンテナンスの必要性が発生する。
開発における仕様変更は日常茶飯事なので、先週作成したドキュメントの情報が参考にならない、酷いときには間違った情報に誘導する可能性がある。
それよりも、そういった設計は直接コードで実装するべきだし、仕様はテストで担保していくべきだと思う。
逆に言えば、コード以外のものをメンテナンスしたくない。
各チームで共有するAPI仕様書や、フロントで実装する画面デザイン資料などはもちろん必要だし、見積もり書なども作るが、それいがのドキュメントは極力書かないでいきたい。
PRを盛り上げること
PRでのやりとりは文字による人間味のないものになりがちなので、時に表現のすれ違いから険悪なムードになってしまうことがある。
チーム開発の心理的安全性を確保するためにも、PRは楽しいものでありたい。
そのために、ぼくはレビューしたらLGTM画像を貼るようにしてる。
（画像はleakcanaryをプロジェクトに入れてもらったときのapprove）
ちなみにLGTM画像は以下サービスにいつもお世話になっています。
LGTM画像を驚くほど簡単に作れるWebサービス with Scala
LGTMoon
あとは、commitにはEmoji Prefixをなるべく使うようにしたり、PRのコメントにも絵文字で感情を表すようにしたり。
Emoji Prefixはこんな感じで運用している。
gist.github.com
世間で言われるように、チームにおける心理的安全性はとても大事なので、こういった表現で少しでも確保していければなと。
こういう記事を過去に書いているので、まずは自分自身がしっかりしていかないと。。。
新人プログラマをレビューで殺さない方法
PRをなるべく盛り上げることでレビューを活発にして、より強いチームを実現していきたい。
これらのスタイルは、ぼくがチームの生産性を最大にできると思っているものだ。
チームの生産性が高まる他の方法があれば、それも活用したいし、自分のスタイルも変えていきたいと思う。
チームとして強くなっていきたい。
