半年前我加入一個(gè)剛剛拿到 A 輪資金的創(chuàng)業(yè)團(tuán)隊(duì)負(fù)責(zé) iOS 項(xiàng)目。早期的時(shí)候公司生死未卜，只追求快速迭代找到一個(gè)正確的方向。這種早期默默無聞的團(tuán)隊(duì)也沒什么工程追求，就是寫的快就好了。但是確定方向后要長期發(fā)展，就不能再野蠻生長了。

基于過去半年我在這個(gè)項(xiàng)目里的實(shí)踐經(jīng)驗(yàn)，和大家分享一下。

代碼托管：自建 Gitlab

早期草根團(tuán)隊(duì)最省事的就是用 GitHub 了。但是團(tuán)隊(duì)人數(shù)增加后用 GitHub 的成本就很高了。普通的團(tuán)隊(duì)套餐每個(gè)月每人 9 刀。另外一個(gè)問題就是 GitHub 部署在國外，國內(nèi)訪問網(wǎng)絡(luò)時(shí)常不穩(wěn)定。聽聞某跨國團(tuán)隊(duì)代碼托管在 GitHub 上，某次重要會(huì)議期間 GitHub 無法正常訪問。真是突如其來的父愛如山。另外一個(gè)缺點(diǎn)就是服務(wù)端如果要自己配置 CI 服務(wù)不太方便。如果部署在自己的服務(wù)器上，其他一些服務(wù)腳本也部署在一起，會(huì)有很大的自主權(quán)。綜合之后選擇了主流的 Gitlab。

工程師的時(shí)間比機(jī)器貴

很多短視的團(tuán)隊(duì)覺得配給工程師的設(shè)備太貴，挑個(gè)便宜點(diǎn)的就好了。一臺好的電腦雖然貴點(diǎn)，可是長期下來節(jié)省下來的工程師的編譯時(shí)間比機(jī)器貴多了。在設(shè)備上我跟公司建議那就配最新的 15 寸的 rmbp 唄，再來一個(gè) dell 4K 顯示器唄。后面發(fā)現(xiàn)鍵盤鼠標(biāo)也重要啊，每個(gè)人又補(bǔ)貼了 500 塊的鍵鼠額度。看到很多工程師還在用 air 開發(fā)，還有 mac mini 的。真的為這種傻逼公司感到心痛。我曾經(jīng)在的某團(tuán)隊(duì)還是 4 個(gè)終端用同一臺電腦。每次編譯的時(shí)候我就到南京路散個(gè)步。如果晚上要上線，可以去看個(gè)電影回來。

盡早招人

招人是團(tuán)隊(duì)發(fā)展過程中非常重要的一環(huán)。很多早期團(tuán)隊(duì)都低估了招人的難度和周期。因?yàn)椴惶膱F(tuán)隊(duì)招人有兩個(gè)缺點(diǎn)：

不能給出太高的薪水

優(yōu)秀的人才當(dāng)然會(huì)比較市場上薪水。已經(jīng)成名已久的 BAT 這種公司自然會(huì)有薪水的優(yōu)勢。創(chuàng)業(yè)公司雖然有期權(quán)，但是畢竟公司前途未卜。很多工程師也擔(dān)心公司會(huì)不會(huì)過陣子就倒閉的問題。

團(tuán)隊(duì)事情多且雜

項(xiàng)目成熟后的迭代大多是按部就班，有穩(wěn)定的節(jié)奏。每個(gè)環(huán)節(jié)的都有很細(xì)分的專職人員。早期的項(xiàng)目因?yàn)轫?xiàng)目還是處于成長階段，很可能半路做著看到直播火了，我們加個(gè)直播的需求。或者做著做著發(fā)現(xiàn)競品有個(gè)功能，管不了那么多我們下個(gè)版本就上。或者 CEO 路過的時(shí)候突然有了個(gè)想法，上線的時(shí)間又推后一下。

招人除了技術(shù)的硬指標(biāo)，在早期團(tuán)隊(duì)還有一個(gè)工程團(tuán)隊(duì)文化的問題。一個(gè)幾十個(gè)人的項(xiàng)目，里面某個(gè)特定的人的積極性對于項(xiàng)目其實(shí)是不太重要的。他只要完成應(yīng)該完成的工作。甚至和其他人不說話也影響不大。一個(gè)大的項(xiàng)目也不能因?yàn)槿魏我粋€(gè)人不在了就運(yùn)行不下去。

