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