- 書き方が曖昧で合意が取れてないから
- 難しい割にメリットが薄いから
- 外部知識を入れるデメリットが大きいから
- 可読性が落ちるから
- 書けないiOSエンジニアが多く、学習コストも大きいから
- プロジェクトの進みが遅くなるから
- リードするチームが場当たり的チームだから
私のスタンスは、例えばCOBOLかJavaかというシーンで、市場にCOBOLエンジニアが多いならCOBOLを採用するし、時代がJavaに切り替わってるならJavaを採用するみたいな感じです。
Swiftなんかはバージョン4.1あたりでObjective-Cから完全移行しました。2.3では早かったですね（2.3から触ってました）
以下詳細。
書き方が曖昧で合意が取れていない問題
「◯◯は良いものだ」
「◯◯は難しくてよくわからない」
この2つの意見が並んでいる時、私は非常に警戒します。
現代のソフトウェア開発はチーム戦ですから、書き方にある程度の合意が取れているか、他人が書いたコードの意図を読み取れなければなりません。
なのでこのような難しく曖昧な方法を採用する際にはチーム内で合意が取れていなければなりませんが、それができるチームとできないチームがあります。
できないチームでは採用するべきではありません。
難しい割にメリットが薄いから
これは経験則なのですが、未採用プロジェクトと採用プロジェクトのどちらでより大変なことになっているか比較した場合、採用したプロジェクトのほうがより多くの問題を抱えていることが多いです。
一体なんの問題がまずあって採用したのかいつも不明です。
一つあるのは自動テスト可能化ですが、自動テストがプラスに働いているプロジェクトがまずわずかです。多くのプロジェクトでは不要な自動テストをたくさん書いています。
敢えて指摘しませんけど。
外部知識を入れるデメリットが大きいから
例えばライブラリーを導入する場合にはライブラリーについて勉強が必要です。
新しい概念を用いるときにはそれについて多くの勉強が必要になります。例えばそのデザインパターンがWeb由来のものであれば、Webにおいて発生した諸問題という前提について理解しておく必要があります。
それらをプロジェクトメンバーに強いるというのは非常に重いし現実的ではないプロジェクトのほうが多いのです。
可読性が落ちるから
よくFatなControllerを避けて可読性をあげるみたいな話がありますが、登場するclassなどのコンポーネントは何倍にも増え、コードの総量は明らかに増えます。
増えた結果、依存関係が曖昧になり、スコープが曖昧になるのでどこまでコードを読めばいいかが非常に難しくなります。
書けないiOSエンジニアが多く、学習コストも大きいから
自慢じゃないですが、ここ5年で10案件以上やってきましたし、面接は100件以上やってます。面接官も20件以上していますし、接してきたiOSエンジニアは結構多いと思っています。
その上で、書けるエンジニアは半分以下だし、ちゃんと書けるエンジニアは2割くらいなんじゃないかと思います。地頭で言えば大学偏差値65以上くらい。
「じゃあうちはお金があるからその優秀な2割だけ雇うよ」みたいな会社もあるんですが、エンジニアの絶対数が少ないのでそれが成立していません。また、やはり熟練者だけで見ても書き方の合意が取れていません。
プロジェクトの進みが遅くなるから
エンジニアという生き物は不思議なことに品質やコードの設計は意識するのに開発スピードには無頓着です。これは長引いた方がエンジニア的には儲かるという昨今のビジネス上の構造問題だと思うのですが、デザインパターンを導入したことによって10年以上のベテランがよってたかって改修しても全然進まないみたいなプロジェクトが散見されます。
敢えて指摘しませんけど。
そういうプロジェクトでは大抵デザインパターンを導入したエンジニアは既に退職していて、かつ今のデザインパターンをやめましょうという人間は一人も出ません。
リードするチームが場当たり的チームだから
特にフリーランスが中心のチームでは、誰がコードを触るかがわかりません。
業界内では未だに「新規開発は優秀なチームでやり、保守はもっと安い人材にやらせる」という風潮があります。（これは現代のモバイル開発では明らかに間違いです。継続開発のほうが難易度が高い）
そのため新規開発の時の優秀なリーダーが最新の難しい設計を試して挙げ句居なくなるというケースが起きます。彼にとっては良いでしょうがプロジェクトにとっては最悪でしょう。
ベンチャーなどでは、1人の社員リーダーだけはそのプロジェクトの面倒を見切るというケースも多く見られますが、その場合でも難しいデザインパターンを採用してしまってエンジニアが見つからずプロジェクトが遅延したり、高い報酬を支払うみたいなケースをよく見ます（そんなプロジェクトの話ばかり来る）
もちろん潤沢な資金と優秀な開発メンバーを社員で抱えているような企業では自由にデザインパターンを選択すればいいと思いますが、ほとんどの人はそうではないはずです。（そのような会社の人がフリーになって上記のような流れができるんですけどね）
その他、採用してないやつ
RxSwfit
async/await
SwiftUI
私としては早く採用できる段階に来てほしいんですけどね。
すなわち、エンジニア市場的にできる人が半分以上で、書き方の合意がある程度取れている状態です。
「秘伝の方法」みたいな一部の人しか理解できないものは要らないのです。
難しいなと感じた時点でアウトです。
じゃあどのような書き方をするのか
デザインパターンのような総論じゃなくて各論でいいと思います。
実際私が長年「こんな書き方がよさそうだなー」と思って書いてるのはCleanArchitectureに似ています。でも100%CleanArchitectureではありません。新しい概念を用いず、小さいスコープでどうするべきか議論していく、でいいと思います。
総論でなければ書き方の強制にはなりませんから、とりあえずスピードは落ちないでしょう？
個人的に思うMVVMの問題点
正直詳しくないんですが、まずMVVMってデータバインディングありきじゃないですか、その時点でRxSwift導入必須みたいな話になるんですよ。重い。
Androidでは採用されていますが、Androidはデータバインディングが標準装備なので前提が違います。
しかもAndroidのMVVMはMVVMじゃないとか言い出す人も居るので内ゲバもあるんですよ、怖い。
あと元々Windows Presentation Foundationでできた概念なのに、私がそのWPFについて詳しくないから、どういう問題があってMVVMが誕生したのかの文脈が追えないというのもあります。
の割に設計方法が明確というわけでもなく。
じゃあ皆何のために導入してるのか探ってみると、どうやらテスト可能化のためっぽいんですけど、自動テストをしたいっていうよりTDDをしたいっていうタイプらしいんですよね。そして私はTDD懐疑派なので、じゃあ採用する理由無いじゃんというわけです。
個人的に思うRxSwiftの問題点
あれは結局「書き方を変える」とう話なんだと思います。
「それ、C#でも書けるよ」みたいな話です。
個人的に思うCleanArchitectureの問題点
一番問題なのは、提唱者の本のレビューに結構否定意見が多いことです。
この時点で書き方のコンセンサス取れるわけないじゃないですか。
他のデザインパターンよりもふわっとしてますしね。
私は最初は思想だと思ったので良いなと思ったんですが、気づけはお作法みたいに捉えてる人が多かったのでなんか違うなとなりました。
結論
Apple様の言うとおりにする。
CombineはRxSwiftと同質なんですけど、SwiftUIを使うなら必須らしいのでいずれ皆やることになるでしょう。なるんですかね？
