iOSチームではリファレンスリポジトリを運用しています - ドワンゴ教育サービス開発者ブログ

こんにちは。N予備校iOSアプリ開発チームです。今日はリファレンスリポジトリをご紹介します。

皆さんはチームの新メンバーをどうやって開発にアサインしてもらっていますか？この悩み、一度は悩まれたことがあるのではないでしょうか。そこで我がチームで登場するのはリファレンスリポジトリです。

f:id:jote:20210901103159p:plain

どんなリポジトリかご説明しますと、字のごとくリファレンス実装が詰まったリポジトリになります。コード規約、設計手法、ディレクトリ構成などを把握できるよう、メインのリポジトリを模して1,2画面ほどの小さなアプリを実装した簡潔なリポジトリとなっています。新メンバーはチュートリアルとなる課題を与えられ、先ずはこのリポジトリで開発します。他にも大活躍しているリポジトリで今日はこの魅力をお伝えします。

何が良いの？

たくさん良いところがあるリファレンスリポジトリですが、まとめるとこの1点につきます。

具体的で解りやすいリファレンス

この効果はとても大きく、たくさんのメリットを生み出してくれます。では、どんな効果があり、どんなメリットが生まれたのか活用例をご紹介していきましょう。

例えばこんな使い方ケース1:新メンバー編

このチームにアサインした際、与えられた課題は「リファレンスリポジトリにXcodeGenを導入する」でした。ここではXcodeGenについての説明は割愛します。詳しくはGitHub:XcodeGenをご覧ください。
さて、実際のプロダクトコードのあるメインリポジトリでは既にXcodeGenが導入されており、リファレンスリポジトリにも導入する需要がありました。シンプルなアプリですが、きちんと要点が押さえてありXcodeGenを導入する時ならではの悩みや苦労を抱えました。例えばproject.ymlを書き起こす作業で、先ずジェネレーターを探しました。ジェネレーターを見つけると次は指定通りの設定になっているかXcodeのScheme、TARGET、Build Settingsの設定を確認しました。
project.ymlとXcodeの設定をにらめっこしている内に、ふと、作業がとてもしやすいことに気づきました。古い情報や歴史的経緯などによるノイズがなく、目的のものをすぐに見つけられているのです。これは何故設定されているのか、やりたいことは何か、考えることなく意図をくみ取ることができました。
導入を終えてみると、ノイズに振り回されることなく作業ができました。一番悩んだことはインデントが足りずYAMLフォーマットを間違えており、テストが意図した設定にならなかったことです。思い返すと笑ってしまうと同時にリファレンスリポジトリだからこそ、純粋にXcodeGenを導入する悩みが大きな印象に残ったのでしょう。リファレンスリポジトリでの作業はシンプルかつ要点が押さえられていて、とても良かったです。

例えばこんな使い方ケース2:アーキテクチャ編

プロダクトコードが数年経つと設計手法が変わってくることがあるでしょう。例えばMVCで当時は作っていたが新規で実装された部分はMVVMで開発している、といったような状況です。その場合、途中参加のメンバーはどこが新旧の書き方なのか自分で判断することになります。
こんな時にもリファレンスリポジトリが活躍してくれます。今の設計方法やフレームワークなどの書き方をリファレンスリポジトリに書いておけば良いリファレンスになります。新しい書き方の場所を探す必要はありません。しかもシンプルなアプリなのでコードは簡潔に書かれ読みやすいものになっています。ざっと一読みして実装の感覚が掴めるようになるのも、とても良いところです。コード規約より具体的な方針が示され解りやすくなっているのも外せない良い点です。
このようにリファレンス実装のリポジトリを作っておくとプロダクトの指標になります。迷ったらリファレンスリポジトリを参考にしましょう！

下記は実際のリファレンスリポジトリの一部です。Kickstarterを参考にしたアーキテクチャを採用していることがわかります。

--- 省略 ---

protocol HomeViewModelType: AnyObject {
    var inputs: HomeViewModelInputs { get }
    var outputs: HomeViewModelOutputs { get }
}

final class HomeViewModel: HomeViewModelType, HomeViewModelInputs, HomeViewModelOutputs {

    // MARK: - Properties
    var inputs: HomeViewModelInputs { self }
    var outputs: HomeViewModelOutputs { self }

--- 省略 ---

例えばこんな使い方ケース3:レビュー編

大切だけれど悩みが多いレビュー。リファレンスリポジトリができたのは、実はレビューの悩みが発端だったそうです。新しいメンバーが古いアーキテクチャでコードを書いてしまった際、「ここの書き方はこのプロダクトではこうだから書き直して。」と指摘する場面はよくあるでしょう。言う方、言われる方の両者共にちょっと辛いところですよね。せっかく書いたものを書き直してもらうのは忍びない、なんとか減らせないものか。考えた先輩方はリファレンスを実装することで解決しました。これがリファレンスリポジトリです。レビュアーはリファレンスと違う点があることを指摘するだけですみ、レビュイーはリファレンスを見直すだけで理解が得られます。かなり気楽なやりとりになり精神的負荷が少なくなったのではないでしょうか。そして新しいアーキテクチャについての教育コストも大幅に削減されています。実際に「リファレンスリポジトリを参考にして」となるケースが多々あります。ですが、特に不便さを感じたことはありません。リファレンスリポジトリの良いところです。

例えばこんな使い方ケース4:新しいアーキテクチャ編

今までご紹介した例ではリファレンスとして大活躍したリファレンスリポジトリですが、新しい事を試す場にもなります。Actionというライブラリを導入する際、このリファレンスリポジトリでローディング画面を試作してみました。これが思いのほか使いやすくメインリポジトリでも使うことになりました。
今後の課題は「SwiftUIをどう組み込むか」がホットなトピックです。リファレンスリポジトリで試し、組み込み方法を相談したりメリット、デメリットや注意点を共有する事になるでしょう。リファレンスリポジトリはプロダクトコードを簡潔に模したものなので、実際の取り入れ方を想定しやすいはずです。かなり具体的な問題点が見えてくるのではと思っています。新しい事を試すハードルをかなり低くしてくれるので、とても良いですね。

まとめ

ここまでたくさんのリファレンスリポジトリの活用例を書かせていただきました。冒頭でも書いたようにたくさんの良いところがあり、一言でまとめると

具体的で解りやすいリファレンス

となっています。

私達のチームでは具体的なリファレンスにより解決できた事がとても多くありました。プロダクト独特の文化やコードの書き方の作法がリファレンスリポジトリを読むだけで理解できるのはとても大きなメリットです。教育コストもかなり削減できています。方針が示されているのでレビューもしやすいです。そして、プロダクトコードとは切り離されているので大胆な挑戦をするハードルが低くなっています。良いことづくしですね。運用するコストはありますが、このリポジトリはなかなか手放し難いものになっています。つまり

リファレンスリポジトリすごく良いですよ。