但是早期團(tuán)隊(duì)，人就這么幾個(gè)。有一個(gè)人對團(tuán)隊(duì)的使命認(rèn)知不一致，日常行為里就會(huì)有很多摩擦。

我之前思考過團(tuán)隊(duì)文化是什么，怎么形容團(tuán)隊(duì)文化。后來看到一個(gè)說法感覺挺貼切。文化是空氣，無處不在。公司沒有規(guī)定下班后社交平臺上看到用戶反饋需要你去回應(yīng)，也不會(huì)規(guī)定你發(fā)現(xiàn)其他部門的產(chǎn)品有問題是不當(dāng)回事還是應(yīng)該去和其他部門的人溝通，又或者看到一個(gè)更好的建議是不是要和公司提出來。這些行為背后的支撐就是團(tuán)隊(duì)文化。在團(tuán)隊(duì)里的人決定了價(jià)值觀。

綜合上面說的，招到一個(gè)匹配的技術(shù)人員，運(yùn)氣好的話幾天就你能遇到，更常見的情況是可能要好幾周的時(shí)間。當(dāng)然如果情急之下招進(jìn)來一個(gè)人，干了幾個(gè)月后發(fā)現(xiàn)不合適就走了，對于團(tuán)隊(duì)的士氣損害也挺大的。

所以考慮到項(xiàng)目未來的進(jìn)展，要及時(shí)啟動(dòng)招人的計(jì)劃。當(dāng)你發(fā)現(xiàn)進(jìn)度忙不過來的時(shí)候開始招人，這個(gè)時(shí)候你要抽時(shí)間去準(zhǔn)備面試的事情，還要兼顧項(xiàng)目進(jìn)度，會(huì)很焦頭爛額。

轉(zhuǎn)型 Swift

團(tuán)隊(duì)里的另外 3 個(gè)同事之前都沒有寫 Swift 的經(jīng)驗(yàn)。但是考慮到未來的發(fā)展趨勢，并且我們的業(yè)務(wù)類型對動(dòng)態(tài)化的要求沒那么強(qiáng)。我堅(jiān)持在團(tuán)隊(duì)里推行使用 Swift 編程。

我經(jīng)常被問到的一個(gè)問題是你想用 Swift 但是團(tuán)隊(duì)里其他人不會(huì)用，會(huì)不會(huì)給項(xiàng)目推進(jìn)帶來困難。其實(shí)如果團(tuán)隊(duì)里有人正確的引導(dǎo)，幫他們解決上手過程中的問題，再給一段時(shí)間過渡。很快他們就會(huì)退不回去。

下面介紹一下我把從 OC 遷移到 Swift 的過程。

先用 Swift 寫好網(wǎng)絡(luò)層的庫。借著把常用的幾個(gè) OC Model 和 Swift 對象做好橋接。類似下面這樣：

class SwiftUser {  
init(ocUser: OCUser) {  
}  
func convertOCUser() {  
}  
} 

這樣改造之后如果一個(gè)新的模塊就可以完全用 Swift 編寫。一開始肯定是用 OC 的思維寫 Swift 的代碼。但是在熟悉了 Swift 語法后可以慢慢在 review 過程中提出可以用更 Swift 的寫法。有些功能需要 OC 和 Swift 互相調(diào)用確實(shí)挺麻煩。如果讓一個(gè)沒 Swift 經(jīng)驗(yàn)的上手就解決這些問題一定很氣餒。所以在項(xiàng)目過程中也要分配一定時(shí)間把老的 OC 代碼重寫了。好在原先的代碼本來就很亂，需要重寫。這樣就隨著業(yè)務(wù)推進(jìn)中，Swift 比例越來越高。

這樣經(jīng)過一兩個(gè)月后大家就慢慢熟悉了 Swift ，此時(shí)再去推進(jìn) RxSwift 等框架的使用。

理順開發(fā)工作流

項(xiàng)目早期的時(shí)候需求千千萬，一個(gè)迭代版本中應(yīng)該開發(fā)多少功能呢?產(chǎn)品經(jīng)理本能的就是靠拍腦袋。列了一頁需求后表示這就是這個(gè)版本了。程序員都傾向于樂觀估時(shí)間，做著做著半個(gè)月過去了。下個(gè)迭代的需求、UI 設(shè)計(jì)，交付前測試的工作都很混亂。

