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

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

代碼托管：自建 Gitlab

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

工程師的時間比機器貴

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

盡早招人

招人是團隊發(fā)展過程中非常重要的一環(huán)。很多早期團隊都低估了招人的難度和周期。因為不太知名的團隊招人有兩個缺點：

不能給出太高的薪水

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

團隊事情多且雜

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

招人除了技術(shù)的硬指標，在早期團隊還有一個工程團隊文化的問題。一個幾十個人的項目，里面某個特定的人的積極性對于項目其實是不太重要的。他只要完成應該完成的工作。甚至和其他人不說話也影響不大。一個大的項目也不能因為任何一個人不在了就運行不下去。

但是早期團隊，人就這么幾個。有一個人對團隊的使命認知不一致，日常行為里就會有很多摩擦。

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

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

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

轉(zhuǎn)型 Swift

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

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

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

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

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

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

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

理順開發(fā)工作流

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

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

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

不用 Sketch 的設計師不是好設計師

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

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

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

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

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

接入 CI

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

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

實際上通過 Xcode 打包手動提交也是一個充滿風險的過程。因為不時會出現(xiàn)本地改了幾行代碼，提交的時候把本地的代碼也提交了。帶來了未知的風險。

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

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

用好 Testflight，注重 beta 反饋

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

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

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

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

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

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

堅持 Code Review，增強技術(shù)交流

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

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

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

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

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

但是吃力不討好的堅持是為了什么?

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