林です。
アプリの開発を続けていると、今の自分を苦しめるのは、過去の自分が書いた当時の「最高の実装」だということに気がつきます。なんでこんなところを複雑に書いてしまったのだという後悔。
未来は予測できないという原則を忘れて、かえって問題を複雑にしてしまうのは、人間の性なのでしょうか。
かんたんな実装は本質的なので、変化に強く、品質も担保しやすい。
分かってはいるけど、かんたんに作るのは難しく、かんたんを保つのはさらに難しい。
iOSアプリをかんたんに作るにはどうすれば良いのでしょう？
壊しやすく、作り直しやすく
**未来は予測できず、問題は起こるまで分からない。**となれば、壊しやすく変更しやすく設計するのが筋というものです。
アプリの大半はViewで、A/Bテストもあれば、要件もよく変わります。
画面はStoryboardとAutoLayoutで、サクッと作ってサクッと捨てるくらいがちょうど良い。
BaseViewControllerや高機能なライブラリ・実装は、深く依存してしまって捨てにくいのでやめましょう。
スタイルガイド・UIコンポーネントは作り込む
スタイルガイド・UIコンポーネントはアプリのアイデンティティです。
ここをStoryboard/AutoLayoutと連携しやすいように作り込むことで、アプリの一貫性を保ったままで画面のスクラップ＆ビルドが捗ります。
WWDCのセッションと、Appleの公式ドキュメントを読みましょう。
UIKitをしっかり把握すると、UIコンポーネントの実装はそれほど難しくありません。
UI系のライブラリを使うのはあまりおすすめできません。
Easy < Simple
可読性のためと思って作ったEasyな実装が、問題の原因になることがよくあります。
- 本来不要なプロトコル
- 普通の関数で良いのに
ExtensionやComputed property - プロトコルとジェネリクスが組み合わさった、Swiftyな何か
見た目をよくするために作った実装が、かえって見通しを下げることにつながります。
あるいは、自分が技術をよく理解できないために導入したEasyなWrapperライブラリ。
ある時、問題が起きてデバッグし、内部実装を読んで挙動を理解した頃には、そんなライブラリなんか必要ないことに気がつきます。
結局のところ、ソフトウェア全体の複雑度を下げること(=Simple)が一番Easyだったりします。
凝りすぎない
正しい方向に力を入れることができれば、その実装はアプリの強みになることでしょう。
一方で、間違った方向に凝ってしまった実装は、その後長い間チームを悩ませることになります。
未来は予測できないという原則に立ち返ると、開発初期に頑張ってしまった実装は、つまり長い間チームを悩ませる頭痛の種となることになります。
先回りせず、問題が起きた時に最小限の解決方法で対処するのが、プロジェクトをかんたんに保つコツです。
たいていの場合、MVCで十分
ある程度の複雑度まではMVCでも十分に品質を保てます。
iOS SDKはMVCを前提に作られていて、アプリ開発の初期に適切な別のアーキテクチャを選択し、正しく実装するのは難しいものです。
エンジニアにとっては残念なことに、大抵のアプリはユーザーに使われずに消えていきます。
アーキテクチャではなくユーザーの方を見ましょう。
アプリが商業的にも成功すれば、規模も大きくなり、チームのメンバーも増えて、アーキテクチャについて考える余裕もできます。
データの流れは一方向に
データが複雑に絡み合うと、人間には予想もつかない挙動になってしまいます。
データの流れを一方向に保つことは、変更に強く、処理を追いやすい実装に繋がります。
例えば、ViewがViewに依存する処理は、ありがちですが思わぬ不具合の温床になります。
button.isEnabled = uiSwitch.isOn
突き詰めてデータの流れの各ステップに名前をつけると「アーキテクチャ」と呼ばれるものになるのですが、問題は起きるまで解決しないのが信条ですから、まずはデータの流れを一方向に保つという原則だけを徹底するくらいが良いのではないでしょうか。