エキサイト株式会社メディア開発の佐々木です。
メディア開発では、github.comを使ってソースコード管理を行っています。人数やプロジェクトが多くなってくるとPullRequestのコメントの書き方がバラバラになってくるので、生産性を確保する為に下記のようなラベルっぽいものを書くことを推奨する方針としています。
[MUST]… (Must)
必ず直してほしいところをコメントで記載します。どう直してほしいのか具体例をつけて書くことを推奨します。メンテしづらくなったり、パフォーマンスが著しく悪かったり、色々な観点がありますが、その観点がコミュニケーションでは大事なので、その点を書くようにします。
(例) [MUST] この実装はパフォーマンスがよくないとおもうので、 `xxxx` を使った書き方になおしてほしいです
GithubのSuggestion機能
明確な修正提案は、GithubのSuggestion機能を使ってもOK。
複数行にまたがる場合は、cmd + 行数で範囲選択ができるので、それをやってからコメントすると作ることができます。
[IMO] (In my opinion)
自分ならこう直すみたいな提案型のコメントになります。具体的にメリット・デメリットも提示しながらコメントできると、チームの実装力が向上するかとおもいます。
(例) [IMO] この部分は、こういう書き方もできるとおもいます
[NITS] (nits pick)
細かい指摘等に対するコメントです。直しても直さなくてもいい程度の修正ですが、なるべく直すような方針にしています。
(例) [NITS] このコメントは不要な気がします
[ASK] (ask)
実装内容がわからないときとかに使います。
(例) [ASK] ここの実装の中身がわからないです
[GOOD] (good)
実装がよい場合にこちらを書いたり、絵文字でアクションすると良いコミュニケーションになので使用します。
(例) [GOOD] この書き方いいですね！
[HELP]
プルリクを発行する人が、いい解決法が見つからないときに、これを書いておきます。わからないところや解決したいことを書いておくとレビュアーが知見や解決方法の提案を書きやすくなります。
(例) [HELP] ここのいい解決方法が思いつかないです。やりたいことは xxx で、ちょっと冗長になってしまっているのを解消したいです。
対応できなかった指摘
指摘をもらったのに、対応できなかったものに関しては、忘れないようにgithub issueをたててもらうようにしています。コメントからissueをたてられるので、便利です。
おわりに
冒頭にも書いたとおり、人数やプロジェクトも増えてくると指摘の仕方やコメントの仕方に関しても、みんなバラバラになりがちで、生産性があがりません。これを是正しようとしてフォーマット等を厳しくすると、これもまた指摘するのが面倒になったり、守られてないプロジェクトなどがでてきて、生産性に寄与しません。現在の部署では最低限のゆるめのフォーマットを使用してある程度はワークしているとおもいます。ガチガチにした方がいいとか いう意見もありますが、生産現場では、生産性の高さが勝負になってくると思います。これからもメンバーのスキルや考え方を見ながら、バランスを意識して開発効率をあげていければと思います。
