你有沒有遇過這種狀況：新人第二天就被丟一張 ticket，然後你心裡其實知道——他不是不努力，他只是連「要從哪裡開 PR」都還沒搞懂。
先講結論：兩週的 iOS onboarding，其實是在買「少踩雷」
inDrive 的做法是用一個獨立 repo 的迷你 iOS app，跑一套為期兩週的 onboarding，讓新人在進產品前就練過 inClean、UDF、XCoordinator、Nivelir、公司 code style、PR 規則與測試流程，並且每次任務都開 pull request 接受 buddy 與 iOS Community Lead review。
- 新人不是「看文件」，是「做任務 → 開 PR → 被 review → 修到過」
- 用獨立 repo 隔離風險：練手不會把 production 弄髒
- 兩種架構 + 兩套導航先吃透，不然進去會迷路
- 把 code style、network layer、analytics、design system 變成肌肉記憶
- 兩週後第一個產品 PR，至少不會被 review 打成蜂窩
沒系統的 onboarding 會發生什麼事？通常不是「慢」，是「亂」
當新人直接跳進大型 iOS 專案、而且還是 UDF（unidirectional data flow）那種事件會到處噴的架構時，最常見的結果是：debug 追一個 event，要翻十幾段 code，依賴關係不明顯，文件又沒有，最後只能靠「問人」或「猜」。
我比較在意的點：不是新人學不會，是團隊成本會被拉爆。review comment 變多、反覆修改變長、有人開始不耐煩，然後 bug 就會趁縫鑽進 production。很常見。真的。
更尷尬的是，原文提到「每個 team 都用自己的方式實作 UDF」。這句話我看到會皺眉。
因為這代表你不是在 onboarding 一個架構，你是在 onboarding 一堆「口味」。而口味這種東西，你要新人兩週內懂？很硬。
他們的解法：兩週、獨立 repo、用迷你 app 模擬 production 的核心流程
這套 onboarding 的核心設計很直白：把新人要學的東西塞進一個「小但完整」的 iOS app repo，讓他在兩週內依序碰到架構、導航、網路層、分析埋點、design system、測試與 PR 流程，最後再回到產品 repo 才開始真正的 product task。
兩週內容包含（原文白名單我照留）：
- 兩種架構：inClean、UDF
- 兩套導航框架：XCoordinator、Nivelir
- Networking 與 analytics
- 公司 code style
- Design system 整合
- Pull request 規則（含怎樣才算「好開、好 review」）
- 測試怎麼寫（至少知道你們要什麼）
每個主題不是上課聽完就算，是給你任務。
做完要開 PR。
然後會被 review。
被 buddy 跟 iOS Community Lead 一起看。這點其實蠻關鍵：buddy 忙起來是常態，但 Community Lead 這個角色會把 review 的品質撐住，不然 onboarding 很容易「看心情」。
把帳算清楚：公司表面「少兩週產出」，實際是省掉一堆 review 與 bug 成本
兩週 onboarding 看起來像是公司在「燒時間」，但 inDrive 的論點很務實：不做 onboarding，新人可能會花幾週到幾個月在亂撞，團隊還要付出 review 負擔、修改往返、甚至 production bug 的代價，最後 release 變慢、錢也會漏。
這裡我會用更冷一點的指標看：你要的是「第一個產品 PR 的可預測性」。兩週後新人開第一個產品 PR，至少知道你們怎麼走流程、怎麼切架構邊界、怎麼寫測試、怎麼用 design system。這不是讓他變大神，是讓他不要亂開槍。
| Pros（你會得到什麼） | Cons（你要付出什麼） |
|---|---|
| 新人更快進入「能被 review」的狀態，第一個產品 PR 不會全是基本錯誤 | 短期少兩週人力輸出，排程要先吞一下 |
| 減少因架構誤解造成的 production bug（原文直接點名這種 bug 會下降） | 你需要有人願意當 buddy，還要有人扛 Community Lead 的 review 量 |
| 流程與 code style 被「實作化」，不是靠口耳相傳 | onboarding repo 需要維護，不然很快跟主專案脫節 |
| 變相做候選人評估：兩週還跟不上，訊號很清楚 | 有些人會覺得壓力大（尤其一直被 review），心理安全要顧 |
| 每次收 feedback，讓 onboarding 變成持續更新的系統，而不是一次性教材 | 要有紀律去改，不然 feedback 只會變成表單堆積 |
先把專案怎麼長、骨架怎麼走看懂，再進產品做 task。這順序看似慢，實際上更快。
規模結果：2024/02/07 上線後，30+ 人走完、開了快 500 個 PR
他們的 onboarding 在 2024 年 2 月 7 日啟動，到現在已有超過 30 位開發者完成，並且在 onboarding repo 裡開了將近 500 個 pull request。這種量級代表一件事：不是做做樣子，是有真的在跑流程、真的在 review。
我會挑毛病的地方也在這：500 個 PR 的 review 品質如果不穩，整套就會崩成「形式」。所以原文提到 iOS Community Lead 的角色，我是買單的，因為它在組織上把「一致性」拉回來。
題外話，講到一致性我就想到另一種常見翻車：你以為 onboarding 是教新人，結果其實是在逼團隊把自己的混亂講清楚。
有點殘忍。
但有效。
分眾決策：如果你是這種團隊／新人，該怎麼用「兩週制」不翻車
兩週 onboarding 聽起來漂亮，但你要的是「能落地」。我用 If This Then That 方式講，比較像群組裡真的會用的那種判斷。
如果你是高速迭代的產品團隊（永遠缺人、永遠在趕）：那就把 onboarding repo 做到「能自動跑起來」，CI、lint、基本測試先備好，不然你會一直被新人卡住。別幻想靠口頭帶就好，最後都會回來咬你。
如果你是多架構並存（像原文：inClean + UDF，還有兩套導航）：那 onboarding 的任務要刻意設計「同一個功能用兩種做法各寫一次」，讓新人看到 trade-off，不然他只會背 API 名稱，進產品照樣迷路。
如果你是夜班／跨時區協作（review 可能隔天才回）：就別把 onboarding 完全綁在同步 review 上，改成「固定 review 時段 + 非同步 checklist」。不然新人會在等待中焦慮，然後開始亂改，越改越糟。
如果你是新人本人，而且你很怕被 review 打爆：先把 PR 切小，真的。小到你覺得不好意思那種大小。因為 review 不是審判，是把你對齊團隊習慣的最快方式——前提是 reviewer 願意講人話。
如果你是帶人的那個 buddy（同時還要扛 feature）：把「你一定要盯的點」寫成短 checklist：code style、架構邊界、測試最低標準、命名、PR 描述。其他的先放過。你不需要在 onboarding 把新人雕成藝術品。
兩週 onboarding 不是 HR 的儀式，是把「團隊規則」變成可以被練習、被 review、被複製的流程。
小小的在地吐槽（台灣團隊常見）：很多公司會把 onboarding 寫成一堆 Notion 頁面，然後新人看完還是不敢動 repo。因為他怕弄壞、怕被罵、怕問了顯得笨。
這種怕，其實很貴。
順帶一提，如果你的公司有在走資安或合規（哪怕只是基本的權限控管），兩週制 onboarding 用「獨立 repo」也比較好處理權限：新人先在隔離環境把流程跑熟，再開到產品 repo 的權限。這個做法在稽核上也比較好解釋。
收尾給一個資源關鍵字（你自己去搜就好）：「iOS pull request checklist」。
你找到一份順眼的，貼進你們 repo 的 PR template，然後開始要求自己也照做。先從自己開始比較不尷尬 😅
