The most challenge things in your job

這篇一直很想寫，但是一直沒有寫出來。

上個月初的時候去了一趟 WWDC ，這是 Apple 的 Developer 會議，可以遇到來自全世界各地的開發者，還有很多跟 Apple 有關的人，像是設計師，PM，也有很多公司在附近其他場地辦party 找人。主要組成比例大概是：Attendance 5000，Apple Engineer 1000

門票很貴，1599鎂，再加上機票住宿，去一次沒有10萬～15萬是去不了的。為了不要浪費這筆錢，所以會去的人幾乎都是有準備才會去的。

在那邊五天的時間裡面，我最常作的事是跟其他國家的開發者聊天，交換彼此遇到的問題，平常在台灣跑 meetup，會遇到的問題大概都一樣，因為我們遇到的是同一個業界，都是在台灣。

跟國外的人聊天之前，總是會有一種期待，期待對方講初他們是用什麼高大上屌炸天的技術。實際聊過才發現也沒差這麼多， startup 的人，很多人用 Lottie 作動畫，沒做Unit Test 沒做 CI 的人一大堆。有規模的公司，就是那種跨國有聽過名字的公司，一個 app 分成好幾組人，每組又有好多人的，大概10個 developer 寫一個 app 的那種，CI 幾乎都是從 jenkins 改出來的，再配上自己的 script 。人數更多的，就會開始自己寫 tool。

我最喜歡問的問題：What's the most challenge things in your job?

因為每個 developer 作的產品不同、客戶不同、市場不同、公司規模不同。這個問題收到一大堆的答案。

做物流的公司說是 customer service，做企業 app 的公司說是 security ，還沒賺錢的公司說是 adoption 。也問過 Apple Engineer ，大部分人都說是 cross BU communication，似乎技術問題對於 Developer 來說就像是吃飯喝水一樣，每天都在做都沒在害怕的。

搭飛機回來的路上，10幾個小時，我一直在想，如果這個問題問我自己呢？我做過的工作裡面什麼是最難的最重要的？想到兩個

1. 同事離職，交接時間不夠

待過很多家公司，遇過很多同事來來去去，最嚴重的問題一定是同事離職，尤其這位同事負責的東西沒有其他人可以做得像他一樣好、沒有他這麼深入了解。這個時候就是大問題，尤其在位子越高的人發生越嚴重，最知名最極端的例子是 Steve Jobs 離開，（雖然他是非自願的），這麼高職位的人要交接一定都是以年當單位來交接的，不可能兩三個月就交接完，當時要在 Apple 裡面找出另一個 Steve Jobs 是不可能的事。

以我待過接案公司跟新創團隊為例，每個月都在想下個月有沒有辦法活下去。在接案公司的時候，重點是快速接下一個案子，已經接進來的案子要快速結案。這個時候如果接到一個新案，是之前有作過類似的。一般來說就會發生請之前作的那位同事幫忙，如果好死不死，類似的案子一直來，那位同事就在那個領域一直累積經驗值，然後其他人就在作別的事。

有一天這位經驗豐富的同事要離職了，只有一個月作交接要怎麼辦。偏偏那個領域又是需要長期經驗累積的。其實在接案公司一個月算超多了，大部分都只有3 天到一個禮拜。

解法非常困難，牽扯到人性，「放權」。工程技術方面的解法想到幾招，定時開讀書會，換人作 refactor，或者寫 feature 跟 unit test 的時候故意找不同人作，這麼多招式可以用。

但也不一定，如果公司平常事情一堆，連做上面這些事的時間都沒有，也有可能專職負責的同事覺得教其他人不如自己作比較快，其他同事沒有練習的機會。同事離職的時候還是一樣完蛋。

2.待了一陣子，只是把一年經驗變成X年經驗

像我目前待的公司是在作 video streaming 的，在 app 端來說，最重要的是播放影片的技術：像是怎麼跟硬體溝通，加密解密的流程，在 app 既有的 flow 下要怎麼插入其他商業邏輯。

第二層的是每一版 iOS 更新後的新功能，如何跟商業邏輯整合。像是 3D touch 、Universal Link、rich notification。每年都在改版的金流 IAP 應該也算是這塊。

再下一層的話是指每個 app 都會用到的東西，像是刻 UI。這也是最常變動的一塊，有大量的練習機會。

