静的コード解析とUnit Testを活用し、コードの品質を保つ
今入氏がまず解説したのは、コードの品質を保つための施策だ。JapanTaxiでは、静的コード解析ツールとしてSwiftLintを導入している。かつ、特定行のLintを除外する「//swiftlint:disable」の設定は、極力用いないようにしているという。
「かつてJapanTaxiでは、Lintを通すために『//swiftlint:disable』が乱用されてしまい、コード解析の利点をうまく活用できていなかった時期がありました。その状態を改善するため、あるタイミングでルールをいったん全て有効にし、無効にしてよいルールを厳選しました。どうしても『//swiftlint:disable』を使わなければいけない場合には、理由をコメントで明記しています」
コードの品質を保つために、Unit Testを書くことも徹底している。Unit Testには、既存のビジネスロジックが壊れないように保証するという意味合いはもちろん、単体テストのレベルで防げるバグを早めの段階でつぶし、QAテストでの手戻りを防ぐという目的もある。
「Unit Testを書く心理的な障壁を下げるため、ボイラープレート的な記述はXcodeのテンプレートを活用して効率的に書けるようにしています。また、テストに使うモックもコマンドで自動生成できる仕組みを入れています。DIを導入するなど、Unit Testを書き続けられるような状態を維持していくことも、コードの品質を保つ上では重要です」
コミュニケーション活性化と徹底した自動化が、複数人開発の要
効率よく複数人開発するための施策についても、今入氏は解説する。
まずはコードレビューにおける工夫だ。同社のレビューにおいては、実装の誤りや改善方法について指摘するだけではなく、良い実装があった場合には「いいね」をつける習慣も大切にしている。今後のリファクタリングの予定などについても気軽にコメントし合い、「コードを通じたコミュニケーションの場」としてコードレビューを活用している。
Pull Requestを発行する際にも、いくつかの趣向がある。Description上で、対応した内容はもちろん、対応していないこと（対応すべき範囲を超えているもの、別のPull Requestで対応するもの）や実装における懸念、スクリーンショットによる修正差分などを提示し、レビュイー・レビュアー間のコミュニケーションの円滑化を図っているのだ。
また、Pull Requestが長時間放置されないようにPull Pandaを活用している。例えば、Pull Asignerを用いてのレビュアーの自動アサインや、Pull Analyticsによる24時間以内にレビューがされたかどうかの確認、Pull Remindersによるリマインドなどを実施しているのだ。
レビュアーの負担軽減のため、機械的にチェックできる部分についてはBotに任せている。SwiftLintの警告を自動的にコメントしたり、未使用のメソッドやプロパティ、クラスなどを解析してDangerによって警告を出せる仕組みを構築したりと、いくつもの工夫を行っているそうだ。
「さらに、複数人開発で全メンバーに共通して必要になるような開発環境の構築やUnit Testのモック生成、GraphQLのスキーマの更新、API.swiftの生成などは、スクリプトを作成してコマンド化しています。また、Bitriseのワークフローを作成し、さまざまな作業を自動化しています。こうした施策によって、作業環境の共通化や作業の省力化を行っているのです」
