iOS AntiPatterns & Refactoring
-
Upload
kazuhiro-sakamoto -
Category
Engineering
-
view
1.031 -
download
4
Transcript of iOS AntiPatterns & Refactoring
自己紹介
https://github.com/kazu0620
坂本 和大( @kazu0620 ) Sansan株式会社 Eight事業部所属
過去に個人で開発したアプリ - 秘密のアルバム(40万DL!) - にゃんこ(15万DL!)
Refactoring• Storyboadに移行する。慣れてみると
Storyboad+AutoLayoutの方が大体の場合楽でした。
• 経験上、動的に表示を変更するという要件でも、frameをゴリゴリ操作するよりも最小限のConstraintをIBOutletで接続して必要な制約だけ変更する方が楽。
• しかし明らかに割りに合わない時は、仕様上の大きな変更など、replaceできる機を待つのもアリ
• どうしてもコードの見通しが悪くなる(永遠と続く
case文やif分岐)
• 新しい振る舞いを追加するとき、変更が必要な箇所が散らばる
• 変更時にデグレが発生するリスクが高くなる。というか実際デグレる。
何が問題なのか?
何が問題なのか?
• 規模が小さいうちは良いが、Fatになるほどにメンテナンスや機能追加の難易度が上がる
• Modelが存在しない(or薄い)ので、状態の管理や監視の実装がどうしても複雑かつ見通しが悪くなってしまう(Model = NSDictionaryなど)
Refactoring
Modelを切り出す
• NSDictionaryで情報 / 状態を持つコードはメンテナンスがツラい
• Controllerからビジネスロジックを剥がすことが出来る
• 複数のViewControllerで共通のModelを利用できる
Refactoring
Viewを切り出す
• 割とシンプルなViewならStoryBoadでコード無しで作れる
• 必要なUIViewを継承したCustom Viewを作る
• 演出のためのアニメーション等複雑な処理をViewControllerから剥がすことが出来る
Refactoring
その他のリファクタリング
• TableViewやCollectionViewはDataSourceDeleagteを別クラスに切り分けできないか検討する
• チュートリアル / ガイダンスの状態管理などはそれのみを責務としたクラスなどに分けることを検討する
• 複数のModelに対して複雑なデータ操作をしている場合などは、Serviceクラスに切り分けできないか検討する
Refactoring
• それぞれの処理を、その責務を持ったクラスに委譲できないか検討する(Logging、APNSなど)
• NSNotificationCenterを利用し、ViewControllerでアプリのライフサイクルイベントを監視する
• 初期起動 -> 画面遷移を行うことを責務としたクラスを作る(Router,
Dispatcherクラス)
Refactoring• 通知元:通知先が1:1の関係の場合はDelegateを利用したほうがわかりやすい(Ex. ViewControllerとViewなど)
• しかし、離れてる場合は、Delegateがクラス間でリレーされてしまい、見通しが悪くなりがち
• 通知元:通知先が1:Manyの関係の場合はNotificationを利用したほうがわかりやすい(Ex. 複数のControllerにModelが状態変化を伝える時など)
• 放置すれば状況は必ず悪くなる
• 苦労して悪しきコードを理解したとしても、後任者はまたコードを解読するところから始めることに。
• とはいえ、程度問題。リスクなくリネームだけで解決するなら気づいたときに対応すべき。
何が問題なのか?
Copyright © Sansan, Inc. All rights reserved.
0
Sansanは一緒に新しい価値を作っていく 仲間をさがしています。
Ruby, Ruby on Rails (Webアプリケーション)
C#,ASP.NET MVC (Webアプリケーション)
iOS / Android アプリ
- 個人向け名刺管理アプリ「Eight」 - 名刺データ化分散処理システム
- 法人向け名刺管理サービス「Sansan」
- 法人向け名刺管理サービス「Sansan」
- 個人向け名刺管理アプリ「Eight」
エンジニア募集中
Sansan 採用 検索
[email protected] まで お気軽にご連絡ください。
興味のある方は