Findyの爆速開発を支えるテクニック

こんにちは。

Findy で Tech Lead をやらせてもらってる戸田です。

早速ですが、これは弊社のとあるチームの1ヶ月のサイクルタイムです。

最初のコミットからマージされるまで平均3.6時間程度と、開発に着手したらその日のうちにリリースされるのがデフォルトとなっています。

今回はこの開発スピードを継続し、更に速くするために弊社で実践しているテクニックを紹介していきます。

それでは見ていきましょう！

タスク分解
Pull requestの粒度
テスト
CI/CD
- 高速化
- 自動化
通知
まとめ

タスク分解

開発タスクをアサインされた時、まず最初にタスク分解をします。

タスク分解をすることによるメリットとしては、

工数見積もりの精度が上がる
対応方針の認識を他メンバーと合わせやすくなる
対応漏れに気づきやすくなり、手戻りの発生が少なくなる
Pull requestの粒度を適切に保つことができる
他メンバーへの引き継ぎをしやすくなる

などが挙げられます。

分解したタスク毎にPull requestを作成することで、Pull requestを小さく作り続けることが可能になります。

マークダウン記法のチェックボックスを使ってIssueにタスクリストを洗い出します。

終わったタスクから順にチェックボックスにチェックを入れ、タスク管理をします。

良いタスクリストを作成するためのコツは、最初から完璧なタスクリストを作ろうとしないことです。

まず最初に大枠のタスクを考え、そこから分解していくように意識してタスクリストを作成すると、結果的に詳細なタスクリストが完成しています。

完成したタスクリストを元にPull requestを作成していくと、結果的に適切な粒度でPull requestを作成できるようになるはずです。

例えば、何かしらのデータの一覧を返すREST APIを追加する場合、次のようなタスクに分解できます。

- [ ] APIの仮実装を行う
    - [ ] APIのエンドポイントを決める
    - [ ] APIのresponseの形を決める
    - [ ] モックデータを返す
- [ ] データベースからデータを取得して返す
- [ ] 検索条件に対応する
    - [ ] id
    - [ ] nameの部分一致
- [ ] ソートに対応する

小さくコツコツと修正を上乗せしていき、最終的に完成形に近づけていくような分解の仕方が良いでしょう。

大きな機能の実装担当になった際に、一度に全ての機能を実装するのではなく、小さい機能追加を何回も繰り返して結果的に大きな機能を完成させるようなイメージを持つと良いです。

まずタスク分解をして作成したタスクリストを他のメンバーにレビューしてもらいます。そこで認識を合わせることで、開発の進行がスムーズになります。

分解したタスクに沿って開発を進めていくと、そのタスクも更に分解したほうが良いことに気づくこともあります。

その際はどんどん分解していきます。結果的に分解されたタスクそのものが知見となり、今後の開発の参考になるからです。

Pull requestの粒度

Pull requestを小さくすることで開発生産性が改善することは既に知られている事実ですが、小さすぎても問題が出ます。

じゃあどうするのか？という話になりがちですが、これはPull requestのサイズを気にしすぎていて粒度を考えていないために起こる問題です。

Pull requestを 小さくするのではなく、粒度を考える ことが、小さいPull requestを作り続けるための秘訣です。

では適切な粒度とはどういったものなのでしょうか？それは、一つのことだけに注力している Pull requestです。

具体的に幾つかの例を挙げましょう。

例えば、「関数名を変更したので、それを利用してる1万行を一括置換したPull request」があるとします。

これは適切な粒度だと言えます。変更行数は1万行でサイズは大きいかもしれませんが、「特定の関数名を一括置換する」という1つのことしかしていないため、粒度としては適切です。

Pull requestの概要欄に一斉置換した旨を書いておき、CI通れば即mergeでOKです。 ※後述するように自動化テストが充実しており、守れるテストになっている前提です

では「画面の開発中に別の画面のリファクタを入れ、変更行数は20行程度だったPull request」はどうでしょうか？

これは適切な粒度とは言えません。変更行数は20行でサイズは小さいかもしれませんが、「画面の開発」と「別の画面のリファクタ」という２つの事を同時にしているため、粒度としては不適切です。

仮に画面の開発の部分で不具合が発生しrevertが必要になった場合、画面の開発部分だけではなく別の画面のリファクタの部分も同時にrevertされてしまいます。

適切な粒度を考える上で、Pull requestの存在意義が多岐に渡っていないかどうか？ ということを考えると良いです。

粒度が大きすぎると出てくる問題は色々とありますが、

レビューに時間が掛かり、レビュワー目線で考えるとレビューに対して精神的に負荷がかかる
どこをどうレビューしたら良いのか分かりづらいため、レビューの質が下がり、結果的に不具合の発生率が高くなる
Pull request上でのコミュニケーションが必要以上に増えてしまう
不具合発生時の影響範囲が広くなり、原因の特定に時間がかかる
etc

などが挙げられます。

Pull requestが大きすぎること自体の原因は組織によって異なりますが、Pull requestの粒度が大きすぎることは、システム開発において何のメリットも生み出さないのです。

適切な粒度を維持し続けることにより、Pull requestのレビューに対する負担が減るためレビュー自体の質が上がることに加え、レビューの優先度が上がることに繋がり、結果的に開発スピードと品質の両方を担保できます。

テスト

実装コードに加えて、それの動作を保証するテストコードを同じPull request内で用意することをマストとしています。

