はじめに
NE開発ブログ、開幕アドカレの6日目です。
プルリクのサイズは小さい方が良い。
ただし大きい/小さいの定義は人それぞれ。
また大きいかな？小さいかな？を自身で気付くタイミングがない。
↓
ということで組織全体として大きい/小さいを定義して、プルリク作成時に気付ける/意識できるような仕組みを作ってみました！
作ったもの
仕組み解説
基本的にyml見てくださいにはなるんですが
git diffを見て
- 追加差分
- 削除差分
- 合計差分
- 差分ファイル数
を集計しプルリクエストにコメントする形になっています。
Githubの差分の出し方についてはこちらの記事で解説をしています。
スクリーンショット
以下のようなコメントが届きます。
問題がない時
閾値を超えた時
仕様
- プルリク作成時/追加push時に発火します。
- 問題があってもなくても発火の度にコメントされます。
- 警告を出す閾値は500行、10ファイルです。
- 環境変数にしてあるのでデプロイなく変更が可能です。
- これは仮置きでリポジトリやPJ毎に適切な値に設定してもらう想定でいます。
- ただプルリクにコメントが投稿されるだけです。
- これを守らないとmergeできない、などの制約は今の所ありません。
- 目安として導入している感じです。
- テストディレクトリ配下は差分としてカウントされません。
- テストいっぱい書いたために警告される、というのは本質的ではないので除外しています。
- たくさんテスト書いてください！
効果
2023/02/13にこの仕組みを入れたのでその前後でのプルリク数を比べてみようと思います。
対象期間
2022/10/28 ~ 2023/02/13 108日
2312プルリク
2023/02/13 ~ 2023/06/01 108日
3166プルリク
3166/2312 = 1.36937716263
約1.37倍
導入前後で比べて1.37倍もプルリクが増えました！
もちろんこの仕組みだけの要因ではないとは思いますが、少なくとも「プルリクを小さくすることを意識する」という点で貢献できたように思います。
まとめ
今後は適切な閾値を見定めて、組織に浸透してきたら「閾値を超えていたらマージ禁止」までできるとより効果が出る気がしています。
プルリクサイズを小さくしデプロイ頻度を上げ、生産性を上げていきましょう！
NE株式会社のエンジニアを中心に更新していくPublicationです。 NEでは、「コマースに熱狂を。」をパーパスに掲げ、ECやその周辺領域の事業に取り組んでいます。 Homepage: ne-inc.jp/
Discussion