接手一個負分的 iOS 項目後我作了什麼

半年前我加入一個剛剛拿到 A 輪資金的創業團隊負責 iOS 項目。早期的時候公司生死未卜，只追求快速迭代找到一個正確的方向。這種早期默默無聞的團隊也沒什麼工程追求，就是寫的快就行了。可是肯定方向後要長期發展，就不能再野蠻生長了。 基於過去半年我在這個項目裏的實踐經驗，和你們分享一下。

代碼託管：自建 Gitlab

早期草根團隊最省事的就是用 GitHub 了。可是團隊人數增長後用 GitHub 的成本就很高了。普通的團隊套餐每月每人 9 刀。另一個問題就是 GitHub 部署在國外，國內訪問網絡時常不穩定。聽聞某跨國團隊代碼託管在 GitHub 上，某次重要會議期間 GitHub 沒法正常訪問。真是突如其來的父愛如山。 另一個缺點就是服務端若是要本身配置 CI 服務不太方便。若是部署在本身的服務器上，其餘一些服務腳本也部署在一塊兒，會有很大的自主權。 綜合以後選擇了主流的 Gitlab。

工程師的時間比機器貴

不少短視的團隊以爲配給工程師的設備太貴，挑個便宜點的就行了。一臺好的電腦雖然貴點，但是長期下來節省下來的工程師的編譯時間比機器貴多了。在設備上我跟公司建議那就配最新的 15 寸的 rmbp 唄，再來一個 dell 4K 顯示器唄。後面發現鍵盤鼠標也重要啊，每一個人又補貼了 500 塊的鍵鼠額度。 看到不少工程師還在用 air 開發，還有 mac mini 的。真的爲這種傻逼公司感到心痛。我曾經在的某團隊仍是 4 個終端用同一臺電腦。每次編譯的時候我就到南京路散個步。若是晚上要上線，能夠去看個電影回來。

儘早招人

招人是團隊發展過程當中很是重要的一環。 不少早期團隊都低估了招人的難度和週期。由於不太知名的團隊招人有兩個缺點：

• 不能給出過高的薪水

  優秀的人才固然會比較市場上薪水。已經成名已久的 BAT 這種公司天然會有薪水的優點。創業公司雖然有期權，可是畢竟公司前途未卜。不少工程師也擔憂公司會不會過陣子就倒閉的問題。

• 團隊事情多且雜

  項目成熟後的迭代大可能是循序漸進，有穩定的節奏。每一個環節的都有很細分的專職人員。早期的項目由於項目仍是處於成長階段，極可能半路作着看到直播火了，咱們加個直播的需求。或者作着作着發現競品有個功能，管不了那麼多咱們下個版本就上。或者 CEO 路過的時候忽然有了個想法，上線的時間又推後一下。

招人除了技術的硬指標，在早期團隊還有一個工程團隊文化的問題。一個幾十我的的項目，裏面某個特定的人的積極性對於項目實際上是不過重要的。他只要完成應該完成的工做。甚至和其餘人不說話也影響不大。一個大的項目也不能由於任何一我的不在了就運行不下去。

可是早期團隊，人就這麼幾個。有一我的對團隊的使命認知不一致，平常行爲裏就會有不少摩擦。

我以前思考過團隊文化是什麼，怎麼形容團隊文化。後來看到一個說法感受挺貼切。文化是空氣，無處不在。公司沒有規定下班後社交平臺上看到用戶反饋須要你去迴應，也不會規定你發現其餘部門的產品有問題是不當回事仍是應該去和其餘部門的人溝通，又或者看到一個更好的建議是否是要和公司提出來。這些行爲背後的支撐就是團隊文化。在團隊裏的人決定了價值觀。

綜合上面說的，招到一個匹配的技術人員，運氣好的話幾天就你能遇到，更常見的狀況是可能要好幾周的時間。固然若是情急之下招進來一我的，幹了幾個月後發現不合適就走了，對於團隊的士氣損害也挺大的。

因此考慮到項目將來的進展，要及時啓動招人的計劃。當你發現進度忙不過來的時候開始招人，這個時候你要抽時間去準備面試的事情，還要兼顧項目進度，會很焦頭爛額。

轉型 Swift

團隊裏的另外 3 個同事以前都沒有寫 Swift 的經驗。可是考慮到將來的發展趨勢，而且咱們的業務類型對動態化的要求沒那麼強。我堅持在團隊裏推行使用 Swift 編程。

我常常被問到的一個問題是你想用 Swift 可是團隊裏其餘人不會用，會不會給項目推動帶來困難。其實若是團隊裏有人正確的引導，幫他們解決上手過程當中的問題，再給一段時間過渡。很快他們就會退不回去。

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

先用 Swift 寫好網絡層的庫。藉着把經常使用的幾個 OC Model 和 Swift 對象作好橋接。相似下面這樣：

class SwiftUser {
	init(ocUser: OCUser) {
	}
	func convertOCUser() {
	}
}
複製代碼

這樣改造以後若是一個新的模塊就能夠徹底用 Swift 編寫。一開始確定是用 OC 的思惟寫 Swift 的代碼。可是在熟悉了 Swift 語法後能夠慢慢在 review 過程當中提出能夠用更 Swift 的寫法。 有些功能須要 OC 和 Swift 互相調用確實挺麻煩。若是讓一個沒 Swift 經驗的上手就解決這些問題必定很氣餒。因此在項目過程當中也要分配必定時間把老的 OC 代碼重寫了。好在原先的代碼原本就很亂，須要重寫。這樣就隨着業務推動中，Swift 比例愈來愈高。

這樣通過一兩個月後你們就慢慢熟悉了 Swift ，此時再去推動 RxSwift 等框架的使用。

理順開發工做流

項目早期的時候需求千千萬，一個迭代版本中應該開發多少功能呢？產品經理本能的就是靠拍腦殼。列了一頁需求後表示這就是這個版本了。程序員都傾向於樂觀估時間，作着作着半個月過去了。下個迭代的需求、UI 設計，交付前測試的工做都很混亂。

後來通過討論肯定了兩週一個迭代週期。開發過程當中發現某個需求這個迭代裏沒法完成就挪到了下個迭代中。每一個週期階段要作什麼你們都很明確。兩週左右發佈參考用戶反饋也是一個比較好的節奏。

這裏要強調的是開發過程前期的準備工做。主要指需求和 UI 圖。大多數的需求設計都是圍繞某個需求展開，可是這個需求要融入到現有體系裏是有不少周邊的工做要作的。好比產品提出用戶資料裏應該能夠打標籤。因而畫了一個草圖裏有標籤。對於他可能這個需求描述的很明確了，可是真正落地的時候就有其餘工做要作。好比標籤怎麼刪除？標籤有字數限制嗎？標籤重複了怎麼辦？這些問題若是前期設計的時候產品沒有表達清楚，就只能在開發的過程當中來回溝通。有一個經驗豐富的開發者在前期就參與需求的討論，和提出問題對於在後期開發有很大的幫助。

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

我看到不少設計師沿用傳統，一直使用 PS 。然而實際上業界使用矢量設計工具 Skecth 已經很廣泛了。如今手機的屏幕尺寸更異，若是設計的時候不是矢量圖，而是位圖，作響應式的佈局設計就會很不方便。實際上移動的 UI 設計若是用慣 Sketch ，絕對是生產力的極大提高。 可是和大多數人同樣，不少設計師都會以爲 PS 用的也挺順手的，Sketch 沒用過。其實 leader 是有義務去推進一些人，讓美好發生。

以前我在的團隊我就一直不斷暗示不厲害的設計師才用 PS ，後來刺激了幾周後他說他如今也能夠用 Sketch ，後來慢慢項目 symbol 都湊齊了 PS 他也退不回去了。

固然也有很是老派的設計師，這種只能給他壓力讓他去被動改變。當時咱們團隊有一個四十多高齡設計師，咱們也很爲難。我當時想那算了，下個月若是你不能用 Sketch 出圖就本身準備換個工做吧。固然做爲一個團隊也不能給個指示就甩手無論了。中間已經熟練使用 Sketch 的設計師會特別關注他的學習狀態，及時指導。最後也獲得了一個好的結果，他在被迫改變後發現 Sketch 確實更好用。

這裏還有安利一個很好用的輸出設計圖的軟件：zeplin。設計圖直接採用標註的方式會很死板。程序員在查看過程當中能夠本身查看到設計圖的全部源信息效率會獲得極大的提高。

接入 CI

不少團隊改變代碼裏的宏來區別 app 裏的環境，每次提交前改下宏。常在河邊走，哪能不溼鞋。我還真遇到過提交 App Store 的時候，有人忘記改環境的宏，app 鏈接到的是測試環境。這裏想說的不是發佈前要仔細檢查，而是這種狀況就不該該發生。

實際上經過 Xcode 打包手動提交也是一個充滿風險的過程。由於不時會出現本地改了幾行代碼，提交的時候把本地的代碼也提交了。帶來了未知的風險。

我經過配置 Xcode 裏的 scheme、target 來區分環境。利用 fastlane 來完成自動打包上傳的工做。結合 Gitlab 的 CI ，配置了 Gitlab runner，今後打包只須要點擊一下按鈕。下降了發佈的人工操做風險。

咱們的組件是用 cocoapods 管理依賴的。配置了 Gitlab runner 後，組件的版本更新也放在遠端工做，再也不基於本地。配置了 webhook 後，每次 job 完成後 slack 的 channel 裏你們都會收到消息。

用好 Testflight，注重 beta 反饋

