この記事は何？
Swift TweetsでTweet LTさせていただいたもののまとめになります。イベントのスポンサーとして Qiita に許可をいただいた上で、このような形（ツイートの引用）で投稿しています。
発表形式
Twitterのアンケート機能を使って話す内容を決めてみました。短い5分のLT時間で、できるだけニーズある話をしたかったという意図での試みでした。
【アンケートのお願い】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
いきなりですがクリーンアーキテクチャに関してLTします田中です。
参加者の皆さんが気になることのアンケートを取りたいです。
アンケートの結果に応じて話す内容を変えようと思ってます。
iOSにおけるCAに関して気になるところはどこですか？#swtws
クリーンアーキテクチャに対する意識調査にもなってよいアンケートだったなと個人的に思っています。
もともと3つ話を作っておいてありました。本番では得票数の多かった話その1の「そもそもCAってなに？」の内容をTweetしましたが、せっかく用意したのでその他も公開しちゃいます。
iOSにおけるクリーンアーキテクチャよもやま話
※ここで使っているCAという表記はClean Architectureの略になっています。
はじめに
🍺など飲みながらゆるく始めさせていただきます。
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
それでは聞いてください、
「iOSにおけるクリーンアーキテクチャよもやま話」#swtws pic.twitter.com/zdpSXKH3OW
【自己紹介】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
おばんです、クラスメソッドでiOSをやりながらブログを書いている田中賢治といいます。
アイコンの通り、一部では「ダンボールの人」と呼ばれています。
詳しくは👇https://t.co/1WAWbzjLuy#swtws pic.twitter.com/fMDSK4Aozy
【今日する話の説明】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
今回はアンケートを取った中の「そもそもCAってなに？」について話していきますが、みなさんの発表が終わり次第他の話も垂れ流します。Qiitaにもまとめますのでご安心を。（というか話したい）
100票以上集まりました、すごい。#swtws pic.twitter.com/PsAHNv2mc0
話その1: 「そもそもCAってなに？」
【元ネタ】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
元ネタと翻訳版は以下のリンク。https://t.co/vblzZQgx06https://t.co/DA6OM0Z57x
CA（=クリーンアーキテクチャ）に関してはいくつかの要件が元ネタに書いてあるけれど今回は省略。是非読んでみてください。#swtws
【iOSにおけるCA】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
僕がiOSでCAを採用するにあたって大いに参考にさせていただいているのが以下のリンク先です。むしろパクってます、ありがとうございます。
サンプルコードも載っているのでとてもわかりやすいです。https://t.co/RQv7olSnqP#swtws
この記事ね。#swtws pic.twitter.com/BLn2b14idB
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
【iOSにおけるCA】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
iOSにおけるCAはおおまかな説明をすると添付している画像の通りの層と役割ごとに分けた設計です。(前ツイートのリンク先よりお借りしてます)
役割ごとの説明は先述のリンク先で説明されています。#swtws pic.twitter.com/o11PAgZnA2
【iOSでCAを取り入れると良いこと】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
以下が挙げられます。
・役割を分けることでMV○系におけるModel部分の曖昧さが無くなるので、エンジニア同士の経験値の差を埋めてくれる
・処理とデータの流れが追いやすい
・疎結合な作りなのでテストしやすくなる#swtws
【iOSでCAを取り入れるとつらいこと】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
・導入コストが高い
・ファイル数・コード量が増える
複雑なアプリor開発期間の長いアプリでないとオーバーコストな設計なので採用には見極めが必要。後者に関しては僕の後の @yhirose741 さんから詳しく説明があるかも#swtws
【CA導入までの流れ】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
・CAは理解するのが難しい。一度簡単なアプリを「チームで」作ってみるとよい。
・いきなり案件導入するとチーム内で認識の齟齬が生まれてしまって苦労する。（体験談）
続きはWebで。https://t.co/nqkoBtyNM6#swtws
この記事ね。#swtws pic.twitter.com/4ZZSSkb2vD
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
【さいごに】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
以上、「そもそもCAってなに？」についてお話ししました。
今日の発表がみなさまのより良い開発の一助となれば幸いです。ごTweet聴ありがとうございました。(続く#swtws pic.twitter.com/1iVuqKaatX
発表後
この後のフリートークでは
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
・アンケートの中の取り上げなかったトピックの話（発表用に話は用意してある）
・CAと他のアーキテクチャの比較の話
・CAに則ったコードって実際どんな風に書くの？
などなんでもウェルカムです。気軽にお声がけください。#swtws
【宣伝・参考・関連】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
あと勉強会やってます、よろしく！！！📦https://t.co/tff3kvnJUghttps://t.co/RQv7olSnqPhttps://t.co/Ty9aw4hEvUhttps://t.co/nqkoBtyNM6#swtws
以上、温かみのある手Tweetでした！ありがとうございましたー#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
話その2: 「CAを採用するとなにが良いの？」
勝手にSwift Tweets 第二部
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
「CAを採用するとなにが良いの？」
#swtws
【CAを採用した際のメリット】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
以下が挙げられます。
1. MV○系アーキテクチャにおけるModelという曖昧な存在を細分化して明確にしてくれる
2. 処理とデータの流れが追いやすい
3. テストしやすい#swtws
【1. MV○系におけr(ry】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
設計の力はエンジニアによって差が出がちです。
それに対してCAは層と役割を細分化することによって明確な設計指標を提示することができます。
力量や好み関係なく統一した設計で開発を進めることができるのは大きなメリットです。#swtws
【2. 処理とデータの流れが追いやすい】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
CAは依存を単一方向に統一した作りになっているので、処理の流れが追いやすいです。
VC -> Presenter -> UseCase -> ... と処理は流れて、戻ってくるときは必ずその逆の順になる作りなので、#swtws pic.twitter.com/pPlD4cOAFE
【3. テストしやすい】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
役割 = 機能として細かく分割されて独立しているのでテストしやすい作りになっています。
この話に関しては前の発表の参考リンクのサンプルコードにも載っていますが、各役割はそれぞれインターフェースを作る実装となることもうまく作用します。#swtws
【CAを採用した際のデメリット】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
これについてはさきほどの「そもそもCAってなに？」で言った通り。#swtws
話その3: 「CAを採用すべき場面ってどういうとき？」
そして最後。
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
アンケートで「そもそもCAってなに？」という話と票が割れた
「CAを採用すべき場面ってどういうとき？」#swtws pic.twitter.com/598ILq8T6x
【CAを利用すべきシーン】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
以下が挙げられます。
・アプリの作りが複雑な場合
・アプリの開発期間が（大体）1年以上の規模の場合（メンテなど含む）
そのアプリの複雑さと開発規模で考えます。アーキテクチャ選定の具体的な線引きについては、今度ブログに書きます。#swtws
【CAを利用すべきでないシーン】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
利用すべきシーンに当てはまらない場合です。
なぜかといえば、CAは非常に大きな作りをした設計だからです。ファイル数・コード量がとても増えるため、CA以外の設計と比較した時に圧倒的にアプリを作るためにかかる工数が増えてしまうからです。#swtws
【CAを利用すべきでないシーン】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
どれくらいファイルが増えるかといえば添付の画像の役割分、インターフェースと実装をそれぞれ作る必要があります。作ったファイルにはそれぞれの実装が書かれますので、工数が増えるということがお分かり頂けると思います。#swtws pic.twitter.com/vPOWc8Wl6i
【CAを利用すべきでないシーン】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
添付画像はCAでログイン機能を作ってみた時のものです。
お気づきになられただろうか...、画面左端のファイルインスペクタに映る圧倒的ファイル数...。もう一度ご覧いただk（ry
ちょっと一機能作るだけでもこんだけ多くなる#swtws pic.twitter.com/ZfIZOj0AnF
【補足】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
あと一人開発の時にCAは要らない。個人開発で、CA実装の練習と思って作っているアプリがあるんですが、実装の重さと一人開発の寂しさで死ぬ。#swtws
【その他のアーキテクチャとの比較】
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日
これまで述べてきたようにCAの採用にはそれがコストに見合うかの見極めが肝心です。
他にもMVCやMVP、MVVMにVIPERなどありますが、僕の感覚は添付の画像の通りです。詳しくは省きますが気になる方は後ほどリプください。#swtws pic.twitter.com/AYO8S2Y01i
以上でっしたー。TweetできたのでQiitaにまとめまっす😗 #swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日