実装コードよりもテストケースやテストの内容に対するレビューの方が多いこともあります。

弊社ではテストのカバレッジに対しての大きな拘りは特にありませんが、カバレッジよりも重要視していることがあります。

それは、そのテストが「守る」テストになっているかどうかです。通るべき時に通り、コケるべき時にコケるテストになっているかどうかが重要なのです。

例えば正常系の次のようなテストコードがあるとします。

const mockOnSuccessCallback = jest.fn();
const mockOnErrorCallback = jest.fn();
const { result } = renderHook(() => useHoge({ onSuccessCallback: mockOnSuccessCallback, onErrorCallback: mockOnErrorCallback }));

act(() => {
  result.current.handleSubmit();
});

expect(mockOnSuccessCallback).toHaveBeenCalledWith('test');

hooksの関数を実行し、成功時に引数で渡したコールバック関数が実行されることを確認しています。

一見何の変哲もないテストコードですが、このテストコードには次の視点が抜けており、守るテストとしては不十分なのです。

成功時の関数が複数回実行されたとしても通ってしまう
エラー時のコールバック関数が実行されたとしても通ってしまう

こういったケースでは、弊社では次のようなテストコードが良いとされています。

const mockOnSuccessCallback = jest.fn();
const mockOnErrorCallback = jest.fn();
const { result } = renderHook(() => useHoge({ onSuccessCallback: mockOnSuccessCallback, onErrorCallback: mockOnErrorCallback }));

act(() => {
  result.current.handleSubmit();
});

expect(mockOnSuccessCallback).toHaveBeenCalledTimes(1);
expect(mockOnSuccessCallback).toHaveBeenCalledWith('test');
expect(mockOnErrorCallback).not.toHaveBeenCalled();

このテストコードにより、「成功時に1回だけコールバック関数がパラメータ付きで実行され、エラーのコールバック関数が実行されない」ことを守ることができます。

この2つのテストコードのカバレッジは変わりませんが、テストとして守ることができる内容が異なります。

弊社ではカバレッジよりもテストが守る内容の方に重きを置いており、結果としてカバレッジが上がっているだけなのです。

弊社のリポジトリではテストカバレッジが90％を超えているものも珍しくないですが、それはカバレッジを意識してテストを書いたのではなく、守るテストを書き続けることによって勝手に上がったものなのです。

このような一定の品質以上のテストコードが存在することにより、ライブラリのバージョンアップや既存処理のリファクタなどは「CI通れば即mergeでOK」という文化が根付いています。

全ての修正に対して動作確認を行うことは無く、テストコードのお陰でスピードと品質の両方を担保する状況を維持し続けることを実現しているのです。

CI/CD

弊社のCIのほとんどはGitHub Actionsで統一しています。

弊社ではPull requestが作成されるたびにテストやLinterなどを実行し、レビューの効率化やコードの品質を一定に保つようにしています。

高速化

CIの速度には非常に拘っており、様々な高速化の工夫をしています。CIの実行速度が遅いと、Pull requestをmergeするまでの時間が長くなってしまい、結果的にクリティカルパスになってしまうからです。

1つ目はキャッシュの活用です。GitHub Actionsが提供している各種パッケージをキャッシュする仕組みを利用することで、CIのセットアップに必要な時間を削減することが出来ます。

弊社ではいくつかのプロジェクトに Nx を導入しており、Nxが持つ変更検知機能とリモートキャッシュ機能によってCIを大幅に高速化しました。

2つ目はテストコードの実行を並列化することです。GitHub Actionsのmatrixと呼ばれる機能を利用し、CIのワークフローそのものを並列実行できるようにしています。

テストファイルをいくつかのグループに分類し、それぞれのワークフローにグループごとのテストファイルを割り当てる独自のスクリプトを用意しています。

1つのワークフロー内で全てのテストファイルを実行してしまうと、テストファイルの数に比例してCIの実行時間が長くなっていきます。

しかしグループ分けをしてワークフローを並列実行することで、CIのトータルでの実行時間はほとんど変わりませんが、CIが完了するまでの時間を一定に保つことが出来るようになります。

詳細は別記事の方でも紹介しているので、興味がある方はそちらもご覧ください。

3つ目はGitHub Actionsのワークフローが実行される runnerのスペックを上げることです。

runnerのCPUのコア数やメモリを増やしたマシンを利用できるように設定し、テストコードの実行コマンドを見直して、同じワークフロー内でもテストコードを並列実行できるようにしています。

つまりワークフローそのものと、ワークフロー内の両方の並列化を実現しています。これにより、弊社では最大で40個のテストファイルを並列実行しているリポジトリもあります。

runnerのスペックを上げることにより利用料金の大幅な増額が予想されますが、GitHub Actionsの課金はrunnerの総実行時間に対して行われており、ワークフロー自体の実行が高速化される分、結果的に総実行時間が短くなり、課金額が必要以上に膨らんでしまうことを防いでいます。

自動化

CI高速化以外にも業務の効率化のため、ほぼ全てのプロジェクトにリリース作業を自動化する仕組みを取り入れています。GitHub Actionsのワークフローを手動実行するだけで、リリース用のPull requestが自動生成され、それをmergeするだけで自動的にstaging/production環境へのデプロイが実行されるようになっています。

更にPull requestのLabelsやAssigneesを自動で設定するようにもしています。

このように手間とコストを掛けてでもCI/CDの高速化と自動化の両方を実現させています。