OSSに学ぶ、開発を効率化するTips
presentation@イジゲン BUILD
先日、初めて OSS 開発に携わりました。 ルールにしたがって開発できるかどうか不安だったのですが、開発が属人化しないようにリポジトリにいろいろな工夫がなされていたおかげで、快適に開発することができました。
この工夫を社内に取り入れたら、社内の開発を効率化できるのでは？ということで、今回は OSS 開発で発見した工夫のうち、ぜひ社内に取り入れたいと思ったものを紹介します。
PR のテンプレ
PR の概要をちゃんと書くと、レビュワーの負担を軽減するだけでなく、あとから見返すためにかかる時間を削減できます。とはいえ、PR の概要を書くのは正直面倒なので、社内では書いていないことも少なくありません。
そこでおすすめしたいのが、PR に書く内容をあらかじめ決めて、テンプレ化することです。GitHub では、PR のテンプレを設定する機能があって、新しく PR を作ろうとしたときに概要に見出しが入力された状態にすることができます。これなら、見出しにしたがって項目を埋めるだけで概要が書けますね。概要のフォーマットを統一できるというメリットもあり、一石二鳥です。
issue のテンプレ
PR テンプレートと同じ発想です。issue もテンプレを作ることによって精神的ハードルを下げながらも、レビューしやすいフォーマットに統一することができます。Backlog なら課題に置き換えてください。
テンプレの登録方法は PR とほぼ同じですが、issue がテンプレを複数登録できます。たとえば、バグと機能追加でテンプレを使い分けるなんてことができるわけです。
参考: GitHub の Issue・Pull Request のテンプレート機能を使おう
コミット前にフォーマット
不特定多数の人がかかわる OSS では、コードの書き方についていろんな考えを持った人が集まります。ある人はカッコを省略したいけど、ある人は省略したくなかったりするわけです。
そこで OSS では、コミットする前にステージにあるファイルに対してフォーマッターが実行されるようになっていて、リポジトリのコーディング規約にしたがってないコードはコミットできません。
これにより、リポジトリの管理者が目を光らせなくても、リポジトリ内のコードに統一感を持たせることができます。
コミット前に Lint
フォーマッターと同じ発想で、Linter が実行されるようになっているリポジトリがあります。これにより、バグが含まれているコードやそもそも動かないコードをコミットできないように制御できます。
次のコードブロックは、コミットが弾かれた場合の表示です。ESLint のエラーが表示されて、コミットが拒否されていることがわかります。
$ git commit
/path/to/file.vue
134:10 error 'EventBus' is defined but never used @typescript-eslint/no-unused-vars
134:10 error 'EventBus' is defined but never used no-unused-vars
134:20 error 'TOGGLE_EVENT' is defined but never used @typescript-eslint/no-unused-vars
134:20 error 'TOGGLE_EVENT' is defined but never used no-unused-vars
✖ 4 problems (4 errors, 0 warnings)
error Command failed with exit code 1.フォーマッターと一緒に導入することが多いです。
開発情報を README に書く
OSS においては、開発情報を README に書くのはあたりまえのことです。しかし、社内開発だとやっているところが少ないように思います。不特定多数の人が見るものではないので書かなくてもいいかなと思ってしまいますが、プロジェクトに新しい人が参加したときや久しぶりにプロジェクトを触るときなどは README があったほうがいいです。
以下のような情報が特定のエンジニアに依存してしまうと、担当者不在のときに対応できませんし、プロジェクトに新しくメンバーが入るときもいちいち教えなければいけません。
- リポジトリの概要
- 環境構築の手順
- 環境変数
- ブランチ運用
- テスト環境と本番環境の場所
会社によってはスプレッドシートなどで管理する場合もあるかもしれませんが、個人的には README がいちばんわかりやすいと思います。
ちょっとしたことで開発は効率化できる
開発フローを大きく変えなくても、ちょっとした工夫で開発効率は大きく変わります。取り入れられるものからやってみてください。
