Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
担当しているiOSアプリを全部作り直す開発中に_いろいろ半自動化した事_簡易版.pdf
Search
SatoshiN
November 03, 2019
0
69
担当しているiOSアプリを全部作り直す開発中に_いろいろ半自動化した事_簡易版.pdf
SatoshiN
November 03, 2019
Tweet
Share
More Decks by SatoshiN
See All by SatoshiN
開発スピード向上Tipsその2.pdf
satoshin303
0
49
秘伝のタレ.pdf
satoshin303
0
25
GitHub小技集.pdf
satoshin303
0
28
iOS_DC_2018_参加レポート.pdf
satoshin303
0
25
量子コンピュータ_の仕組みとQ_.pdf
satoshin303
0
190
モバイルアプリ_開発スピード向上Tips.pdf
satoshin303
0
23
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
42
2.7k
Into the Great Unknown - MozCon
thekraken
39
1.9k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
730
Thoughts on Productivity
jonyablonski
69
4.7k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
500
Become a Pro
speakerdeck
PRO
28
5.4k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Statistics for Hackers
jakevdp
799
220k
GitHub's CSS Performance
jonrohan
1031
460k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Transcript
担当しているiOSアプリを 全部作り直す仮定で いろいろ半自動化した事 簡易版
自己紹介 佐藤慎(さとしん) Twitter @satoshin2071 GitHub https://github.com/SatoshiN303 最近の趣味は カレコ (カーシェア) できままにドライブです
話すこと 0. 前提 & 開発環境の確認 1. ビルド成果物の配布自動化 2. PR時に最低限のコードレヴューを自動化 3.
ObjCの実装からSwiftでの新設計へ半自動で出力 4. UITest実行時に画面のスナップショットを撮影 5. WebやAndroidで似た様な事をするには
前提 & 開発環境の確認 - 2014年?から続いてる年賀状ECアプリ (2017から参加) - 時期によって利用できる機能や見た目が変わる -
2019/10/1にSwiftで再設計・再実装してリリース - iOSアプリは 3名~5名くらいで開発 - TD/ PG で顧客との折衝、設計・実装 担当(なんでもやる)
前提 & 開発環境の確認
案件の一番の課題 毎年エンジニアがほぼ入れ替わる 対策の一つとして自動化
1. ビルド成果物の配布自動化
None
2. PR時に最低限のコードレヴューを半自動で行う
None
None
3. ObjCの実装からSwiftでの新設計へ半自動で出力 ▪解決したい課題 • 2019はObjCの実装をSwiftで書き直してリリース • 新しい設計はファイル数が増えるデメリット (画面関連だけで約360個くらい)
時間が掛かる依存関係の解決方法
None
依存関係が解決されたファイルを360個 生成 旧実装をpythonでクロールしてSwiftファイルを生成 依存関係のあるプロパティはファイル名に応じて変更
依存関係をコード生成時に解決 Swinject / SwinjectStoryboard x CleanArchitecture を採用しているので DIグラフの解決がほぼ定型文で pythonでの生成が容易
時間が掛かるどの画面で何のWebAPIを 叩いてるかを紐付けした上で生成 ※MVCでいうModelとEntityにあたる部分は別途生成済み
どの画面がどのAPIを叩いてるかを抽出 tail -rで旧ファイルを逆表示して読み込み、APIを使用しているメ ソッドを取得する。 そのメソッドを使っているViewControllerをク ロール 例 AddressBookEditViewController' ['address_send_parse.php','as_updateScanUnconfirmData.php', 'address_parse.php',
'postcode.php', 'get_address.php'],
通信まわりの責務を持つファイルに追記 抽出結果を元に 生成済みの下記ファイルに 利用するAPIを叩く処理を追記すれば紐付けは完了 ◦◦Protocols.swift, ◦◦UseCase.swift, ◦◦Gateway.swift
4. UITest実行時に画面のスナップショットを撮影 ▪解決したい課題 * 複数デバイスでの表示崩れの確認に時間が掛かる。 * 改修前の表示との比較が一発で出来ない
UITestを実際に動かしてみるデモ
現状のUITest運用の課題 - Xcodeのバージョンを上げると通っていたテストが通らなくなるなど安定性に欠ける - 録画機能で UITestの記述自体は楽にはなったが 自前で条件分岐等を書かないと 通らない箇所もある - WebView
の中身のテストは省いている - 時間が掛かる => 簡易的な表示系の確認はSnapShotTestCaseを検討 - 運用問題
5. WebやAndroidで似た様な事をするには * 設計 => CleanArchitecture * UITest + スナップショット
=> Selenium, screenshot-tests-for-android * 自動レヴュー => danger-js, GitlabCI
まとめ 運用案件において 後々時間を奪う要因になりそうなものに対してはお金と実行ス ピードとのバランスを考えて できることから早めに対処しておくと幸せになれるはず