スピードと品質を保ちつつスケールをする開発プラクティス

11月に正社員として入社した sekky0905 です!

入社して感じたのは、Appifyはスピードと品質を保ちつつスケールをする開発プラクティスを非常に大切にしているということです。入社してからの1ヶ月半程の間にこのプラクティスが非常に有効なものだと感じることが多く、自分も常にこのプラクティスを念頭に開発をしています。

今回は、その開発プラクティスの背景となる考え方(と自分が考えていること)と開発プラクティスの一部を紹介します。

開発プラクティスの背景となる考え方(と自分が考えていること)

スピードを保ちつつ、スケールするためには以下の2つのことが大切だと思います。

  1. その人にしかできないことをなくすこと。一言で言えば 属人性の排除
  2. 本質的なことに集中することができること

1を満たすためには、には自分達が生み出すあらゆる知識や成果物に対して 自分だけが知っていることをなくす他のメンバーが見てすぐ理解できる誰がやっても同じようにできる という考え方が非常に重要だと思います。

2.に関しては、本質的なこと以外のところはなるべく自動化されている、もしくは標準化されていて考える必要がないということが非常に重要だと考えています。

Appifyではこの観点から確立されたプラクティスが充実しています。

開発プラクティス

統一感のあるコード

これについては、他のメンバーがアドベントカレンダーで記載する予定なので詳細には書きませんが、(書かれたらURLを貼ります。)Appifyにはサーバーサイドにも、フロントエンドにも明確な設計方針が存在します。そして、それがドキュメント化されています。 コードはその設計方針に従って記述されているため、初めてAppifyのコードを見た時から「どこに何が書かれていて、自分がどこにコードを書けば良いのか」と迷うことは少なかったです。(自分の実力不足によって、もっとこう書いた方が良いよねとレビューで指摘されることはありましたが)

設計方針が明確にドキュメント化されており、コードもそれに則ったものになっているため、自分が機能を実装するときには、機能そのものの開発に集中することができ、本質的にではない部分で迷うことがないようになっています。

ドキュメントの充実

Appifyの開発ではドキュメントが非常に充実しています。開発環境の構築からデプロイ手順、設計方針等に至るまでドキュメント化されています。

誰かがこれまでチームとしてやったことのない業務を行い、それを他のメンバーが後で行う可能性がある場合には、初めてその業務を行ったメンバーは必ずドキュメント化するようにしています。これにより、初めてその業務を行うメンバーが他の人に確認しなくても最初からスムーズにその作業を実施できるようになっています。

コードを書く際にも、上述した通り、設計方針がドキュメント化されているため、初めて実装する人でもすんなり実装を始めることができるようになっていますし、コード設計方針で毎回揉めるようなことはあまりありません。(よりこうすると良いよねというような前向きな議論はありますが)

セルフレビューシート

これは自分が入社した後に導入されたものですが、Pull Request Templateを使用して実装者が他のメンバーにレビューを依頼する前に自身でレビューをする際に確認するべき項目がチェックリストになっています。実装者はこのチェックリストを確認しながら、自身のコードレビューしていき、コードが確認するべき項目を満たしている場合にはチェックをつけて行きます。全ての項目にチェックをするまで、他のメンバーにレビューを依頼することはできません。

何かチームで気をつけた方が良いと思うことがあれば、メンバーはその項目を追加することができます。

このセルフレビューシートは以下の3つの点で非常に強力です。

  • コードを書く上で気をつけるべきことがリスト化されているので、予めミスを防ぐことができる
  • メンバーが気がついたことがあれば、随時アップデートしているので、各メンバーの知見をチームの標準として残すことができる
  • 他のメンバーにレビューを依頼する前に自分のリストを見ながら入念に確認していくため、レビューを依頼された他のメンバーに負担がかかりにくい

コメントへのこだわり

Appifyの開発では、コードと同じくらいコメントについても重要視しています。特に「なぜこのようなコードになっているのか」ということについて、背景知識のないメンバーであっても読んで理解できる水準でコメントを書く必要があります。これにより、新しく参加したメンバーがコードリーディングをしたけど、理解できず、結局他のメンバーに確認しないといけないということを極力無くしています。

E2Eテストの充実

これは既に他のメンバーの記事でも紹介されていますが、Appifyでは機能を追加した場合には、基本的に全てのAPIのユースケースについてE2Eテストをコードで実装しています。よっぽど緊急的な対応である場合や、技術的にその時点ではどうしてもE2Eのテストを実装できない場合以外は、どんなに急いでいる場合であっても、E2Eテストを実装しています。

APIのE2Eテストの実装自体には時間がかかりますが、以下のようなメリットがあり、中長期的に考えると非常に効率的な開発を行うことができます。

  • バックエンドの実装は、APIのE2Eテストを実装してそれが全部Passしていれば、正常に動くものとし、フロントエンドとの結合試験を待たずに次のタスクに進めることができます
  • コードの変更を行った際にはリグレッションテスト等を行う必要がない
    • ユニットテストだけだと、ユースケース全体に異常が発生していないかを確認することは難しい
  • E2Eテストのコードを見れば、APIの振る舞いやユースケースを確認することができるので、既存のコードを把握しやすい

会社全体のアドベントカレンダーはこちら!