Findyの爆速開発を支える、価値提供を最優先にするための開発手法

こんにちは。

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

このテックブログでは開発生産性を向上させるための取り組みや、開発テクニックを紹介してきました。

意外に思われるかもしれませんが、弊社では全てのことを100％でやってるわけではなく、ユーザーへの価値提供を最優先するために後回しにしている部分もあります。

しかし、その影響で障害が多発したり、困ったことになることは滅多にありません。

そこで今回は、ユーザーへの価値提供を最優先するために弊社で実践していることを紹介していこうと思います。

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

綺麗なコードは後。アプリケーションの振る舞いが先。

Pull requestをレビューする中で、「もっと良い書き方がありそうで、議論が長引いて中々マージされない」といったケースがあるかと思います。

そのような場合、弊社ではテストが網羅されていればマージしてOKというスタンスを取っています。

もちろん、パフォーマンスやセキュリティ等に悪影響が出るようなコードはマージしませんが、基本的にはアプリケーションの振る舞いに影響がなければマージします。キレイなコードを書くことは非常に重要ですが、ユーザーが求めているのはアプリケーションの振る舞いであるからです。

マージ後に良い書き方を思いついたら、そのタイミングでリファクタのみの修正を行ったPull requestを出します。

後でリファクタするとしても、アプリケーションの振る舞いをテストコードで守っているので、強気でリファクタできます。

弊社のとあるリポジトリでは、リファクタのPull requestが1ヶ月で50個程度作成されていました。思いついたり気づいたりしたら日常的にリファクタを行う文化が根付いている証拠です。

このように、最初の段階で綺麗なコードを突き詰めることよりも、ユーザーに早く価値提供をすることを優先しています。テストコードの存在が、このような開発手法を許しているのです。

Pull requestの粒度については以前、別の記事で触れましたが、コミットの粒度に関してはレビュー対象にはしていません。

コミットの粒度まで指摘してしまうと気軽に修正できなくなり、開発そのものを楽しむことが難しくなってしまうと考えているからです。

もちろん、試行錯誤のコミットが多すぎてgitのログに悪影響を及ぼすと判断したらrebaseなどで纏めることはありますが、基本的にローカル環境では自由に色々と試して欲しいと考えています。

その代わり、コミットメッセージには一定のルールを設けています。コミットメッセージのルールやprefixには Conventional Commit や Semantic Versioning などがあります。

例えば既存のAPIに対する機能追加があった場合のコミットメッセージは、

minor-feat: add hoge feature

のようになります。

コミットメッセージのprefixに悩むということは、1つのコミットの中でたくさんのことをやりすぎているということに気づくことができます。

このようにコミットメッセージにルールを設けることによって、自然に一定内のコミットの粒度を維持できるようになっています。そのため、コミットの治安が悪くなることはほとんどありません。

実装途中のコードであっても、次の条件の全てを満たす場合はマージを許容しています。

対応スコープ内の全てが完了してからマージするのではなく、Pull requestを細かく作成し、少しずつ作成、修正をしていくような流れです。

マージしてしまうとどうしても本番環境の振る舞いに影響が出てしまう場合は、Feature Flagを使ったりtopic branch運用を行うこともあります。

Feature Flagやtopic branch運用に関しては、↓の記事を参照してください。

対応予定の全てが完了するまでマージを止めてしまうと、base branchとの差分が大きくなりやすく、conflictや不具合が発生しやすくなり、ユーザーへの価値提供までのスピードが遅くなってしまいます。

本番環境で利用されないコードをマージしてしまうのは抵抗感があるかもしれませんが、本番環境の振る舞いに影響がないということは悪影響もないはずであり、ユーザーへの価値提供を最優先するためにこのような開発手法になっています。

本番環境への影響がないということについては、既存コードに対するテストコードによって守られているため、強気でマージ出来るようになっています。

いかがでしたでしょうか？

開発組織によっては「そんなことやっていいの？」と思われるかもしれませんが、弊社ではユーザーへの価値提供を最優先するために、このような開発手法になっています。

もちろん、しっかりとしたテストコード、CI/CD環境が整っているからこそ、このような開発手法が可能となっています。

他にも、このような開発手法を支えている開発テクニックを別記事にて紹介していますので、興味がある方は是非読んでみてください。

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers