Home
Explore
Submit Search
Upload
Login
Signup
Advertisement
さらに上を目指すための iOS アプリ設計
Report
Taketo Sano
Follow
May. 25, 2015
•
0 likes
238 likes
×
Be the first to like this
Show More
•
30,871 views
views
×
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Check these out next
コンテナDojo #4:VSCodeを使ったPodmanコンテナアプリ開発.pdf
Teruyoshi Matsushima
Ruby 3のキーワード引数について考える
mametter
コルーチンでC++でも楽々ゲーム作成!
amusementcreators
やはりお前らのMVCは間違っている
Koichi Tanaka
5分でわかるクリーンアーキテクチャ
Kenji Tanaka
SQLアンチパターン - 開発者を待ち受ける25の落とし穴
Takuto Wada
サーバーサイドな人がフロントエンド技術と仲良くするはじめの一歩
Y Watanabe
第ⅲ部:Clean architecture 設計の原則
tak
1
of
51
Top clipped slide
さらに上を目指すための iOS アプリ設計
May. 25, 2015
•
0 likes
238 likes
×
Be the first to like this
Show More
•
30,871 views
views
×
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download Now
Download to read offline
Report
Software
2015/05/13 ヤフー社内「中級 iOS アプリ開発者」向けに行った講義の資料。
Taketo Sano
Follow
Advertisement
Advertisement
Advertisement
Recommended
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
Ken Morishita
83.9K views
•
78 slides
「速」を落とさないコードレビュー
Takafumi ONAKA
55.2K views
•
62 slides
WSL2+docker+JupyterとVS Codeリモート環境の構築
Saito5656
357 views
•
27 slides
オブジェクト指向とは何ですか?
sumim
2.1K views
•
29 slides
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
82.5K views
•
51 slides
VIPER アーキテクチャによる iOS アプリの設計
Yuichi Adachi
12.2K views
•
35 slides
More Related Content
Slideshows for you
(20)
コンテナDojo #4:VSCodeを使ったPodmanコンテナアプリ開発.pdf
Teruyoshi Matsushima
•
299 views
Ruby 3のキーワード引数について考える
mametter
•
9.6K views
コルーチンでC++でも楽々ゲーム作成!
amusementcreators
•
7.4K views
やはりお前らのMVCは間違っている
Koichi Tanaka
•
143.2K views
5分でわかるクリーンアーキテクチャ
Kenji Tanaka
•
19.4K views
SQLアンチパターン - 開発者を待ち受ける25の落とし穴
Takuto Wada
•
17K views
サーバーサイドな人がフロントエンド技術と仲良くするはじめの一歩
Y Watanabe
•
4.5K views
第ⅲ部:Clean architecture 設計の原則
tak
•
134 views
クロージャデザインパターン
Moriharu Ohzu
•
19.5K views
いまさら聞けないDocker - 第5回コンテナ型仮想化の情報交換会@大阪
Kunihiro TANAKA
•
14.3K views
C++でCプリプロセッサを作ったり速くしたりしたお話
Kinuko Yasuda
•
33.1K views
go_router が隠してくれるもの
cch-robo
•
1.2K views
Eclipseデバッガを活用するための31のtips
Hiroki Kondo
•
51.3K views
umapを使ったフリーマイマップの作り方
Fuminori Hoshian
•
2.9K views
名は体を表していますか
infinite_loop
•
1.8K views
CODE BLUE 2014 : バグハンターの愉しみ by キヌガワマサト Masato Kinugawa
CODE BLUE
•
25.1K views
Docker管理もHinemosで! ~監視・ジョブ機能を併せ持つ唯一のOSS「Hinemos」のご紹介~
Hinemos
•
4.4K views
世界一わかりやすいClean Architecture
Atsushi Nakamura
•
45.1K views
テスト駆動開発のはじめ方
Shuji Watanabe
•
27.2K views
Luigi PyData presentation
Elias Freider
•
16.8K views
Viewers also liked
(20)
IOS/Androidアプリの3つの大事な設計方針
Ken Morishita
•
44K views
iOS アプリのメンテナンス性を高めるための基本的な考え方
kakegawa-atsushi
•
13.8K views
BaseViewControllerは作りたくない
今城 善矩
•
7.2K views
「数える」とは何か? 〜 「とは何か?」を問う、AI時代の数学
Taketo Sano
•
4.5K views
iOSやAndroidアプリ開発のGoodPractice
Ken Morishita
•
12.4K views
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Masaru Gushiken
•
12.4K views
大企業でスクラムしたら筋肉だった
Yusuke Kawanabe
•
36.1K views
プログラマのための線形代数再入門
Taketo Sano
•
53.8K views
何もないところから数を作る
Taketo Sano
•
9.5K views
3 auto layout tips
Tomoki Hasegawa
•
3.4K views
プロトコル指向 - 夢と現実の狭間 #cswift
Tomohiro Kumagai
•
3.5K views
NS Prefix 外伝 … Copy-On-Write #関モバ
Tomohiro Kumagai
•
3.7K views
Swift 2.0 大域関数の行方から #swift2symposium
Tomohiro Kumagai
•
12.7K views
AnyObject – 自分が見落としていた、基本の話
Tomohiro Kumagai
•
4K views
objc2swift (続・自動変換の野望)
Taketo Sano
•
4.3K views
デザイナーとエンジニアが話す、iOSアプリケーション開発
Kenta Ohsugi
•
8.7K views
objc2swift 〜 Objective-C から Swift への「コード&パラダイム」シフト
Taketo Sano
•
7.6K views
基底変換、固有値・固有ベクトル、そしてその先
Taketo Sano
•
31.3K views
知らないと損するアプリ開発におけるStateMachineの活用法(full版)
Ken Morishita
•
18.5K views
プログラマのための線形代数再入門2 〜 要件定義から学ぶ行列式と逆行列
Taketo Sano
•
57.2K views
Advertisement
Similar to さらに上を目指すための iOS アプリ設計
(20)
ウォーターフォールとアジャイル開発の比較
Unicast Inc.
•
24.7K views
DevLOVE iPhoneアプリ勉強会
Toshimitsu Takahashi
•
1.3K views
e-Learning Design for Teacher
Sunami Hokuto
•
1.2K views
Itca yammer提案110615
伸夫 森本
•
1.2K views
2019年度 若手技術者向け講座 オブジェクト指向
keki3
•
91 views
20090924 YAMAHA Webforum Sort
loftwork
•
701 views
プロジェクトを成功に導くための秘訣
loftwork
•
1.3K views
DSLによる要求獲得でスーパーアジャイル
陽平 山口
•
1.2K views
アジャイルマネジメントとは?
Kiro Harada
•
4.4K views
131207 NECTJ Workshop 2
NECTJ
•
545 views
タブレット端末を学習に活かすさまざまなアイデア
Naoya Sangu
•
8.2K views
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
masashi takehara
•
1.2K views
iQONの開発手法 at iQONエンジニアセミナー
Imamura Masayuki
•
4.9K views
保守性の高いアプリケーション設計について
TomomitsuKusaba
•
250 views
Project Management
Kazuto Omori
•
692 views
#MSIgnite x Japan Microsoft MVP/RD - Learning story
Rie Moriguchi
•
966 views
MAごころを、君に - #7 ChatGPT勉強会(2023-03-28)
Webpla LLC.
•
87 views
社内 DDD 勉強会第1回
shingo suzuki
•
419 views
2012ー1 TENTOプレゼン資料
TENTO_slide
•
264 views
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
nishio
•
13.3K views
More from Taketo Sano
(19)
Divisibility of Lee’s class and its relation with Rasmussen’s invariant / 201...
Taketo Sano
•
1.1K views
トポロジーと圏論の夜明け
Taketo Sano
•
3.3K views
Swift で数学研究のススメ
Taketo Sano
•
1.4K views
(意欲的な中高生のための)トポロジー・圏論・コンピュータ
Taketo Sano
•
3.8K views
特性類の気持ち
Taketo Sano
•
3.8K views
Swift で数学のススメ 〜 プログラミングと数学は同時に学べ
Taketo Sano
•
29.3K views
山手線は丸いのか?プログラマのためのトポロジー入門
Taketo Sano
•
24K views
何もないところから数を作る
Taketo Sano
•
4.7K views
情報幾何学 #2.4
Taketo Sano
•
2K views
情報幾何学 #2 #infogeo16
Taketo Sano
•
2.2K views
objc2swift (自動変換の野望)
Taketo Sano
•
6.6K views
2015 02-18 xxx-literalconvertible
Taketo Sano
•
3.8K views
let UIWebView as WKWebView
Taketo Sano
•
29.5K views
コードを書けば複素数がわかる
Taketo Sano
•
4.8K views
虚数は作れる!Swift で学ぶ複素数
Taketo Sano
•
42.2K views
ひろ子 in Objective-C
Taketo Sano
•
6.6K views
Objective-C が好きになる Tips & Hack
Taketo Sano
•
38.6K views
Konashi で始める iOS 電子工作
Taketo Sano
•
4.8K views
下位互換コード隠蔽のストイシズム
Taketo Sano
•
11.3K views
Advertisement
Recently uploaded
(20)
☀️【密德萨斯大学毕业证成绩单留学生首选】
25mjhd12
•
6 views
留信网认证可查【威得恩大学文凭证书毕业证购买】
32lkhng
•
2 views
国外学历【魁北克大学研究生文凭毕业证留学生首选】
ewq15a
•
2 views
在哪里可以做《邦德大学文凭证书|毕业证》
kjds1245
•
2 views
在哪里可以做《南安普顿大学文凭证书|毕业证》
1232hdjk
•
2 views
留信网认证可查【艾格伍学院文凭证书毕业证购买】
32lkhng
•
2 views
☀️【萨德伯里大学毕业证成绩单留学生首选】
15sad
•
2 views
①【利兹贝克特大学毕业证文凭学位证书|工艺完美复刻】
love445ds
•
2 views
①【诺丁汉大学毕业证文凭学位证书|工艺完美复刻】
0987hgh789
•
2 views
①【伦敦政治经济学院毕业证文凭学位证书|工艺完美复刻】
0987hgh789
•
2 views
測量データ処理ソフト・MarineDiscoveryの紹介
ssuserbceee8
•
22 views
国外学历【尼尔森理工学院研究生文凭毕业证留学生首选】
jsad789
•
2 views
留信网认证可查【怀俄明大学文凭证书毕业证购买】
1lkjhg
•
2 views
測量データ処理システム「MarineDiscoveryクラウド」の紹介
ssuserbceee8
•
39 views
☀️【伯明翰大学毕业证成绩单留学生首选】
25mjhd12
•
2 views
測量支援ソフト「みとおしえ」「みとおしえクラウド」の紹介
ssuserbceee8
•
42 views
留信网认证可查【南安普顿大学文凭证书毕业证购买】
32lkhng
•
2 views
留信网认证可查【罗德岛大学文凭证书毕业证购买】
1lkjhg
•
2 views
☀️【斯旺西大学毕业证成绩单留学生首选】
25mjhd12
•
2 views
留信网认证可查【麻省大学洛威尔分校文凭证书毕业证购买】
hh123hh1
•
2 views
さらに上を目指すための iOS アプリ設計
さらに上を目指すための iOS アプリ設計 @taketo1024
(このスライドはヤフー社内で「中級者iOSアプリ開発者」向けに行った講義の資料です)
本講座の目的 • iOSアプリ開発者がより高い視点からアプリの設計 を考えられるようになること。 • デザインパターンなどのお堅い話ではなく、「いい 設計」を感覚的に納得できるようにしたい。 •
「いい設計」を意識できるようになり、プロダクト の品質と開発スピードが上がれば嬉しいです。
Agenda 1. アプリ開発における「いい設計」とは? 2. Storyboard
/ xib / コードの住み分け 3. delegate / callback / notification の使い分け 4. インターフェース ∼ 晒すものと隠すもの 5. 肥大化したクラスをスリム化する 6. 通信処理のカプセル化と使い捨て 7. 外部ライブラリの使用を判断するポイント 8. おまけ:これからの Swift 対応のために
1. アプリ開発における「いい設計」とは?
やってはいけないこと 最初から「神殿のような設計」を求めない方がいい。
アプリ開発において受け入れるべき 「3つの変化」 1) OS/デバイス/開発言語/フレームワークの進化 • 最新のものでも1年後には当たり前のように陳腐化している。 •
ARC がなかった時代、block がなかった時代とでは「最適な設計」は当然違う。 2) ユーザニーズ/トレンドの変化 •「最適な設計」が完成する頃にはもうそれ自体不要になっていたりする。 • アプリ全体に影響を与えるようなフレームワークの採用には注意(例:Three20)。 3) チーム/メンバーの変化 • 人材流動化の時代。いつでもメンバーは入ったり抜けたりする。 • サービスやチームの規模も大きくなれば、設計のあるべき形も当然変わる。
変化に対応できる「いい設計」の要件 1) 柔軟性 • プロダクトの要件や仕様の変更にすぐ対応できる。 •
特定のライブラリやフレームワークにできるだけ依存しない。 2) 拡張可能性 • 一極集中せず、機能を並列的に付け足していける。 • 逆に不要になったものは簡単に取り外せる。 3) 安定性 • 何かをちょっと変えただけで落ちまくるようになっては困る。
参考:「メタボリズム」 建築には空間的な制約があるが、ソフトウェアは真にメタボリックな設計が実現可能。 メタボリズムは、1959年に黒川紀章や菊竹清訓ら日本の若手建築家・都市 計画家グループが開始した建築運動。新陳代謝(メタボリズム)からグルー プの名をとり、社会の変化や人口の成長に合わせて有機的に成長する都市 や建築を提案した。 彼らの構想した将来の都市は、高度経済成長という当時の日本の人口増加 圧力と都市の急速な更新、膨張に応えるものであった。 彼らは、従来の固定した形態や機能を支える「機械の原理」はもはや有効 的でないと考え、空間や機能が変化する「生命の原理」が将来の社会や文 化を支えると信じた。 … 引用:Wikipedia中銀カプセルタワービル 黒川紀章
僕はこう思うッス 慣れない内はまずはスピード優先で作っていい。開発速度 が鈍ってきたらリファクタリングを検討しよう。そのとき にちゃんと時間を取らせてもらえるようにマネージャとの 信頼関係を築いておくことも大事です。
2. Storyboard /
xib / コード の住み分け
あかんパターンその1. 激重スパゲッティストーリーボード • 画面数が多くなると重く、可視性も悪くなる。 • チーム作業だとコンフリクトしまくってやばい。
あかんパターンその2. 全部コードで書いてる • UI の微調整が大変になる。 •
チーム作業の場合つらい。デザイナとの分業もできない。 - (void)viewDidLoad { [super viewDidLoad]; UITextField *textField = [[UITextField alloc] initWithFrame:CGRectMake(10, 200, 300, 40)]; textField.borderStyle = UITextBorderStyleRoundedRect; textField.font = [UIFont systemFontOfSize:15]; textField.placeholder = @"Message"; textField.autocorrectionType = UITextAutocorrectionTypeNo; textField.keyboardType = UIKeyboardTypeDefault; textField.returnKeyType = UIReturnKeyDone; textField.clearButtonMode = UITextFieldViewModeWhileEditing; textField.contentVerticalAlignment = UIControlContentVerticalAlignmentCenter; textField.delegate = self; [self.view addSubview:textField]; … }
なかなか最適解がない • Storyboard のいいところ •
アプリの画面構成・遷移が一望できる。 • 簡単な遷移ならコードを書かなくてもいい。 • UI をグラフィカルに構成していける(デザイナと分業できる)。 • もどかしいところ • 画面遷移も構成も一個のファイルに詰め込んだら当然重くなる。 • 文字列の ID でコードと紐付けなきゃいけない。 • 遷移間の処理は prepareForSegue:sender: で分岐しなきゃいけない。
僕のオススメのやり方 • Storyboard は画面遷移を定義するためだけに使う。 •
各コントローラの UI 構成は xib で作る。 • 画面の遷移処理は performSegueWithID: でやる。
Storyboard で画面遷移、xib で画面構成 Viewを外しておく + 対応するファイル名の
xib が自動で読み込まれる!
これで全体の画面遷移と各々の画面構成が分離できる + … Storyboard で画面遷移、xib で画面構成
Storyboard 非対応な外部ライブラリもこの方法で行ける #import "XYZStoryboardSegue.h" @implementation
XYZStoryboardSegue - (void)perform { // 具体的な処理 } @end 独自 UIStoryboardSegue を作れば、どんな遷移も繋げる
performSegueWithId: で遷移処理 - (void)cellTapped:(XYZTableViewCell
*)cell { XYZWebEntity *entity = cell.entity; [self performSegueWithIdentifier:@"Browser" preparation:^(UIStoryboardSegue *segue) { XYZWebViewController *vc = segue.destinationViewController; vc.title = entity.title; vc.URL = entity.linkURL; }]; } • prepareForSegue: に遷移処理をまとめて分岐させるのは嫌なので、遷移時にブロッ クを渡せるように拡張した(method-swizzling によるちょい裏技)。 • StoryboardID を別ファイルにしたり、遷移処理をメソッド化してカテゴリと切り 出したりすれば、各 ViewController では Storyboard のこと意識せずに済む。
• このやり方の難点 • xib
だと navigationItem を指定したりできない(Outlet で繋いでおい てコードから指定することはできる) • 画面遷移処理は全てコードで記述しなきゃいけない。 • その他のやり方 • xib を使わず 画面遷移用の Storyboard と各画面別の Storyboard を 分ける。 • Segue は使わず、 instantiateViewControllerWithIdentifier: によって コードで VC を生成して画面遷移。
僕はこう思うッス 現状最適なソリューションはないので、画面の数やチーム人数に応 じて上手くやってける方法を探っていきましょう。
3. delegate /
callback / notification の 使い分け
原則:相互参照は良くない • 特殊なケースを除いて、オブジェクトが相互に参照しあってメッセージを送り合うの は密結合になってよくない。 • アプリは基本的に木構造になっているので、子が親を参照したり、子同士で参照しあっ たりしないように気をつけたい。 •
オブジェクト間の依存関係を必要最小限に制限しながら通信する方法としてある delegate / callback / notification の3パターンを解説します。 親 子 親 子 子
A) delegate パターン •
UITextFieldDelegate, UITableViewDelegate, UIImagePickerControllerDelegate など。 • 子(委譲する側 = delegater)は親(委譲される側 = delegate)の詳細については知らず、必要に応じて問い合わ せ/丸投げする。 • TableViewController(親)が TableView(子)を持つよう な、親が子を管理していてその存在期間中に密なやり取りが ある場合に有効。 • 1対N には不向き(親のメソッド内で分岐が必要になる) • VC 間の通信も delegate パターンになっていることが多い。 親 (delegate) 子 (delegater) 子は無責任に問い続ける
B) callback パターン •
UIAlertControllerAction, …WithCompletionHandler: など。 • 親が子に対してやっておいて欲しい処理を予め指定しておく。 • 子への命令とコールバックをまとめて書けるのが利点。 • 通信などの単発の命令の完了処理や、処理中に密なやり取りを する場合に有効。 • AlertView / ActionSheet が callback パターンになったのは 必然。 親 子 子 用が済んだらサイナラ
C) notification パターン •
UIApplicationWillEnterForegroundNotification, UIKeyboardWillShowNotification など。 • 通知者が受信者が誰なのかを直接知らない場合に有効。 • 受信者からのレスポンスを受け取りたい場合は使えない。 • ある画面でコンテンツを Like したのが、他画面でも反映 されてて欲しい場合などに有効。 • コード上では依存関係が見えにくいので、仕様変更による 不具合には注意が必要。 NotificationCenter 親1 親2 親3 子 (親子という表現は適切でないが、前の二つとの関連のため)
どのパターンにせよ、 「子は親のことを知らなくていい」ことが大事! 親 子 delegate 親 callback 子 子 notification NotificationCenter 親1 親2 親3 子
僕はこう思うッス いちいちプロトコルを作るのは面倒だから直接参照したくなるけど、 放っておくとすぐスパゲッティ化するので、早いうちから不必要な 依存性はシャキッと断ち切っておきましょう。
4. インターフェース ∼
晒すものと隠すもの
公開プロパティ/メソッドは できるだけ少なくシンプルにしておく。 • クラスの内部状態/内部でのみ使う操作は private
にしておきましょう (Obj-C なら無名カテゴリ/Swift なら private で)。 • 外から変更されることのない property は readonly / immutable に。 • サブクラス化前提のクラスで、子クラスのみに公開する必要のあるもの も public にしない。(Swift なら internal で、Obj-C はサブクラス専 用ヘッダを用意する) • 「このクラスの役割は何なのか」を意識し、「適切な名前がつけられる かどうか」を正しい設計の指針にする。
僕はこう思うッス 細かなコーディング規約よりもインターフェースの正しさを意識する 方がずっと大事。 クラスの内部実装が汚いのは直しようがあるが、インターフェースが イビツだと修正が大変(内装のリフォーム < 骨格の改築)。
5. 肥大化したクラスをスリム化する
参考:
BaseViewController の危険性 • 共通処理をなんでもかんでも
BaseVC に入れると、どんどん Fat 化してどこに何があるのか分からなくなる。メンテナンス性も下 がるし、変更の影響が見えづらく危険。 • 共通処理のうち一部カスタマイズできようにしようとする必要が 出てきたりして、サブクラスで共有のパラメータを用意したりテ ンプレートメソッドを作るハメになって余計ややこしくなる。 • iOS がアップデートして BaseVC でやってる処理が不要になって も容易に取り外せなかったりする。
スリム化の戦略をいくつか A. モジュール化して切り出し B. 基底クラスをカテゴリ拡張 C.
クラスの実装を分割
A. モジュール化して切り出し • 例えば
TableVC / CollectionVC の delegate / dataSource を別クラスにする。 • 切り出したモジュールとの間での相互参照が増えすぎないように気をつけないといけない (意外とこれが難しいので何でも切り出せばいいというものでもない)。 • 切り出したモジュールが専用の protocol を用意して、親への参照をなくしたりする。 TableViewController TableViewDelegate TableViewDataSource TableViewDelegate TableViewDataSource TableViewController
B. 基底クラスをカテゴリ拡張 • 共通処理のうち、独立性の高い機能を切り出して
UIViewController 拡張にする。 • ロギング、キーボード表示関連、アラート/HUD表示 など全画面共通の機能。 • これも UIViewController+Common などとするとすぐ Fat 化するので注意。 MyViewController 共通処理 1 共通処理 2 UIViewController + ... 共通処理 1 UIViewController + ... 共通処理 2
C. クラスの実装を分割 • Extension
は既存クラスを拡張するためだけでなく、自分で作ったクラスの実装を分割す るためにも使える。 • 例えば AppDelegate にはいろんな機能が詰め込まれがちだけど、互いに無関係なものが 多いので、機能群をまとめて分割するといい。 MyClass まとまり1 まとまり2 MyClass MyClass + まとまり1 MyClass + まとまり2
僕はこう思うッス 最初から何でもかんでも共通化/クラス分割しようとすると危険。 特にクラス階層を深くするのは慎重に。全体像が見えてないうちは ベタ書きのまま我慢。 美意識よりも効果を優先しましょう。
6. 通信処理のカプセル化と使い捨て
通信処理のカプセル化 • Controller /
Model に生の通信処理を書くべきではない。 • endpoint-URL や、リクエストパラメータ、レスポンスの仕様に ついて利用者が意識しなくて済むようにしたい。 • レスポンスは Dictionary などのプリミティブ型ではなく、専用の エンティティクラスを用意した方がいい。型セーフになるし API の仕様変更に対しても柔軟に対応できる。
僕が好きなやり方: 通信自体をオブジェクトとして使い捨てる - (IBAction)searchButtonTapped:(UIButton *)button { NSString
*query = …; XYZSearchRequest *req = [XYZSearchRequest requestWithQuery:_query]; [req startWithHandler:^(XYZSearchResultSet *result, NSError *error) { // 通信コールバック if(error) { … // エラー処理 return; } … }]; } • 通信開始のための手続きがシンプルでいい。 • インスタンス保持しておけば通信をキャンセルすることもできる。
僕はこう思うッス AFNetworking のようなガッツリした通信ライブラリは本当に必要 か見直してみましょう。 API
仕様の特殊性を吸収する簡単なラッパー があればほとんどの場合十分。
7. 外部ライブラリの使用を判断するポイント
• まずソースコードは必ず確認する。 • IF仕様がイケてなかったら実装もきっとイケてない(クラッシュの原因にもなり うる)。 •
コードが公開されていないものは信頼性が保証されている場合に限定すべき。 • 他にも同様のライブラリがないか確認する。★数や最終コミット日時(継続的にメ ンテナンスされてるか)なども確認する。 • 分厚いライブラリの場合は警戒する。全面的にその仕様に依存した設計になってし まうのはリスク(例: Three20)。 • 自分が欲しい機能はそのライブラリの何割を占めるか?一部だけならそのコードに インスピレーションを受けた上で自作した方がいいかもしれない。 • それでも使用した方がよければ、ライセンスを確認した上で使わせて頂きましょう。
8. (おまけ)これからの Swift
対応のために
Swift 対応 既存コードを機械的 に書き換える Swift 最適化+ こっちの作業は機械がやればいい!
objc2swift project https://github.com/yahoojapan/objc2swift Fork me!
総まとめ:僕はこう思うッス よくできた設計は Storyboard とクラスのインターフェースを一望 するだけで大体の構造が分かる。細かくルールを定めるよりも先に、 どういう設計を目指すのかチームのみんなで合意しておきましょう。
Questions?
Thanks! @taketo1024
Advertisement