后來經(jīng)過討論確定了兩周一個(gè)迭代周期。開發(fā)過程中發(fā)現(xiàn)某個(gè)需求這個(gè)迭代里無法完成就挪到了下個(gè)迭代中。每個(gè)周期階段要做什么大家都很明確。兩周左右發(fā)布參考用戶反饋也是一個(gè)比較好的節(jié)奏。

這里要強(qiáng)調(diào)的是開發(fā)過程前期的準(zhǔn)備工作。主要指需求和 UI 圖。大多數(shù)的需求設(shè)計(jì)都是圍繞某個(gè)需求展開，但是這個(gè)需求要融入到現(xiàn)有體系里是有很多周邊的工作要做的。比如產(chǎn)品提出用戶資料里應(yīng)該可以打標(biāo)簽。于是畫了一個(gè)草圖里有標(biāo)簽。對于他可能這個(gè)需求描述的很明確了，但是真正落地的時(shí)候就有其他工作要做。比如標(biāo)簽怎么刪除?標(biāo)簽有字?jǐn)?shù)限制嗎?標(biāo)簽重復(fù)了怎么辦?這些問題如果前期設(shè)計(jì)的時(shí)候產(chǎn)品沒有表達(dá)清楚，就只能在開發(fā)的過程中來回溝通。有一個(gè)經(jīng)驗(yàn)豐富的開發(fā)者在前期就參與需求的討論，和提出問題對于在后期開發(fā)有很大的幫助。

不用 Sketch 的設(shè)計(jì)師不是好設(shè)計(jì)師

我看到很多設(shè)計(jì)師沿用傳統(tǒng)，一直使用 PS 。然而實(shí)際上業(yè)界使用矢量設(shè)計(jì)工具 Skecth 已經(jīng)很普遍了。現(xiàn)在手機(jī)的屏幕尺寸更異，如果設(shè)計(jì)的時(shí)候不是矢量圖，而是位圖，做響應(yīng)式的布局設(shè)計(jì)就會(huì)很不方便。實(shí)際上移動(dòng)的 UI 設(shè)計(jì)如果用慣 Sketch ，絕對是生產(chǎn)力的極大提升。

但是和大多數(shù)人一樣，很多設(shè)計(jì)師都會(huì)覺得 PS 用的也挺順手的，Sketch 沒用過。其實(shí) leader 是有義務(wù)去推動(dòng)一些人，讓美好發(fā)生。

之前我在的團(tuán)隊(duì)我就一直不斷暗示不厲害的設(shè)計(jì)師才用 PS ，后來刺激了幾周后他說他現(xiàn)在也可以用 Sketch ，后來慢慢項(xiàng)目 symbol 都湊齊了 PS 他也退不回去了。

當(dāng)然也有非常老派的設(shè)計(jì)師，這種只能給他壓力讓他去被動(dòng)改變。當(dāng)時(shí)我們團(tuán)隊(duì)有一個(gè)四十多高齡設(shè)計(jì)師，我們也很為難。我當(dāng)時(shí)想那算了，下個(gè)月如果你不能用 Sketch 出圖就自己準(zhǔn)備換個(gè)工作吧。當(dāng)然作為一個(gè)團(tuán)隊(duì)也不能給個(gè)指示就甩手不管了。中間已經(jīng)熟練使用 Sketch 的設(shè)計(jì)師會(huì)特別關(guān)注他的學(xué)習(xí)狀態(tài)，及時(shí)指導(dǎo)。最后也得到了一個(gè)好的結(jié)果，他在被迫改變后發(fā)現(xiàn) Sketch 確實(shí)更好用。

這里還有安利一個(gè)很好用的輸出設(shè)計(jì)圖的軟件：zeplin。設(shè)計(jì)圖直接采用標(biāo)注的方式會(huì)很死板。程序員在查看過程中可以自己查看到設(shè)計(jì)圖的所有源信息效率會(huì)得到極大的提升。

接入 CI

很多團(tuán)隊(duì)改變代碼里的宏來區(qū)別 app 里的環(huán)境，每次提交前改下宏。常在河邊走，哪能不濕鞋。我還真遇到過提交 App Store 的時(shí)

