今年の8月に入社したshimgoです。主にバックエンドを担当しています。 この記事では、私が入社して感じた、開発組織に根付いている文化やプラクティスで良いと思った点を3つご紹介しようと思います。 自分がバックエンドを担当することが多いのでバックエンド側の視点寄りになっています。
1. シナリオテストが充実している
ジョインしてまず驚いたのはテストがかなり充実していることです。 サーバ側のテストではシナリオテストがかなり重点的に書かれています。 単体テストは、複雑なロジックを持つ関数や構造体に限り書かれています。 シナリオテストでは、実際のユースケースに沿ってAPIを実行していって正しく動くことを確認しているため、Web画面やモバイルアプリとのつなぎこみで問題が起こることがかなり少ないように感じます。 また、実際のユースケースではどんな流れでAPIが実行されるかを理解するためのドキュメントとしても役立ちます。 シナリオテストは下記のようなイメージになります。実装した機能はすべて実際のユースケースに沿ってテストがされるようにこのシナリオの中に組み込まれていきます。
// 管理画面: Appifyのインストール
...
// 管理画面: モバイルアプリの設定
...
// モバイルアプリ: サインアップ
...
// モバイルアプリ: クーポン一覧取得
...
// サーバ: Shopifyからの注文Webhookを再現
...
// 管理画面: モバイルアプリ会員にポイント付与を確認
...テストを通すのが少し大変なときもありますが、かなり安心感がありますし、後述するリファクタリングへの着手のしやすさにも貢献していると思います。
2. リファクタリングを頻繁に行っている
リファクタリングの規模は大小ありますが、小さな規模のリファクタリングであれば機能開発の中でその機能に関わる部分の改善を入れたり、リリース日が動かせない機能であればリリース後にすぐ実施したりと、コード改善の意識がチーム全体に浸透しているように感じます。 自分が機能開発をしている間に、masterブランチに次々とリファクタリングが取り込まれて自分の機能ブランチに取り込んで追いつくのが大変だと感じることすらありました笑 これだけ積極的にコードの改善に着手できるのも、シナリオテストが充実しているおかげだと思います。
3. 冪等性を担保することへの意識が高い
これは私の反省でもありますが、ジョインしてから冪等性を担保するための設計を議論する場をよく目にしたことで、今まで自分が冪等性を担保することへの意識が少し低かったなと感じました。 個人的には、ID生成にも可能な限り冪等性を持たせるようにする設計方針に関心しました。 例えば、1ユーザにつき1レコードしか存在しないデータの場合、あるユーザに対してそのレコードを作ろうとするとき、作成処理が何度実行されようとそのレコードのIDは同一であるため、DB側で重複登録を防ぐことができます。 そのほか、バッチ処理が何らかのエラーで止まってしまっても、冪等であれば何度実行しても同じ結果になるためエラーが解消すればバッチを再実行するだけでよく、リカバリー作業が複雑にならなくて済みます。 こうした冪等性担保の重要性をチーム全体で意識できていることはとても良いと思います。
おわりに
書き終えてみると、目新しいものはなく、どれもよく目にする基礎的なものだなと思いましたが、その基礎的なことがちゃんとできていると言えることは、健全な開発組織に必要な要素であると思います。 私もこうした文化を維持・発展に貢献していけるようこれからも頑張っていこうと思います！