iPlayground 2025 - 接⼿ 10年⼤雜燴：專案現代化與產品開發的挑戰

Transcript

1. Rakuten Rebates 接⼿ 10 年⼤雜燴：專案現代化與產品開發的挑戰 Aug 30th, 2025 Assistant Manager, Rebates iOS Team Vincent Chen
2.  Agenda • 我是誰 • Rakuten Rebates 是個什麼樣的服務 • 接⼿時的狀態 (2020年) • 挑戰❶ ‒ 協調需求：達成商業需求、換取籌碼 • 挑戰❷ ‒ 有效溝通：跨團隊溝通、提案圖像化及增加⾃我價值 • 挑戰❸ ‒ 改善專案：簡化以及現代化專案 • 挑戰❹ ‒ AI ⼯具策略 • 總結、書單
3.  總結 • 技術債 不是 技術問題，⽽是 團隊合作 、 資源協調 和 共識取得 技術的負債というのは、技術的な問題というよりも、チームワークとリソースの調整そして合意形成に関わる問題である。 • 敘事以 商業上 的 價値貢獻 為出發點，⽽⾮強調「這個程式碼不好我要重構」 「このコードが悪いからリファクタリングしたい」と主張するのではなく、ビジネス上の価値貢献を軸にして語りましょう。 • 看到有掉球可以試著幫忙撿球，但是需要把撿球的⼈⼒成本公開透明 ボールが落ちているのを⾒たら、拾っちゃっても構いませんが、そのコストを明確にする必要があります。 • 對所有的任務⽤合理的⽅式化繁為簡 あらゆる業務を、適切かつ合理的な⽅法でシンプルにする。 • ⽤最平鋪直述的語⾔溝通，把需要多加解釋的機會降到最⼩→ 尤其成員都不是⽇⽂/英⽂⺟語者 可能な限りわかりやすい⾔葉でコミュニケーションをを取り、補⾜の必要性をできる限りなくしましょう。特に相⼿はネイティブではない⽅。
4.  注 意 事 項 今天提到做法適合我們團隊和當下的情境。當想要參考使⽤時，請適度彈性改變。如果有進⼀步的問題，歡迎在會後⼀起聊聊。 今回ご説明したアプローチは、我々のチームに最適化したものです。貴チームで導⼊をご検討の際は、その状況に合わせて柔軟に調整していただくこ とをおすすめします。何かご不明な点がございましたら、セッション終了後にお気軽にお声がけください。 簡報內容的⽤詞盡⼒做到正體中⽂，但是在不同語境下還是會有英⽂、⽇⽂⽤法出現，請⾒諒。 本プレゼン資料では、可能な限り繁体字中国語の⽤語を⽤いるよう⼼がけましたが、⽂脈によって英語や⽇本語表現も含まれることをご了承ください。 簡報內容盡量做到⽇⽂翻譯，因為版⾯和內容沒有翻譯時請⾒諒。 本プレゼン資料では、可能な限り⽇本語に翻訳しましたが、レイアウトやコンテンツの都合で翻訳を付けない場合がありますので、ご了承ください。 簡報內有提到⾮樂天集團相關的名稱、版權及商標，權利皆歸屬原公司，本簡報盡⼒做到審査和合理運⽤。 本プレゼン資料に登場する楽天グループ外の名称、著作権、商標につきましては、その権利はすべてオリジナルの企業に帰属します。本プレゼン資料 では適切な引⽤・使⽤を⼼がけをいたしました。 ⽇⽂翻譯／⽇本語翻訳：⾃分、校閲： Rakuten AI + Atlassian Intelligence
5.  我是誰 ‒ Vincent Chen Rakuten Rebates, iOS team (2020~) 現 Assistant Manager ・ 兼 Mobile App 委員會成員、ECID AI 委員會成員 個⼈背景 • iOS Developer (2012~)，前後端、Android 等等為輔 • 涉⾜ UI/UX，Team Building，跨領域應⽤，產品開發 • ᯩଶ໢ท → ಈଶ໢ท • ܥ౷෼ੳઃܭ ˙ ೈᱪ։ᚙ • ਓػޓಈ • Wireframe • ฏ໘ɺ3D ɺӨย੡࡞ • Branding ˙ ଟഔᱪઃܭɺ࢖༻ऀᱪᱛ ˙ J04ҝओ
   ଧᯑ • ࢧ෇ฏ୆ɺࢧ෇޻۩ SDK • ిࢠ঎຿ฏ୆ • લޙ୺ࢧԉ • UI/UXࢧԉ • ղܾํҊن֢ɺ৽ਓ܇࿅ ላੜ࣌୅ ୆ᖯ ೔ຊ ˙ J04ҝओ
   ଧᯑ • ৽૑ҝओɺჩᢛ㗞඼։ᚙ • ࣗݐޙ୺҃ MBaaS • ॳظՍߏධဟɺઃܭ • 㚎෦ SDK ։ᚙ • ৽ਓ܇࿅
