Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Obj-CをSwiftにリプレースするお話

425 views

Published on

CyberZ スキルウェンズデー 6月14日発表資料

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Obj-CをSwiftにリプレースするお話

  1. 1. Obj-CをSwiftにリプレースするお話 2017/06/14 Skill Wednesday 齋藤 仁
  2. 2. 自己紹介 ・齋藤 仁(さいとう ひとし) ・株式会社CyberZ OPENREC事業部 ・iOSエンジニアだったりサーバーサイドエンジニアだったり ・ロードバイク乗りです
  3. 3. 絶賛Swiftへのリプレース中
  4. 4. Swift化のメリット ● ジェネリクスの活用することで柔軟で汎用的なコーディングが可能 ● optional型を活用することでnull安全なコーディングが可能 ● Objective-Cより処理パフォーマンスが向上 ● ヘッダーファイルがなくなったので、実装ファイルとヘッダーファイルを行き来する必 要がなくなった ● Objective-Cのいけていないメソッドの呼び出し方からの解放 ● ネームスペース ● 採用力の強化 ● などなど
  5. 5. 現在の構成 View ViewController Model
  6. 6. 現在の構成 カオス!! ViewControllerView Model Model Model View View Model Model Fat Controller!! Model Model View View View View View View Model
  7. 7. 実装面でのKPTを実施 「Problem」 ・null安全が保障されない実装であるため、 EXC_BAD_ACCESSが発生しやすい ・ReactiveCocoaとdelegateが混ざったりしていて、逆効果になっていることがある気がする ・ViewでModelの処理してる ・View周りの実装があらゆる箇所に入り込んでいる。 ・XCodeプロジェクト上のフォルダ構成と実フォルダ構成が合っていない ・xibファイルがないので、 uiの実装効率が悪い ・xib化した時にレビューの仕方どうする? ・アプリ全体の挙動に関わる状態を保っているクラスがどこにあるのか把握しづらい ・クラスに関するコメントがないから、何をしてくれる Managerなのかわからない ・コードでviewの実装をしているため、メンテが大変 ・コードでViewを生成するのはつらい ・コードの依存関係が複雑 ・コードコメントが少ないので、読みにくい ・サーバ側apiの仕様変更したとこらが、 wikiに反映遅い時もあります ・トップ画面とかの Controllerが親クラスを継承していて、処理の流れを追いにくい。 ・ユニットテストない ・ログイン・サインアップの各 controllerに共通のソースコード多い。 ・各Controllerがかなり肥大化している ・画像名やローカライズの key名を文字列でハードコーディングしているため、存在しないリソース名が出てきた時に気付きにくい ・自動再生と動画再生画面で共通で使えるように MoviePlayerクラスを定義しているが、肥大化しすぎて影響範囲が見切れずメンテしにくい。 自動再生だけに絞るとかなりソースコード少ないはず。
  8. 8. 実装面でのKPTを実施 「Try」 ・APIライブラリの使い方もう少し検討する余地ある ・BuildConfigurationの見直し ・Dataレイヤ、Domainレイヤのデータオブジェクトはそこそこ正規化する。 ・DIの導入 ・iOS9以降の対応にシフト。 ・signingの設定とか見直しする ・Swift lint入れる ・XCodeプロジェクト上のフォルダ構成と実フォルダ構成が合っていないのはツールで解決 ・Xib, ストーリーボード有効活用 ・xib化するか検討する。 ・コードフォーマッタの導入 ・タイプセーフリソース化 Swiftgen ・マクロとUtilityの使い分けを統一してもよさそう ・命名規則やコーディング規約の再認識 ・状態を伝えるのはドメインじゃないといけない ・継承していること自体が問題じゃない。ドメイン設計意識する。
  9. 9. 以下を実現できるアーキテクチャを選定 ・責務ごとにレイヤー化 ・ドメイン設計意識する ・依存の方向性を単一方向に揃える ・処理の流れは単方向にする ・DIによってユニットテストを導入しやすくする
  10. 10. Clean Architecture
  11. 11. Clean Architecture View ViewController Presenter UseCase Repository DataStore EntityTranslater Model Presentation Layer Domain Layer Data Layer
  12. 12. Clean Architectureのメリット ● 責務を細分化 ○ 各レイヤの役割が明確になる。 ○ MVCでは実装者の経験やレベルなどによって、実装するクラスの構成に差が 出るが、各レイヤーの役割を明確にしてアーキテクチャとして定めることで、 チーム内の共通認識も持ちやすい。 ○ データ・処理の流れを単方向に制限することを意識して実装しやすい。 ● UIとビジネスロジックを分離することでレイヤ間の依存を最小限に抑えるこ とができる。 ● レイヤ間を疎結合に保つことでモジュールの置き換えができ、テストが容易 となる。
  13. 13. 実装量が多くて面倒そう。。
  14. 14. MVVMを検討してみた View ViewController ModelViewModel
  15. 15. MVVM PresenterとUseCaseを追加 View ViewController ModelPresenter UseCase
  16. 16. MVVM Repositoryを追加 View ViewController Presenter UseCase Repository DataStore Model
  17. 17. あれ?どこかで見たような。。。
  18. 18. これClean Architectureじゃね?
  19. 19. その他対応 ● 現状、iOSとtvOSのソースコードは独立しているが、Domain Layer以下を共通化させる。 ● 各レイヤーはprotocolで抽象化してDIで依存性注入 ● ユニットテストの導入 ● CIツールの活用 ● RxSwiftの導入

×