Dcard 的 iOS 團隊在做什麼？
Hello 大家好，我是 Dcard 的 iOS 工程師 Daidouji，目前在這邊 3 年多。以我自身的角度分享一些平常在做的事情，讓大家對於我們的日常可以有更進一步的了解 : )
身份的組成
身為一位工程師，在 Dcard 通常會隸屬兩個單位，一個是你本來的職能，像我屬於 iOS team，另外是一個把功能開發出來的 Delivery team。比重分配上，在 Delivery team 裡面的時間會比較多一些。
這邊就先從我們 Delivery team 的風格開始說起。
Delivery team
我們會在每天早上大概花半個小時，討論一下手上在做的事情。一個 Delivery team 中有：
- PM 1–2
- UI / UX 設計師 x 1
- iOS x 1
- Android x 1
- Web Frontend x 1
- Backend x 1
- 如果有 BI 或是 Data 需求時，有可能會加入討論
必須要說的是，在 Dcard 工程師可以高度參與需求調整的細節。
Pre launch meeting
PM 會把規劃好的第一手需求提出來，並讓其他成員了解。
身為工程師除了可行性的評估之外，通常還會想知道 PM 要做這件事情的理由是什麼，以及最終想要達成的目的。從這個出發點再回頭去思考，需求會不會有不周全的地方，或是怎麼樣我們可能可以讓這個需求變得更好。
會後，再跟 iOS team 的其他夥伴討論一下這次要做的東西，看看大家有沒有什麼其他的想法或需要顧慮的點。大家有了初步的共識之後，PM 會與設計師共同規劃出畫面的細節與流程。
這邊有一個蠻重要的技能是 溝通。在面對各職能不同的夥伴們，我們需要考慮怎麼在互相可以理解的基礎上，討論出一個共有的結論。
Launch meeting
到了這邊，PM 與設計師應該已經順過一次整個需求的流程，並且把畫面的細節都長出來了。
在這個會議上，我們可以有更完整的想像。比如說在某個畫面可能會需要某些 API，某些頁面的跳轉可能可以怎麼實現，討論細部的實作，以及各平台互相確認是不是有什麼缺少的東西，可以趕快提出來。
一是互相幫助，二是看需求能不能有小幅度的調整，PM 會希望在這個階段大家可以粗估一個工作的時間，方便時間控管。 這邊我覺得各自都給了很大的彈性，因為即使是很資深的工程師，也會有估時不精準的時候，所以只要不是在最後一天，我們把自己遇到的難點提出來，「每一個人」都會盡他的能力幫助你，這是我覺得 Dcard 的一種文化，也是一種很正向的能量。
開發過程
在這個階段，除了每天早上的 sync，基本上不會被其他事情打擾。
sync 的內容可能會包含和 PM 再確認需求細節，跟設計師討論設計稿，跟後端確認 api 的細項，三平台互相討論一下實作 (iOS / Android / Web) 等。除此之外，只要時間允許，我們也都會很積極的參與討論交流意見，並應用在專案上。
UI Day
開發接近尾聲了，我們會需要驗過大部分的功能，讓 PM 確認需求是不是都有達成，讓設計師驗過一次畫面是不是有跟設計稿不相符的部分。都完成後，工作算是告一個段落，我們需要將新的需求 merge 到 code base 裡面，期待下一次的發佈。
iOS Team
Code review 的流程
目前我們有六位 iOS 工程師。
我想應該跟大部分的公司一樣，新功能要進入 code base 時都必須要先開一個 pull request，需要有除了自己以外的兩位成員幫忙 review 過後，新功能才會被 approve。由於不是每位成員都彼此熟悉對方正在實作的內容跟區塊，因此我們希望在 PR 的描述中，盡量可以讓別人容易理解。
同時夥伴們會互相熱情的給予建議，進而互相學習與調整出更容易讓人理解的寫法。
有些共用元件沒有用過可能會不知道，大家會互相幫助檢查，盡量讓 code 可以被重複利用。
CI / CD 的演進
最初的時候我們用的是 iMac Pro 來架 jenkins，配合 fastlane 的使用。他可以做到驗證 pr build / lint / testing 正確，以及上架 app store 的功能，但由於我們人數越來越多，需要他做的事也變多，加上自家沒有專屬的人維護 jenkins 的正常運作，導致我們常常花很多時間在修理 jenkins、iOS Simulator、Xcode，或是 iMac 的各種 bug。
在最近我們整個遷徙到了 Bitrise 上面，目前使用上並沒有太讓我們覺得困擾的地方，除了原先舊有的功能之外，我們想解決一個一直困擾我們的痛點。
不知道各位有沒有過這種經驗，假設在開發 A branch 的時候，其他夥伴希望可以幫忙 build 一個 B branch 功能的版本，在過去 Intel 的電腦上，我們的專案 build 一次大約需要 200–300 秒的時間，這意味著，工作不但會被打斷，還可能要花大概 10 分鐘在一件小小的事情上面，所以我們優化了這個部分。
現在可以透過兩種管道，自動化的利用 Bitrise 幫我們 build 出可以提供給團隊夥伴安裝 ipa 安裝連結，一是從 pull request 的 comment，另一個是 slack bot。
順帶一提，你曾經也因為要整理內部的新版本 release note 而感到煩惱嗎？在這個部分我們讓 PM 在 Clickup 上開 task，task 會對應到一個 pull request 中，在版本發佈的同時，自動化的產出一份列表，並通知相對應的人。
在 Dcard 的生活裡面，我們會捲起袖子，直接去改變困擾我們的事物，優化整個開發跟生活的體驗。
學習與成長
大概可以分成兩個部分來說：
- 公司高度鼓勵學習，每兩週一次的讀書會，會議中我們會討論最近遇到的問題，整份 code 是不是有需要調整的方向，大家在這兩個禮拜學到的東西，互相拿出來做分享。
- 我們把一年分成 6 個 S，每兩個 S 會有一個禮拜的時間。在這個禮拜裡，可以不用管 Delivery Team 的事，讓你去做想做的研究，開發 Dcard app 內可以用的元件，看 WWDC 學新的東西，優化各種開發流程開發體驗等等，只要是對團隊有益處的都可以。在 OKR 結束後，花點時間讓其他夥伴也可以共同成長。
Dcard 整體方向在做什麼？
以現階段來說，我們的功能可以區分成這幾個大類：
- 讀者端：像是在優化使用者閱讀列表的視覺和操作體驗，更容易的利用話題找到喜歡的文章。
- 作者端：幫助使用者們更容易的分享內容，選擇適當的話題，讓別人更容易可以找到你的文章，進而產生的創作者計畫，讓使用者可以擁有自己經營的看板，鼓勵優質的文章產生。
- 廣告：包括 Dcard 的廣告平台開發，聯播網廣告的串接，並且合宜的呈現在使用者面前，優質內容的文章如何曝光給可能感興趣的客群。
- 電商：慢慢的從在非原生的網頁裡面購買，一步一步改成現在的全原生的瀏覽到購買體驗，數次的測試與調整，讓使用者在觀看商品時，即使不買純粹逛逛，都可以有很好的閱讀體驗。
- Global：目前我們有在香港跟日本做推廣，相應而來的就會有需要適應該地區相對應的功能，多國語系的調整。
- Growth：以各種實驗嘗試提升成效，比如優化註冊的流程，新註冊用戶體驗 7 天完整功能的實驗。
所以實際上 Dcard 並不會步調很慢，而是會有蜂擁而來的需求等著被開發，也不需要擔心加入後會被定型在一個固定的組別，基本上工作內容時常會有重疊，或是互相輪替的部分。
最後
很謝謝你可以耐心的看到這邊，不知道整個描述下來，是不是有讓你對 Dcard iOS 工程師這個工作感到興趣了呢？目前我們還有缺人喔，很期待可以看到有新的履歷向我們丟過來 : )
透露幾個部分好了：
- 在過去的經驗裡面，我們會希望你是一個可以有良好溝通能力的人。從上面的描述裡面，會有很多很多很多時候，我們都在溝通，包括對組內、對 PM、對設計師、三平台的前端、後端，無時無刻都是在溝通。勇於說出你的意見，表達你基於這個意見的想法、對於產品的想法很重要。
- Dcard iOS 這邊其實並沒有用很多第三方的套件，我們比較傾向可以自主開發出適用的元件或是架構。原因是覺得了解實際運作的原理，跟直接使用一個包裝的很完美但是不曉得怎麼運作的套件，對於一個需要長期維護的產品來說，前者我們相對看重。
- 希望你是一個樂觀的人，Dcard 是一個每天都有非常多人在使用的 app，如果有些地方沒有注意，產生了讓使用者功能異常，或是大量的 crash，很快的都會被 Crashlytics 或是使用者抓到。我們不會責怪一個 bug 的產生，只有不產生 code 的人才不會有 bug : ) 遇到問題的時候，能有積極的心態來處理就夠惹！
——
對於加入 Dcard 感興趣的話，歡迎跟我們聊聊！
Senior iOS Developer ▶️ https://grnh.se/8a7c32081us