6.  Rakuten Rebates 是個什麼樣的服務 リーベイツとは ˙ 以 樂天點數 回饋使⽤者為主體的 導購服務 楽天ポイント還元による送客プラットフォーム • https://rebates.jp • 2016 年由樂天集團株式會社（⽇本）公開上線，服務地區僅⽇本國內 2016 年末始め、楽天グループ株式会社が運営。サービス対象は⽇本国内のみ。 • 使⽤者透過 Rebates 前往商家的線上商店購物，符合條件就可以獲得相應的樂天點數 リーベイツ経由で提携ショップのオンラインストアをご利⽤いただくと、条件に応じて楽天ポイントを進呈いたします。 • 店家種類：電腦、⼿機 、旅遊 、 服飾、⾷物 、⽇常⽤品 、⾼蛋⽩ 、滑雪⽤具等等 テナント：パソコン、スマホ、旅⾏、アパレル、⾷べ物、⽇常⽤品、プロティン、スキー、スノーボード⽤品など
7.  Rakuten Rebates 是個什麼樣的服務 リーベイツとは ˙ 系統來⾃ Rakuten Rewards (美國分公司) サービス、インフラーは Rakuten Rewards （アメリカ）によるもの • https://rakuten.com • 前⾝為 Ebates，服務地區以美國為主、加拿⼤、英國。曾涵蓋中國、南韓、新加坡、俄羅斯。 旧 Ebates 。アメリカを主にして、カナダ、イギリスを含む。過去には中国、韓国、シンガポール、ロシアなどの国々を含んでいた。 • 繼承後端、前端、 API 、Android 、iOS 的程式碼以及多個⾏銷⼯具 BE, FE, API, Android と iOS を含め、マーケティングや分析ツールも多数受け継いています。
8.  iOS 專案時間線 Ebates ૑ۀ 1998 Rebates ։࢝ᅎӡ 2016 ᒜఱᏅߪ 2014 Ebates iOS app 2013 Rebates iOS app 2017 iOS app ᘐཱ repo 2019 Rebates ׬શҠআ 2021 Ճೖ 2020 * 年份無照實際⽐例尺擺放 ᔒ༗ iOS ޻ఔࢣ 2020 Rakuten Rewards (Ebates) Rakuten Rebates ˙ 技術債的累積
9.  接⼿時的專案狀態 (late 2020) MVC MVVM RIBs Carthage Subproject (.framework, with Carthage) 整包拉進來 Git submodule 不同 subproject ⽤的函式庫版本不⼀樣 Interface Builder (Storyboard, XIB) Visual Format Anchor layoutSubviews 計算 cell ⾼度的算式 KVO Notification Center RxSwift Method Swizzling Pass by Reference NSOperationQueue No CI/CD 測試 Target 無法執⾏ Many Targets Many .xcconfig Many Configurations Monster View Controller ⼀個實作檔同時被加到不同的 embedded frameworks 冗餘繼承 不當共⽤
10.  接⼿時的課題 ࠔ೉ ˙ աଟඒᅳํ的商業邏輯 很難問到哪些東⻄還有⽤，還能動的東⻄ 就不要變更刪減 削除できるかを知る⼈は極めて少ない、動けるものはで きれば触らないほうが良い。 ਖ਼໘ ˙ 有 Jira 票、Confluence 可以査 • PRs, branches, commits 都有 票號 • Jira 票能回連到 GitHub • 能在 Slack 找到討論串 • 美國那邊有⼈能問；同事⼈都很好 • チケットナンバーはちゃんど追跡できる → GitHub, Jira, Slack などで • アメリカの同僚に聞くのができます • ⽇本側の同僚みんな優しい。 iOS 側の課題は共有で きて、限界はどこにあるのかよく理解してくれてる。 調査能⼒和維持關係變得很重要 ・・・・ ・・・・
11.  ⾸要任務 快速 地交付商業需求 正確 ओ؅ 我幫你準備了⼀個 catch up list 唷！
12.  關於技術債 把課題歸檔，視時機和⼿上籌碼解決 ・・・・ 索引⽂件 開票放 Backlog 有可視化數據 監控改善進度 讓 PM 了解現狀 ˠ ˠ 課題を⾒る度にチケットを切って棚上げさせる、タイミングを⾒て⼿持ちの交渉材料で解決を試みる ・・・・
13.  ௅ፌ⁞ ڠௐधٻ
14.  協調：和 PM 協調，分段需求 以專案現狀難以 ⼀步到位 当時のプロジェクト状態では、いきなり完成形に持っていくのは無理がある • 和 PM 協調，切分成適當的 ⼤⼩，分 phase 上線 PM 通して交渉し、複数フェースに • 順利上線，取得 籌碼 無事にリリース、交渉材料になる • 設計團隊想要⼤規模翻新 デザイナー：⼤規模リニューアルがしたい • 業務想要賣版位 セールス：売れるポジションが欲しい • ⾏銷想要測試點⼦ マーケ：アイディアを試したい • 需兼顧舊 iOS 版本 旧 iOS バージョンをカバー • 現有實作複雜改不動 複雑さで変更しにくい • UI 變更時容易破版 UI 変更で崩しやすい Before After ਎ҝ։ᚙऀ
15.  協調：解決⽅案保持彈性，活⽤現有資源、外部服務 商業需求難以 完全⾃家實作 Biz 要件をすべて⾃家製には無理がある • 活⽤現成⼯具達到⽬的 既存ツールを活⽤し⽬的を達成する • 使⽤ A/B Testing + user segmentation 服務 A/B Testing, ユーザーセグメントで きるサービスを使う • 都要⾃⼰實作 ⾃分で実装したがってる • 最佳解決⽅案 ベストな解決⽅法を求めたがってる • 要來做個很難的東⻄ 難しいそうなものを作りたがってる After ਎ҝ։ᚙऀ Before ݶ੍ • 開發資源不⾜ 開発リソースのなさ • 短時程 スケジュールが急 • ⾼優先 優先度は常に⾼め
16.  如何切分功能 ： 活⽤多種系統分析⼯具 • DFD (Data Flow Diagram, 資料流向圖) • 細分功能，浮現優先度與估時 → Divide and Conquer • 辨識複雜系統中的⾓⾊ → 使⽤者？後端？API？⾏動端？管理系統？外部服務？ • UML, Class Diagram, Sequence Diagram • 設計系統細部⾏為，也可以協助拆解流程 • User Story, User Flow Diagram • 避免過度從開發者觀點分析 • 細分功能， 浮現優先度與估時 • Wireframe ⼯具 → 紙筆、Figma 、After Effect etc. • 提案 → 「如果是 iOS 的話，畫⾯遷移怎麼樣會⽐較好」 開放 回饋・持續 改進
17.  ௅ፌ  ༗Ꮘߔ௨
18.  溝通：說別⼈聽得懂的話 • 去理解溝通對象 → 另⼀⽅⾯，情報掌握越多，對⾃⼰更有利 • 對⽅是什麼職種，就去了解對⽅的⼯作、在意什麼、⽤語 → 設計、業務、⾏銷、客服等等 • 共識：取得能達成⽬的共識 • 取得共識優先，為達⽬的沒有絕對的對錯，需適度讓步 • 要約：簡化、抽象化想表達的內容 → ⼯程師通常會想要解釋透徹 • 掌握聽者最想知道什麼，去除和開發有關的變數、⽅法 • 呈現⽅向、流程重於細節 • 先 結論 後 說明 關鍵字：顧問、溝通⼒、要約 、⾔いかえ、元認知 BCG問題解決⼒：⼀⽣受⽤的 策略顧問思考法 © 時報出版, 徐瑞廷, ⿈菁媺 ⼀番伝わる説明の順番 ©フォレスト出版, ⽥中耕⽐古 40字要約で仕事はどんどん うまくいく ©アーク出版, 原⽥ 虔⼀郎
19.  溝通：加⼊「格式」 ˙ ⽂字討論 • 善⽤ 條列式 ，避免使⽤⼤型段落 箇条書きを活⽤し、⻑い⽂書でのやり取りをなるべく避ける • 多段落時，段落之間加⼊ ⾏距（Slack: 多⼀⾏空⾏） 段落と段落の間にスペースを⼊れる • 適當使⽤粗、斜體以及底線強調 ˙ Ḥሜจ݅ • ⽂件加⼊ H1~H4 、 ⽬次 ⽬次と⾒出しをちゃんと⼊れる • 程式碼區塊 指定語⾔ 以上⾊，增加易讀性 読みさすくため、コードブロックに⾔語を必ず指定する • 內容複雜時善⽤ 表格 歸納多個項⽬，避免過度使⽤條列式 内容が複雑しすぎる時、表でまとめてみましょう。そして、箇条書きをしすぎないように。
20.  溝通：加⼊「格式」 ˙ ੡࡞圖表 • ⽤ 折線 ，避免⽤ 斜線 呈現不同元件之間的關係 • ⽤ 顏⾊ 和 線條 區分和群組不同責任的元件 • 同樣性質的⾏為⽤ ⼀致的圖形 呈現 • 字體⽤ 無襯線體 （黑體），避免⽤ ⼿寫字體 • ⽂字皆⽤ ⼀個詞 ，或 ⼀句話 完結，避免呈現太多字 關鍵字：Infographic, Layout Design, Information Architecture, Typographic Communication Patterns: A Guide for Developers and Architects © O’Reilly Jacqueline Read
21.  案例：與澳洲團隊合作的專案 (Autofill) 背景 在 App 多個階段（原⽣、Web View）和對⽅的 SDK 介接 需求 實作之外，需要分別和主管、資安審査、產品設計等不同的職種解釋資料流程 實作 共同進⾏後端條件庫⽇本在地化 AU SDK SDK JS 元件 Web View 初始化 Web View 是否 可初始化 注⼊ JS 是 使⽤者輸⼊資訊 後端 *呈現⽤途，細節經過⼤幅簡化
22.  案例：與澳洲團隊合作的專案 (Autofill) 初始化模組 AU SDK JS 元件 Web View 初始化 Web View 是否 可初始化 注⼊ JS 與多種互動 是 使⽤者輸⼊資訊 AU 後端 *呈現⽤途，細節經過⼤幅簡化 AU Side Rebates
23.  增加⾃⼰（⼯程師）在團隊裡的價値 了解不同團隊的專業 製作易讀的⽂件及圖表 制定⾃⾝團隊標準 提供 技術 上 可⾏的解決⽅案 從 技術⾓度 提供 商業 上 可⾏的解決⽅案 減輕客服成本 改善使⽤者體驗 降低營運成本 降低資安⾵險 etc.
24.  ௅ፌ⁠ ੔಴ሢҊ
25.  整頓專案：移除⾵險與瘦⾝（持續進⾏） 1. 有 版權疑慮 優先移除 • 字體：Rakuten Rewards 在過去使⽤過的授權字體 Rakuten Rewards が使⽤されたフォントを削除する • 有「包」⽽發佈上線即侵權，即使沒有實際套⽤到⽂字上。罰⾦有可能會追溯到上線⽇。 画⾯に使うかどうか問わず、アーカイブしてリリースされたらアウト。罰⾦をサービススタートまで加算される場合があります。 • 多媒體：沒在使⽤的 onboarding, promotion 影⽚ 2. card.io 3. 其他 • A/B 測試遺留檔案, Lottie 檔，俄羅斯、韓國、簡體中⽂等等國家的語⾔、圖檔 使われてない A/B testing, Lottie, ⾔語ファイル, アイコンなど https://www.youtube.com/watch?v=WIckr3HKtSU try! Swift 2025 Searching for Aliens By Noah Martin © try! Swift, Noah Martin
26.  整頓專案：提⾼ App Store 評價 提出假說並進⾏驗證 ˙ ⃧Ճ $5"
    $BMM
    UP
    "DUJPO 假說 • 使⽤者在 完成購物 時，會給⾼評價 （⺟體：⽇本的 iOS 使⽤者） • 使⽤者在 獲得點數 時，會給⾼評價 （CS 訪談） 做法 • 選定使⽤者 segment • 選定特定店家進⾏ A/B testing，variant 間有顯著差異後開放所有指定店家 ˙ ଖଞ၏๏ • 協助檢視 App Store 評價，幫助客服 (CS) 進⾏正確回覆 TCS として App Store にある評価と CS チームのレスポンスをレビューし正しい対応⽅法を提案する • 跟進 App Store 評價，提案並執⾏其他改善⽅案 App Store にある評価をフォローアップ、改善案を提案しリリースする
27.  綜合成果 123.6MB ݪେখ 103.2MB վળޙ 53.5MB ۙظ 經過 4 個⼩版本，成功減少約 16% App Store 評價顯著改善 2 4.* ˠ ˠ ˠ
28.  整頓專案：語法更新 • 新功能⽤ Swift • 新畫⾯、新元件⽤ SwiftUI • 前提：要⽤在 UIKit 的情境，避免過度 wrapping • 實作上 從簡 ，不過度分層，減少⽇後新成員加⼊的學習成本 • 定案 MVVM，逐漸減少 ⼤型 View Controller 和 RIBs • 從 複雜度 、可維護 考量，不引⼊⾮必要函式庫，尤其是⼤禮包型的 從 ⼩部分 迭代改善 需要⾼強度的 brainstorming 找模式，不能無論如何只要有新寫法就⽤
29.  Great software design looks simple because it eliminates as many failure modes as possible during the design stage. The best way to eliminate a failure mode is to not do something exciting (or if you can, not do anything at all). 好的軟體設計之所以看起來簡單，是因為它在設計階段就盡可能地消除 了很多失敗模式。⽽消除失敗模式的最佳辦法是 不要做任何「令⼈興 奮」的事情（如果可以的話，什麼都不要做）。 https://www.seangoedecke.com/great-software-design/ 《Great software design looks underwhelming》 by Sean Goedecke 在 PoC 做天⾺⾏空的嘗試，在 Production Code 達成簡單設計 （Proof of Concept，概念驗證）
30.  簡化 背後平時的準備 ‒ 架構採⽤、程式碼 閱讀公司內外⼤型 SDK 的程式碼、 issues 和討論 ⼤⼿ SDK 、repo と⾊んな issues や議論を読んでおきましょう • 了解業界常⾒的設計模式 デザインパターンを知る • 了解⼤家在意什麼，慣⽤什麼樣的寫法、慣⽤的詞彙 業界の⽅々が気になるところ、慣習、どんな名詞や名称を使ってるかを把握 實作上適度 封裝 和 資訊隱藏 (Information Hiding) • 思考的 edge cases 和 trade-offs，不過度封裝 エージケースとトレードオフを考えながら、 カプセル化をしすぎないよう • 思考什麼是⽤戶可以不知道的 ユーザーが何を知らなくてもいいかを考える • 防禦性程式設計：在介⾯ 增加限制，減少⾮預期⾏為 防御的プログラミング：ある程度制約を加えて、予期しない⾏為を防ぎ、間違えにくくする。
31.  簡化 背後平時的準備 ‒ 使⽤者介⾯ • 持續更新 UIKit, Swift, SwiftUI 的語⾔特性，了解如何簡化程式碼並能保留彈性 • 在網⾴或是 app 看到特別的 UI ，試著想想能怎麼做到，或是⾃⼰動⼿做做看 ˙ UIKit • 多活⽤ self-sizing ，UIStack ，讓 iOS SDK 幫忙排版 • 遵守 Apple 的官⽅建議，可以避免升⼤版本時破版 ˙ SwiftUI • 避免過多的邏輯判斷，過多或不合理的 modifier 影響到對 UI 結構的 閱讀 及 理解 • 善⽤ ButtonStyle 和⾃定義 modifier 包裝會重複使⽤的設定
32.  案例：SwiftUI Title Description Ճೖߪ෺ं 8 8 8 8 VStack { Text("Title") .padding(.vertical, 8) // ß Text("Description") .padding(.bottom, 8) // ß AddToCartButton() .padding(.bottom, 8) // ß } .padding(.horizontal, 8) VStack(spacing: 8) { Text("Title") Text("Title") AddToCartButton() } .padding(8) 物件之間有 8pt 的間距 內容容器外圍有 8pt 的邊界 *呈現⽤途，省略滿寬、佈局設定
33.  ௅ፌ⁡ AI ޻۩ࡦུ
34.  AI ⼯具策略 程式碼⽣成 應⽤程式 中短期活動⾴⾯ 錯誤容忍 中／⾼ 低 對策 課題 • 產出 deprecated 程式碼、不存在的⽅法和變數 • Figma UI ⽣成的 SwiftUI 架構不合理 • 花時間「引導」AI 做出正確產出 成員必須對⾃⼰的 PR 完全負責 • PR 前必須 review AI 產出，並識別： 正確性 效率・效能 分析 中／⾼ • 對了解程式碼⼤致現狀有幫助 • 會誤以為 protocol 沒被⽤ • 無法正確讀解複雜邏輯
35.  ័ ݁
36.  總結 • 技術債 不是 技術問題，⽽是 團隊合作 、 資源協調 和 共識取得 技術的負債というのは、技術的な問題というよりも、チームワークとリソースの調整そして合意形成に関わる問題である。 • 敘事以 商業上 的 價値貢獻 為出發點，⽽⾮強調「這個程式碼不好我要重構」 「このコードが悪いからリファクタリングしたい」と主張するのではなく、ビジネス上の価値貢献を軸にして語りましょう。 • 看到有掉球可以試著幫忙撿球，但是需要把撿球的⼈⼒成本公開透明 ボールが落ちているのを⾒たら、拾っちゃっても構いません。ただし、ボール拾いのコストを明確にする必要があります。 • 對所有的任務⽤合理的⽅式化繁為簡 あらゆる業務を、適切かつ合理的な⽅法でシンプルにする。 • ⽤最平鋪直述的語⾔溝通，把需要多加解釋的機會降到最⼩→ 尤其成員都不是⽇⽂/英⽂⺟語者 可能な限りわかりやすい⾔葉でコミュニケーションをを取り、補⾜の必要性をできる限りなくしましょう。特に相⼿はネイティブではない⽅。
37.  參考資料與推薦書⽬ • Start with Why: How Great Leaders Inspire Everyone to Take Action by Simon Sinek • Communication Patterns: A Guide for Developers and Architects. by Jacqueline Read • BCG 問題解決⼒：⼀⽣受⽤的策略顧問思考法 by 徐瑞廷, ⿈菁媺 • Great software design looks underwhelming by Sean Goedecke https://www.seangoedecke.com/great-software-design/ • Everything I know about good system design by Sean Goedecke https://www.seangoedecke.com/good-system-design/ • Prioritizing technical debt: when to rewrite and when to live with it by Dmitry Glazunov https://itnext.io/prioritizing-technical-debt-when-to-rewrite-and-when-to-live-with-it-c98527e59426 • Information Architecture, 4th Edition by Louis Rosenfeld, Peter Morville, Jorge Arango
38.  參考資料與推薦書⽬ • Martin Fowler的企業級軟體架構模式：軟體重構教⽗傳授51個模式，活⽤設計思考與架構決策 Patterns of Enterprise Application Architecture by Martin Fowler, 譯者：陳傳興, 張⽴顗 • 無暇的程式碼系列 - 《Clean Code》《The Clean Coder》 《Clean Architecture》 by Robert C. Martin • OʼREILLY Lean 系列 - 《Running Lean》 《LEAN UX》 《Lean Customer Development》 by Ash Maurya | Jeff Gothelf, Josh Seiden | Cindy Alvarez
39.  Thank you