はじめに
最近は少々堅牢なシステム設計への意識が高まっているので、iOSアプリに関してもそのあたりの知識を習得しておきたいという意味で読みました。
そのあたりの考え方については、ケースバイケースだと思っていますが、自分の書くコードやシステム設計について根拠を示せない現状に半年ほど前ぐらいから不安に感じていました。
そこで、クリーンコードの考え方であったり、デザインパターンやアーキテクチャへ意識が向くようになった次第です。
第1部
- 設計の必要性など
- アプリでできることが増えた。それだけバグを生みそうな箇所も必然的に増える。
- 継続的にリリースしてくためには、テストによって品質を担保していくのが楽ですよね。
- 関心の分離: 単純の問題を単純な問題群として切り分けること
- チームで分業していくにも大事な概念
- AppleもUIKitのように様々なフレームワークに分離して提供している
- 「設計パターン」: 再現性のある問題に対する共通の解決策
- GoFのデザインパターンが有名
- 設計パターンを知るメリット
- 「これはXXパターン」といえば誰もが構造をイメージできるので、生産性の向上
- レイヤーに切り分けるためのアーキテクチャ
- 責務
- モジュール内にまとまっていて、疎結合であることが適切な状態
- AppleのUIViewControllerの役割定義がある
- 正しい命名をしましょう
- アジャイル開発について
- 設計の原則
- SOLID原則が有名
- 使いすぎると不必要な複雑さが伴ってしまう(オーバーエンジニアリング)
- 変更に対応するためのリファクタリングは破壊ではない
- 2つのアーキテクチャ
- GUIアーキテクチャ
- MVC, Presentation Model, MVVMなど様々なアーキテクチャの役割や課題の説明
- システムアーキテクチャ
- レイヤードアーキテクチャ、ヘキサゴンアーキテクチャなど
- GUIアーキテクチャ
- iOSアプリでの画面遷移のパターン
- Coodinator と MVVM-C
- Router と VIPER
- Micro View Controller
過去に小さな機能追加の場合、要件実現のための最低限差分(最低行数)を目指すことが最善だと思っていた時期がありました。
追加によって今までの命名がわかりにくくなった箇所も修正するなど、自信を持ってリファクタリングする理由がなんとなく示しやすくなりました。
最近「小手先のレシピを知るだけでなく、言語やフレームワークの思想ももっと知った方がいいですよ」と言いたくなることが増えましたが、どう書くべきか考えるのが少し楽になるので良いですね。
悪い例なコードをベースに改善していく方法が書かれています。
少し胸が痛くなりますが、オプショナルな変数を何個か持たせて、各関数内で処理を一部切り替えているようなクラスは、分割させた方が良いみたいな改善例とか書かれています。
どのシステムアーキテクチャもテスト容易性や、UIや外部サービス部分からいかに切り離すかという目的は同じ。
システムアーキテクチャの辺りを読めば、このアーキテクチャではここまでできるけどこんな課題があって、次のこのアーキテクチャでそこを解決できてみたいな感じで書かれているので、作りたいシステムに応じてここまでは必要ないかなとか思いながら選定できそうな感じでした。
結局、ドメインロジックを中心に置き、内向きの依存を守るのを意識して、レイヤー分割数を適切に判断する部分を考えれば良いらしい。
第2部
- MVCやMVVM、Flux、Clean Architectureのパターンの説明
- システムを分割するレイヤーの捉え方の違い
- 選定基準の話
原初MVCとCocoa MVCの違いは、ViewがModelへの関心を持つかどうかの違いで、Cocoa MVCでは、ControllerがModelの変更を監視して、Viewを操作するので、イメージしているMVCはこっちだった。
MVPは、テスト容易性や分業性の向上のためにMVCからさらに責務の細分化するものとして出てきた感じ。いくつかパターンがあるが「Passive View」が良さげ。Presenterには純粋なロジックが書かれるので実際のViewが無くても、テストができるようになる。
MVVMは、ViewとViewModelをデータバインディングで関連づけるのが特徴。関数型リアクティブプログラミングと相性がいい。
Viewの更新をViewModelとのデータバインディングで実現することで、両者の疎結合が実現することで、可読性とテスト容易性の向上ができるのが利点。
FluxやReduxは、最近Reactに触っていて結構関心があったデータフローが単一方向である考え方。流れが推測しやすく、役割が明確に分かれているので実装すべき場所がわかりやすいなど。
MVCなどがUIとViewを分離することに着目したものであるのに対し、Clean Architectureはアプリケーション全体のアーキテクチャで、厳密に階層的な依存関係になっていている。部分的に大きなな修正が他の層に影響しにくいことやテスト容易性による恩恵は結構ある。
第3部
ここからはFluxとReduxの導入例なので、そのあたり導入しようってなったらじっくり読みます。
