はじめに

CleanArchitecture と題していますが、感想メインであり、CleanArchitecture のノウハウは学べません。
導入してみたいなと思ってつまずいた点などをいくつか上げてみようと思います。
ただ書き殴っているだけです！

なんとなく雰囲気だけ使ってみる

3年ほど前、初めて任されたサービスのiOSアプリがあったのですが、私は神ViewControllerは悪だと聞いていたので、
別の神クラスを作っていました。当時はコードレビューとかも特になく、受け入れテストが通ればOK!と言った雰囲気だったので誰にも指摘されることなく・・・。

保守の担当は社内を転々としていたのですが、WebAPIのリプレイスに伴うアプリ改修の話が私の所属するチームに話が回ってきたので、
じゃあちょっと練習がてら、CleanArchitectureを参考にして書き換えられる部分を書き換えてみましょうという話になりました。

サンプルアプリのシンプルさに騙される

CleanArchitectureだけに言えることではないのですが、View、ロジック、データなどのレイヤーに明確に分けることによって
保守性を高めていると思うのですが、このまず、レイヤーに分けるというのがなかなかうまく行きませんでした。

QiitaやGithubなどでいろいろ参考にさせていただきましたが、
サンプルなので、そもそものアプリの使用が単純で、以下の点に躓きました。

サンプルはAPIから取得するデータと、ローカルに保存するDataの構造がほぼ同じ。
- 実際のプロダクトはそうとも限らない。
構造が違うデータの吸収をどのクラスで行うかがわからない。
- 構造が違うデータのエンティティは別に扱うべきなのか迷った。（あげく、混在した。）
UseCaseの使い方がわからなくて、既存の処理をそのまま書き写すだけになった。
- とはいえクラスが増えた分ファイルごとの行数は減ったので見通しは良くなった。

やはり自分たちのプロダクトに落としたときどうすべきかというのは、一朝一夕でわかるものではなく、
ビジネスの分析の段階からの着手と、試行錯誤が必要なんですね。

結局、この処理どこに書くの？になる

Push通知の制御など、OSの機能や、他のライブラリに依存した機能を書くとき、
どこに書けば良いのかわからなくなってしまいました。

今回は、 HogeHogeService というようなクラスを作り、機能毎にまとめてみましたが、
もしかしたらこれも、UseCaseとかで良かったのかもしれません。

Androidの処理内容との比較はしやすかった

仕様が少し変わったときや、要望が増えたときなどに、
AndroidとiOSの細かい実装をすりあわせるのに、設計アーキティクチャが統一されているというのはやりやすかったです。
私はAndroidの開発はあまりやらないのですが、Androidの実装を確認したいとき、
自分の追いたい処理がどのファイルを見ればいいかを把握するのにかかる時間は体感的に少なかったと思います。

Rxはできればあった方がやりやすそう

iOSを担当するメンバーの1人が、まだ開発に慣れておらず、またRx経験も無かったため、
足並みが揃わない方がリスクになると考え、iOSに関してはRxの導入はしないことになりました。

ただ、Rxが無いと、Delegate地獄や、Blocks地獄になってしまいうので、
ただでさえコード量が増えるのに、さらにコードを書く量が増えます。

Swiftの方が書きやすい

これも、Rxの件と似たような理由になりますが、
クラスが増えて、ヘッダも増えるので、書くコード量だけで言えば、Swiftに移行できるところをしながらやっていった方が
やりやすかったかもしれません。（そうした部分も多々ありました。）
おそらくモダンな書き方ができる言語のほうがいろいろと向いています。

Swiftが書きやすいというより、Objective-Cに向いていない設計をしていただけかもしれません。
Objective-C自体はちょっと変態的なところもありますが、素晴らしい言語です。

最後に

結果的に見れば、CleanArchitectureを導入できたかというと、おそらくそれはできていません。
しかし、一つのクラスにすべてのロジックが書かれていて、それが複雑に絡み合っている。
というよくありがちな問題自体は解決したように思います。

また、何か新しいやり方やってみよう！ということでメンバーの士気も上がっていたと思うので、
そういった結果を考えれば、やってみたこと自体は悪くなかったと思っています。

次はもっとうまくやれるはず。