候，有人忘記改環(huán)境的宏，app 連接到的是測試環(huán)境。這里想說的不是發(fā)布前要仔細(xì)檢查，而是這種情況就不應(yīng)該發(fā)生。

實(shí)際上通過 Xcode 打包手動(dòng)提交也是一個(gè)充滿風(fēng)險(xiǎn)的過程。因?yàn)椴粫r(shí)會(huì)出現(xiàn)本地改了幾行代碼，提交的時(shí)候把本地的代碼也提交了。帶來了未知的風(fēng)險(xiǎn)。

我通過配置 Xcode 里的 scheme、target 來區(qū)分環(huán)境。利用 fastlane 來完成自動(dòng)打包上傳的工作。結(jié)合 Gitlab 的 CI ，配置了 Gitlab runner，從此打包只需要點(diǎn)擊一下按鈕。降低了發(fā)布的人工操作風(fēng)險(xiǎn)。

我們的組件是用 cocoapods 管理依賴的。配置了 Gitlab runner 后，組件的版本更新也放在遠(yuǎn)端工作，不再基于本地。配置了 webhook 后，每次 job 完成后 slack 的 channel 里大家都會(huì)收到消息。

用好 Testflight，注重 beta 反饋

早期業(yè)務(wù)變化頻繁，沒有自動(dòng)化測試，只能靠人工測試保證穩(wěn)定。一開始團(tuán)隊(duì)選擇了發(fā)布企業(yè)版的包來測試。當(dāng)然企業(yè)版用戶可以方便的下載安裝，但是也有不少缺點(diǎn)。最大的缺點(diǎn)就是這個(gè)包和 App Store 的包是兩個(gè)包，不一樣的 bundle id 。會(huì)導(dǎo)致一些跟包綁定的功能無法正常測試，比如微信登錄、支付后的跳轉(zhuǎn)。

我們的業(yè)務(wù)里有聊天的功能，聊天記錄是只存在本地的。而且我們認(rèn)為一個(gè)賬號只能在同一個(gè)平臺上的一臺設(shè)備登錄。這就導(dǎo)致用戶測試的時(shí)候賬號會(huì)從 App Store 版本登出，這樣聊天記錄就沒了。熱心用戶愿意試用我們的 beta 版，但是也承擔(dān)了不該有的代價(jià)。基于這點(diǎn)考慮在我的主導(dǎo)下我們放棄了發(fā)布企業(yè)版的包測試的方式。而是改用利用 testflight 測試。

Testflight 有個(gè)較大的使用門檻，需要收集用戶的郵箱，之后在 testflight 里輸入蘋果發(fā)出的邀請碼才能開始測試。很多用戶嫌麻煩就退出了，運(yùn)營認(rèn)為這樣會(huì)給測試帶來很大的不便。但是冷靜了心態(tài)后其實(shí)事情并沒有那么糟糕。真正對這個(gè)產(chǎn)品有興趣的用戶不會(huì)因?yàn)橐顐€(gè)郵箱就放棄了。那些流失的只是普通的用戶。用戶使用了 Testflight 后，后續(xù)的測試包的發(fā)布也會(huì)收到更新。不會(huì)像企業(yè)版那樣，只能手動(dòng)的告訴用戶我們有新的測試包。當(dāng) beta 測試活躍用戶超過 100 個(gè)會(huì)有一個(gè)質(zhì)變。這些都是積極的重度用戶，一群重度用戶使用你的新版本幾天，至少可以保證核心業(yè)務(wù)邏輯是沒有紕漏的。

之前有人問過我們使用 Swift ，線上出嚴(yán)重 bug 時(shí)沒法動(dòng)態(tài)修復(fù)，會(huì)不會(huì)帶來很多問題。實(shí)際上因?yàn)橛羞@樣一環(huán) beta 測試環(huán)節(jié)，很少出現(xiàn)嚴(yán)重的事故了。有一次意外是我們的 Swift 版本升級到 4.0 的時(shí)候，一個(gè)枚舉居然對 iOS 8 設(shè)備不兼容(Xcode 并沒有提示我們，蘋果的鍋)。那個(gè)版本也恰好是支持 iOS 8 的最后一個(gè)版本。我們的測試用戶里剛好沒有使用 iOS 8 系統(tǒng)的。

