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

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

代碼托管：自建 Gitlab

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

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

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

盡早招人

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

• 不能給出太高的薪水

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

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

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

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

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

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

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

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

轉(zhuǎn)型 Swift

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

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

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

先用 Swift 寫好網(wǎng)絡(luò)層的庫,。借著把常用的幾個 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è)務(wù)推進(jìn)中,，Swift 比例越來越高,。

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

理順開發(fā)工作流

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

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

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

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

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

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

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

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

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

接入 CI

很多團(tuán)隊改變代碼里的宏來區(qū)別 app 里的環(huán)境,，每次提交前改下宏,。常在河邊走，哪能不濕鞋,。我還真遇到過提交 App Store 的時候,，有人忘記改環(huán)境的宏，app 連接到的是測試環(huán)境,。這里想說的不是發(fā)布前要仔細(xì)檢查,，而是這種情況就不應(yīng)該發(fā)生。

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

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

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

用好 Testflight,，注重 beta 反饋

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

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

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

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

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

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

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

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

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

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

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

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

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

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