52
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

お題は不問!Qiita Engineer Festa 2023で記事投稿!

生産性を上げるプルリクエスト分割!の前にやるべきこと

Last updated at Posted at 2023-06-15

生産性を上げるプルリクエスト分割!の前にやるべきこと

先日弊チームのメンバー@d510開発生産性 Meetup #1】開発生産性可視化による変化~事例LTから学ぶベストプラクティス~にて登壇発表した内容の裏側について書きます。
(発表スライドはコチラ

「生産性を上げる手段として注目されているプルリクエスト分割取り組みたいけど、すぐできるものなの?まず何からしたらいいの?」について僕らが実際に行ったことについて説明できれば、と。

目次

  • コーディング規約
  • CI/CDの整備
  • 設計の共通認識
  • Gitのルール

コーディング規約

弊チームではTypeScriptを利用していますが、そのコーディング規約としてGoogle TypeScript Style Guideを元に若干のアレンジを加えて設定しました。

アレンジした内容は命名規則が中心で、
xxx.service.tsxxx.utils.tsなどのファイル名周りや、
混在しやすいfetchXxx,getXxx,extractXxxなどのメソッド/関数名の統一など、です。

また、修正が早くなれば、ソースコードとコメントの不一致が起こる可能性も高くなるため、
コメントは原則JSDocのみにするようにしました。

「そもそもコメントを書かないと理解できないって仕様・設計から見直したほうがいいサインなんじゃない?」という話もありました。
とはいえ、どうしても書きたいシチュエーションがあるので、全くコメントがないわけではないですが、、、。

JSDocサンプル
/**
 * リクエスト
 * @see https://docs.google.com/spreadsheets/xxx
 * @template T - リクエストボディの型
 * @template R - レスポンスの型
 * @param {string} uri - URI
 * @param {T} body - リクエストボディ
 * @param {object | undefined} config? - リクエストコンフィグ
 * @throws {ApiError} APIエラー
 * @returns {Promise<R>} レスポンス
 */
async request<T, R>(uri: string, body: T, config?: object): Promise<R> {
  // 略
}

CI/CDの整備

プルリクエスト分割により生産性が上がったとしても、デグレや不具合を起こしては身も蓋もありません。
各プルリクエストでビルドやテストがしっかり通るのか自動で確認できるように整備しました。デプロイに関しても然り。

ただ、利用しているCIサービスによってはアクション数や実行時間の上限の設定がされている場合があると思います。
実際我々もGitHubActionsの実行時間が爆増してしまいました。

どの程度のジョブ数・実行時間になるのかを観測しながら、状況に応じて実行時間の最適化やジョブの並列化、あるいはそもそもこのブランチで実行すべきジョブなのか、などなど対策を検討するといいと思います。

特定ディレクトリ配下の変更時のみ実行サンプル(GitHubActions)
on:
  workflow_dispatch:
  pull_request:
    branches:
      - develop
    paths:
      - 'src/deploy/**'
# 略

参考:GitHub Actionsの課金について

設計の共通認識

実装時はもちろんレビュー時の迷いを減らすために、どのクラスには何の責務を持たせるべきか、という共通認識を取りました。(実際には議論し続けているものにはなりますが)

指摘をする/される際にも「この処理は○○という意味だからxxxに持たせるべきじゃない?」と根拠のあるコメントをすることができるため、個人的には、上述のコーディング規約も合わさって、レビューが非常にスムーズになったと感じています。

また、設計の認識が深まれば深まるほど、どの粒度でプルリクエストを分割するかの悩みも解決するのではないかと思います。
「Xという機能を実装するには、クラスAに処理追加して、クラスBのメソッド直して・・・」と分けて考えられるようになります。

Gitのルール

プルリクエストを分割した分コミット履歴が膨らむのは容易に想定しうるかと思います。
その分、何かしらの不具合が発生した際に問題点の特定/切り分けが難しくなります。

この対応策として、我々は"1プルリクエスト1コミット"のルールを設定しました。
コミット自体を制限するわけではなく、プルリクエスト作成前にgit rebase -i hash値を用いてコミットを一つにまとめようということです。

また、上記のルールとは別に、コミットメッセージも[チケットID]内容で統一を行いました。

参考:サル先生のGit入門:5. rebase -i でコミットをまとめる

最後に

いずれもプルリクエスト分割に限らず活かせるものがあると思います。
プルリクエスト分割を始めようと思っている方々だけでなく、生産性をあげたいと思っている方々に何かしら得られるものがあれば幸いです。
また、「こんなアクションやるといいですよー」などのアイデアがありましたら教えていただけると嬉しいです!

52
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
52
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?