早期業務變化頻繁，沒有自動化測試，只能靠人工測試保證穩定。一開始團隊選擇了發佈企業版的包來測試。固然企業版用戶能夠方便的下載安裝，可是也有很多缺點。最大的缺點就是這個包和 App Store 的包是兩個包，不同的 bundle id 。會致使一些跟包綁定的功能沒法正常測試，好比微信登陸、支付後的跳轉。

咱們的業務裏有聊天的功能，聊天記錄是隻存在本地的。並且咱們認爲一個帳號只能在同一個平臺上的一臺設備登陸。這就致使用戶測試的時候帳號會從 App Store 版本登出，這樣聊天記錄就沒了。熱心用戶願意試用咱們的 beta 版，可是也承擔了不應有的代價。基於這點考慮在個人主導下咱們放棄了發佈企業版的包測試的方式。而是改用利用 testflight 測試。

Testflight 有個較大的使用門檻，須要收集用戶的郵箱，以後在 testflight 裏輸入蘋果發出的邀請碼才能開始測試。不少用戶嫌麻煩就退出了，運營認爲這樣會給測試帶來很大的不便。可是冷靜了心態後其實事情並無那麼糟糕。真正對這個產品有興趣的用戶不會由於要填個郵箱就放棄了。那些流失的只是普通的用戶。用戶使用了 Testflight 後，後續的測試包的發佈也會收到更新。不會像企業版那樣，只能手動的告訴用戶咱們有新的測試包。當 beta 測試活躍用戶超過 100 個會有一個質變。這些都是積極的重度用戶，一羣重度用戶使用你的新版本幾天，至少能夠保證核心業務邏輯是沒有紕漏的。

以前有人問過咱們使用 Swift ，線上出嚴重 bug 時無法動態修復，會不會帶來不少問題。實際上由於有這樣一環 beta 測試環節，不多出現嚴重的事故了。有一次意外是咱們的 Swift 版本升級到 4.0 的時候，一個枚舉竟然對 iOS 8 設備不兼容（Xcode 並無提示咱們，蘋果的鍋）。那個版本也剛好是支持 iOS 8 的最後一個版本。咱們的測試用戶裏恰好沒有使用 iOS 8 系統的。

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

搖一搖的功能並無對全部用戶開放，只是針對某些特定咱們能聯繫到的用戶開放。畢竟每個反饋工程師都須要跟進，若是面向全部用戶開放，咱們會收到太多無效信息。常看到工程師討論這些開發者功能的入口要藏在哪裏，有的說在某個文本框輸入特定字符，有的說在某個角落裏點幾下什麼的。開發者面板的入口我選擇配置在 universal link 裏。這樣用戶不會在 app 裏任何一個地方誤觸到達，只能經過咱們告訴他的連接經過跳轉到達。

堅持 Code Review，加強技術交流

Code review 是一件神奇的事情。全部有素養的工程師都以爲 code review 好，據咱們所知國外不少優秀的 IT 企業都很注重 code review，可是在國內卻不多看到有團隊執行 code review。或者中小團隊裏不多看到 code review。

可是我很看重 code review，從情懷的角度講，這裏面是工程師技藝的一種傳承。一個方法名起的很差，從公司角度來看，這個項目同樣會 work 。可是從工程師角度來講，若是有能力，爲何不幫助那些剛開始寫代碼的人一些指引呢？

做爲一個 leader，在 review 的時候幫助成員成長，和只是看下代碼是否是能完成功能最後會引向不一樣的結果。看過一句頗有觸動的話，如今不少 leader 知道本身的工做裏須要管理其餘人，可是卻忽略了還須要 lead 。

老實說推動 code review 確實遇到不少阻力。有團隊裏的也有團隊外的。團隊外的見解是 code review 拖慢了項目進度。我做爲一個核心的開發成員，天天超過 20% 的時間是沒有可見的工做產出的。有時別人寫的有問題被我打回去改，一個已經完成的功能又多花了幾個小時。團隊內遇到的問題是，不少成員不理解這項工做背後的價值。很容易就以爲我早上沒有推動項目進度，只是在坐在那裏不知道在看什麼。以爲我 commit 的代碼很少。最後我得到了團隊「代碼最少產出」獎。

對於我我的而言，其實不搞 review 我確定更輕鬆。這個功能我確定能把控全部細節，這樣寫只是很差而已，也不是不能用。我也大能夠不對他們解釋爲何這樣寫是很差的。只要讓他們按照個人 comment 改就能夠了。

可是吃力不討好的堅持是爲了什麼？

我剛工做的時候，出去旅遊路上遇到一個大學教授。閒聊起來我說我請教你一個問題，中國古代的鞋子，會把花繡在鞋底。鞋底其餘人又看不到，這樣作的意義是什麼。他回答說，咱們作事不是作給別人看的，最後仍是要過本身內心這一關。花繡在鞋底，別人看不到，你本身知道。

---

歡迎關注個人微博：@沒故事的卓同窗

掘金博客地址：juejin.im/user/5624c8…

若是想與我有更密切的交流也能夠加入個人小密圈：程序員生存指南