Beta 測試的時(shí)候可以讓用戶及時(shí)的反饋問題也是很重要的。如果我跟你反饋一個(gè)問題，又要看 app 版本，又要說在哪個(gè)頁面，還要說一下我的 userID。用戶的脾氣也是夠好的。我們在 app 集成了搖一搖反饋 bug 的功能，操作步驟，網(wǎng)絡(luò)請求，設(shè)備信息等這些有效的信息都會(huì)一起收集起來。在后臺可以方便的看到。告訴用戶碰到問題搖一搖，描述一下問題就可以了。用戶反饋后我們會(huì)收到郵件，及時(shí)的反饋用戶用戶也很有參與感。

搖一搖的功能并沒有對所有用戶開放，只是針對某些特定我們能聯(lián)系到的用戶開放。畢竟每一個(gè)反饋工程師都需要跟進(jìn)，如果面向所有用戶開放，我們會(huì)收到太多無效信息。常看到工程師討論這些開發(fā)者功能的入口要藏在哪里，有的說在某個(gè)文本框輸入特定字符，有的說在某個(gè)角落里點(diǎn)幾下什么的。開發(fā)者面板的入口我選擇配置在 universal link 里。這樣用戶不會(huì)在 app 里任何一個(gè)地方誤觸到達(dá)，只能通過我們告訴他的鏈接通過跳轉(zhuǎn)到達(dá)。

堅(jiān)持 Code Review，增強(qiáng)技術(shù)交流

Code review 是一件神奇的事情。所有有素養(yǎng)的工程師都覺得 code review 好，據(jù)我們所知國外很多優(yōu)秀的 IT 企業(yè)都很注重 code review，但是在國內(nèi)卻很少看到有團(tuán)隊(duì)執(zhí)行 code review。或者中小團(tuán)隊(duì)里很少看到 code review。

但是我很看重 code review，從情懷的角度講，這里面是工程師技藝的一種傳承。一個(gè)方法名起的不好，從公司角度來看，這個(gè)項(xiàng)目一樣會(huì) work 。但是從工程師角度來說，如果有能力，為什么不幫助那些剛開始寫代碼的人一些指引呢?

作為一個(gè) leader，在 review 的時(shí)候幫助成員成長，和只是看下代碼是不是能完成功能最后會(huì)引向不同的結(jié)果。看過一句很有觸動(dòng)的話，現(xiàn)在很多 leader 知道自己的工作里需要管理其他人，但是卻忽略了還需要 lead 。

老實(shí)說推進(jìn) code review 確實(shí)遇到很多阻力。有團(tuán)隊(duì)里的也有團(tuán)隊(duì)外的。團(tuán)隊(duì)外的看法是 code review 拖慢了項(xiàng)目進(jìn)度。我作為一個(gè)核心的開發(fā)成員，每天超過 20% 的時(shí)間是沒有可見的工作產(chǎn)出的。有時(shí)別人寫的有問題被我打回去改，一個(gè)已經(jīng)完成的功能又多花了幾個(gè)小時(shí)。團(tuán)隊(duì)內(nèi)遇到的問題是，很多成員不理解這項(xiàng)工作背后的價(jià)值。很容易就覺得我早上沒有推進(jìn)項(xiàng)目進(jìn)度，只是在坐在那里不知道在看什么。覺得我 commit 的代碼不多。最后我獲得了團(tuán)隊(duì)“代碼最少產(chǎn)出”獎(jiǎng)。

對于我個(gè)人而言，其實(shí)不搞 review 我肯定更輕松。這個(gè)功能我肯定能把控所有細(xì)節(jié)，這樣寫只是不好而已，也不是不能用。我也大可以不對他們解釋為什么這樣寫是不好的。只要讓他們按照我的 comment 改就可以了。

但是吃力不討好的堅(jiān)持是為了什么?

我剛工作的時(shí)候，出去旅游路上遇到一個(gè)大學(xué)教授。閑聊起來我說我請教你一個(gè)問題，中國古代的鞋子，會(huì)把花繡在鞋底。鞋底其他人又看不到，這樣做的意義是什么。他回答說，我們做事不是做給別人看的，最后還是要過自己心里這一關(guān)。花繡在鞋底，別人看不到，你自己知道。