最下面一層的就開始跟本業沒什麼關係，大多是重複性的工作，像是整理多國語系的翻譯、每次出版都 build 一版上傳用的版本、寫 release note 。這就是低附加價值，沒有辦法拿去炫耀的資歷，最好把這邊的事都變成自動化，不要有工程師專職負責這塊。

上面這幾項，是照功能重要性排名，對員工來說不是說越上面就越好，而是應該要盡可能的往其他層發展，如果只會最上面那層 player 的話，雖然在公司可能會是很重要的人，但是這個人未來發展就被局限住了。

待了一陣子，都在做重複的事，這件事對員工來說最傷，或許公司需要有人來專職負責某一塊業務，但是那像業務每次做的事有 90% 一樣，上手後就沒有挑戰性的，這就是非常浪費生命的一份工作，競爭力隨著時間慢慢磨掉了。

解法當然就是勇於跨出舒適圈，盡量跟同事學習其他業務相關的事情。平常如果有互相 cover ，互相交換工作的習慣，那大家彼此進步，就沒問題了。

carthage 踩到雷

寫軟體開發一定會遇到要管理 3rd party module 的時候，在寫 iOS 最常見的幾個工具，像是 cocoapods , carthage 。因為之前用 cocoapods 的經驗不是很好，所以後來在專案導入 module 管理工具的時候使用  carthage。

這篇文章不會講 cocoapods 有哪些缺點，有哪些解法。也不會講為什麼要選擇 carthage ，不會講 cathage 要怎麼安裝。只會講這次遇到的問題。

目前維護的案子大概寫了兩年，幾乎都是用 swift 寫的，目前是 swift 3.0，不是自己寫的 module 大概小於 10 個，之前有寫一篇怎麼挑選 3rd party module 。

carthage 原本只有用來管理 objC 的 module ，雖然也是有一些 swift 的 module ，但是那些 swift module 都小小的，compile time 增加不多，所以之前都直接把 source code 放進來，都不用 framework。

上個禮拜有個需求，考慮加入一個 swift module，底層又包了一個 C library ，零零總總加起來蠻大包的。所以直覺就是要包成 swift framework 包進來。

現在這個時間 7 月中，iOS 11 也出到 beta 3 了，所以開始看看 iOS 11 有哪些問題要解，要用 xcode 9，使用 xcode 9 compile 的時候 ，swift 版本會變成 swift 3.2 ，就獲得這個 build error。

意思是 app 是用 swift 3.2 ，但是 framework 是用 swift 3.0 ，所以這樣不行喔。覺得這應該是 swift 自己的問題，為什麼 objC 寫好幾年了，都沒有版本不合的問題。

平常還是有固定出版時間，還是必須要用 xcode 8，還是要用 swift 3 ，也就是不能直接換成 3.2。這個問題也只有每次 iOS 升級前解 bug 的時候會遇到。

想一想這問題大概有幾個解法：

1. 放棄那個 swift module，用 objC 改寫
2. 開兩個 branch ，一個是 swift 3.0 平常出版用的，一個是 swift 3.2 + iOS 11 修 bug 用的
3. 等 iOS 11 上線，全部工作機都換成 xcode 9  以後再來做。

我選 3

WWDC 攻略

上禮拜中午與剛從WWDC回來的KKBOX iOS team 同事zonble 吃飯，zonble去了非常多年，這次每天在WWDC每天都會寫1000 2000字的工作報告，所有同事都驚呆了。所以就問zonble一些去WWDC 應該要做的事：

首先，公司花錢讓你去研討會，你必須要證明公司這筆錢花得有意義，像是WWDC的門票加機票住宿，一個人大概要花費10萬到15萬，過去conference 是去工作的，不是去玩的。去WWDC 大概是為了這三個目的

解決相容性問題

寫Apple 產品很重要的是，Apple 使用者升級速度超級快，不像Android 出個新版本可能四年後才會變成主要版本，6月中WWDC 發布測試版，9月就一定會上線，大概到了10月，有一半以上的使用者就會升到最新版本了。所以解決新系統跟現有app的相容性問題是在WWDC最重要的任務。

解掉workaround

另一個寫Apple 產品麻煩的地方是，除了WWDC沒有任何管道可以直接面對Apple的工程師，雖然每個開發帳號都可以有兩個Technical Support 問題可以問，但是一般都不會獲得完整的回答，只會告訴你要往哪個方向去找資料。所以當你有一些困擾很久開發上的問題，在lab的Apple工程師一般都是那個領域的作者，可以省去寫信來來去去的時間，跑lab可以一直問一直問。當然也要你對於這個領域夠瞭解才有辦法一直問一直問，如果有一些舊的workaround是跟apple有關的話，這是一個解決的好時機。

對現有產品的衝擊

快速了解新功能對現有產品的影響，這分成兩類：一個是舊功能的加強，一個是新功能的串接。舊功能來說，像這幾年常改的IAP policy，去年增加了family share，今年修改了autoreable 的分潤機制，身為工程師必須要去了解這些東西在IAP sandbox下要怎麼測試。

至於新功能，如果可以的話，寫個demo吧。
像是去年iOS出了Spotlight search 跟3D touch，就是兩個很好的例子，只要接個新api，馬上就可以整合到現有產品裡，讓規劃產品方向的同事實際體驗看看。

時間規劃

這兩年WWDC的session 隔天就會上網，所以去WWDC 最重要的目的就變成跑lab，而不是看session。WWDC是個五天的conference ，重要的時間表攻略如下：

第一天：上午keynote，沒什麼好說的，就是宗教傳道大會，大家都會看，感受氣氛一下就好，就算你不看別人也會寫好文章重點摘錄。

下午的第一場是developer 的keynote，Session 102 State of Union，超重要，一定要看，
沒有華麗的數字，大部分都是demo，身為工程師絕大部分是接下來你會面對到的東西。
再來就是重點了，接下來的session是Apple Design Award ，看不看無所謂，這個時間會開始開放下載新的Xcode跟iOS，記得要去高速上網區把Xcode跟iOS下載下來，然後裝到測試機裡面看看app有沒有什麼問題，一般來說都會有問題，這個時候就要根據不同的錯誤訊息來決定接下來幾天要去跑哪些lab。

這一天的重點是制定戰略，至少要準備兩台測試機，一台裝舊OS ，一台裝beta OS，跑看看產品app。

第二天：
記得去買紀念T-Shirt ，慣例第二天就會賣完 :)

第二天到第五天都差不多，動態調整吧：
第二天開始就會有session 跟lab了，lab的時間有個習慣是，重要的lab會重複出現兩次，，像是Cocoa Touch 這種UI系列的就會一直出現。所以第一次沒有時間去跑lab的話，第二次一定要去。

session 的重要性不高，但也要去聽，尤其是去的人有超過兩個人時候，每個人的任務分配就很重要了，基本上是聽跟自己產品有關的。

首先KKBOX 是個audio streaming app，所以Audio 有什麼改版一定要去聽，有用到IAP 的話，IAP有什麼改版一定要去聽。然後因為video team 完全沒派人去，所以也要去聽Video 相關的session（我就是video team的，聽到這句話的時候真不好意思）

這邊有一個插曲是，今年apple 推出了offline HLS，keynote完全沒有提到，但是這對video team來說非常重要，所以我們在台灣的同事就快速看一下sample code，整理出幾個問題讓現場的同事去幫忙詢問。當天在lab回答問題的剛好是HLS的作者Roger Pantos，運氣有夠好。

跑完session 跟lab，結束一天的行程後，每天晚上7 8點回到飯店，大概也就是台灣時間10點，跟台灣同事con-call確認一切正常互相報工作進度，然後開始寫工作報告，寫完上傳。

心態

以下是我聽來的，有一個已經離職去yahoo的前iOS team的同事，在研替三年期間去了兩次WWDC。他說他當年很弱，所以晚上在飯店的時候，主管為了要激發他的鬥志，指著他的頭問：
「你知道你為什麼會在這邊嗎？」「你知道讓你過來公司要花多少錢嗎？」「你知道你來這一趟至少要創造多少價值嗎？」

然後研替結束過沒多久他就離職了 （默）

zonble 在講他去WWDC 過程的時候，很明顯一直強調心態很重要，去那邊不是去玩的，是去解決問題的，是去創造價值的。要調整心態的方法我想上面幾行那幾個問題應該去參加國外conference的人都應該好好想一想。