背景

對于追求效率的程序員來說，影響工作效率的事情，是深惡痛絕的，當(dāng)大家拿到任務(wù)的時候，其實對于工作量的評估，心中大致都是有一個數(shù)的，然而，為什么我們交付的時候，大部分情況下會比估算的時間長呢，有時候還會長達幾倍之多？

我總結(jié)的幾個會影響交付進度的關(guān)鍵問題

1. 工位周邊的環(huán)境干擾，例如把銷售人員和研發(fā)人員放一起；
2. 電腦的軟件環(huán)境或硬件環(huán)境出現(xiàn)問題，例如go的版本和其他人的不一樣，編譯他人的代碼時會報錯；
3. 需求變更或理解不到位；
4. 龐大的技術(shù)桟；不同團隊不同的開發(fā)語言，甚至有的是同一個團隊不同的開發(fā)語言和框架，??吐血。。；
5. 架構(gòu)上有重大設(shè)計缺陷，例如有些功能無法通過某種方式實現(xiàn)，后期又得修改，此路不通；
6. 前幾周都在寫B(tài)ug，后幾周在改Bug??，你看我工作多飽滿??；
7. 在測試時或發(fā)布時阻礙較大，例如Bug多，研發(fā)環(huán)境和生產(chǎn)環(huán)境環(huán)境不一致。

這里不談技能Level問題，我們統(tǒng)一認為水平為中級程序員即可

如何解決？

本文主要是解決研發(fā)順暢度問題的，從開發(fā) -> 測試 ->發(fā)布的效率問題，當(dāng)然，既然上面提出了幾個影響效率的因素，那我就先說一下這幾個問題我們是怎么解決的，雖然不是最優(yōu)方案，但一定是適合我們自己的團隊的，我們團隊人較少，情況大致如下：

• 后端4人
• 前端3人(ios+android+web 采用ReactNative)
• 測試2人

但是產(chǎn)品內(nèi)容較多，比如我們需要和第三方存管系統(tǒng)對接，第三方資產(chǎn)系統(tǒng)對接，需要提供管理員系統(tǒng)，手機APP，官網(wǎng)，以及其他周邊的服務(wù)系統(tǒng)，如果不好好解決效率問題，僅僅憑借這些人員數(shù)量，是遠遠不夠的，因為這里僅僅是包含了開發(fā)的任務(wù)，后續(xù)還有上線和解決線上問題的任務(wù)。

我來簡單說一下我們是怎么解決這些問題的吧，希望大家能夠給予建議，同時也很高興能幫助到大家。

工位周邊的環(huán)境干擾

我們是小公司，這個問題。。。。解決不了，大家都在一個特大開間里， 只能帶耳塞和耳機了。。。不過我們的客服大部分是在微信上服務(wù)，以及出去跑業(yè)務(wù)的，因此干擾度不是特別大；

電腦的軟件環(huán)境或硬件環(huán)境出現(xiàn)問題

我強制給大家配備Macbook Pro Retina, 強制大家使用如下工具：

• iTerm2
• brew
• autojump
• Sublime Text
• oh-my-zsh

同時，我要求編譯環(huán)境的庫版本必須是某個特定版本，比如 go必須使用 1.9.4, 這些都是硬性要求，其他的大家是可以自由發(fā)揮。

大家可能會認為配備Macbook Pro Retina筆記本的成本太高，但是我想說的是，這真的是一個提高研發(fā)效率的途徑：

1. 大家使用相同的操作系統(tǒng)；
2. 命令行unix-like，linux上能用的命令，大部分都移植在mac上了，不需要搞什么cygwin了，那玩意搞得真心難受, 最后效果也不是很好；
3. 流氓軟件目前還沒那么多，windows上動不動就是全家桶。。。；
4. 比linux的ui系統(tǒng)好用；
5. xcode只能在mac上用啊??；
6. 如果和同事共享文件，AirDrop就搞定，方便，而且也不用上傳到某些聊天服務(wù)器上做中轉(zhuǎn)了，心里踏實。
7. 協(xié)作時，隨便拿一臺筆記本都像是在操作自己的筆記本一樣，嗯，這個電影是？??

總之，好處多多，一定要說服你們的老板啊??。

需求變更或理解不到位

一定要要求程序員做需求反講，先是產(chǎn)品經(jīng)理講需求，然后是技術(shù)消化，最后研發(fā)給產(chǎn)品經(jīng)理反講，確保雙方理解一致，對于頻繁改需求的問題，這個沒有太好的解決辦法，因為有時候需求就是變了（這里不是說按鈕要放到別的位置，顏色要換成什么，主要的是指功能性的需求）

龐大的技術(shù)桟

我們的要求就是后端只能用go, APP開發(fā)iOS使用ReactNative，打包自動化用gulp, Web使用React, Android就使用原生開發(fā)，主要技術(shù)桟列表如下：

• Go
• ReactNative
• React
• Gulp
• Android Java
• Docker
• Git

這么羅列下來，其實已經(jīng)很多了，我們應(yīng)該盡可能減緩技術(shù)桟列表的增長，要做好技術(shù)選型的把控工作，不要隨意使用某個語言，某個框架。

架構(gòu)上有重大設(shè)計缺陷

架構(gòu)本身是隨著環(huán)境的變化而發(fā)生變化的，需求、體量、痛點是推動架構(gòu)變化的主要原因，我之前做的是廣告行業(yè)的技術(shù)架構(gòu)，當(dāng)時的痛點有如下幾點(有些記不清了)：

• 服務(wù)器多，當(dāng)時Docker尚未興起(我離職前不久還是很初級的版本，14年初，但Docker也是在那個時候快速崛起的)；
• 我們后端使用Erlang開發(fā)，招不到人也是痛點；
• 由于沒有Docker，部署是個大問題，從研發(fā)環(huán)境->測試環(huán)境->生產(chǎn)環(huán)境都有差異，因為這些差異，找問題需要找很久，有新服務(wù)器加入那更是痛上加痛了，上百臺的服務(wù)器啊。。。。；
• 因為是個大公司，所以一直在沿用 SVN，后來給大家做了GIT的培訓(xùn)，搭建了GitLab, 使用了 GitFlow
• 當(dāng)時沒有使用CI, 你就說痛不痛？其實大公司要使用某個工具，某個架構(gòu)，某個流程，做大批量的更換是挺難的，所以很容易就這么痛下去，都2018年了，我一個同事入職某60,這些給研發(fā)人員使用的基礎(chǔ)設(shè)施還很原始呢，我同事的原話：完全沒法和我們現(xiàn)在的開發(fā)環(huán)境相提并論。

再說說我們P2P行業(yè)的痛點:

我們不跑路，我們是一家很正規(guī)的P2P公司，是金融辦審查過的

P2P的業(yè)務(wù)特點如下

• 需要和第三方資產(chǎn)對接；
• 需要和銀行、支付渠道對接；
• 需要和金融辦要求的監(jiān)管系統(tǒng)對接，比如合同、標(biāo)的信息等等，都是要傳過去的；
• 需要給客服提供客服平臺；
• 需要給管理員提供管理平臺；
• 有APP、PC這些自然是不用說了；
  • 活動推廣的體系你得有吧？；
  • 用戶活躍度追蹤的體系你得有吧？
  • 安全體系你得做吧？
• 最主要的特點是：不能錯?。∶刻斓慕灰锥家豌y行、資金通道對賬，每天清算。

對了，大家如果忘記了我們有多少個人，可以往上面再翻一下，另外，這僅僅是我們的一條產(chǎn)品線，我們之前希望把控更多的資產(chǎn)，自己也嘗試開始做資產(chǎn)管理，嗯，做了一個類似鉆石抵押的借款平臺，反正產(chǎn)品線多。。。

除了業(yè)務(wù)上有痛點，公司體量小，本身也會有一個致命痛點

招聘難：好的人才可遇不可求，我們面試到的程序員也大多是初級或中級的，高級的不多見。由于我們使用的是go語言作為后端語言，ReactNative作為前端APP開發(fā)框架，能找到合適的就是微乎其微了。大家別看這些概念都已經(jīng)很火了，但在我們小公司里，幾乎是招聘不到有這些實戰(zhàn)經(jīng)驗的程序員的，大部分是只有一點開發(fā)基礎(chǔ)的，只會一門語言，甚至沒做過項目的，怎么辦？培訓(xùn)+實戰(zhàn)，沒有別的出路。

基于這些問題，我們就有了一個架構(gòu)設(shè)計的思路：

1. 無論對外的服務(wù)還是對內(nèi)的服務(wù)，統(tǒng)一使用API調(diào)用，這樣我們可以用postman進行測試，或?qū)懽詣訙y試工具進行請求；
2. 能快速搭建，要像樂高組件一樣；
3. 要像市面上兼容樂高組件的盜版樂高一樣，我們一部分用正版樂高，一部分用盜版樂高也無問題，其實這一點很重要，我們是希望，在將來有時間、有精力了，能快速換掉質(zhì)量不好的組件，因為一開始為了趕進度，質(zhì)量把控可能就沒那么嚴(yán)格了；
4. 根據(jù)上一點的描述，我們可以進行服務(wù)降級，比如壓力大的時候，將有復(fù)雜邏輯的組件替換成簡單邏輯的組件
5. 方便本地調(diào)試，也方便自動化部署運維；
6. 壓力大了可以做橫向擴展，即無狀態(tài)；
7. 由于某個功能組件未實現(xiàn)，我們先放個Mock組件進去做測試，或做初期聯(lián)調(diào)。

為了增加把控度，我們自己造了輪子，此框架適用于我們的應(yīng)用場景，同時也是開源的，所以，非常歡迎大家使用，并給出建議：

go-spirit

想要快速入手go-spirit請戳這里

前幾周都在寫B(tài)ug，后幾周都在改Bug

Code Review

這項任務(wù)是必須要執(zhí)行的，但仍然解決不了初級程序員，尤其是入門級程序員犯這個錯誤，第一是要提升這位程序員的技術(shù)水平，在每日例會上要碎碎念，多跟他講講設(shè)計、講講哪些東西合理、哪些東西不合理，經(jīng)常講講行為規(guī)范，比如：

• 我們不要在for循環(huán)里一條條去執(zhí)行sql來查詢結(jié)果，而是應(yīng)該在for循環(huán)前先一次性查回來再處理；
• 涉密的內(nèi)容不要提交到代碼庫；
• …...

真的很碎，但這是規(guī)范，也是文化的傳承，小公司可以這么做，因為人少好叨叨，大公司則需要有嚴(yán)格的行為準(zhǔn)則和制度，但也應(yīng)該拆團隊，培養(yǎng)主管對規(guī)則和文化的重視。

擼代碼前做技術(shù)設(shè)計

做完需求反講后，產(chǎn)品經(jīng)理和研發(fā)人員都對需求有了一定的理解，接下來最好做一下技術(shù)實現(xiàn)上的設(shè)計，先做好磨刀的工作，再做砍柴的事。尤其是對于初級程序員，應(yīng)該先聽聽他們的設(shè)計思路，應(yīng)該給予及時的幫助和糾正，總比在最后讓他們改BUG強。

一定要做好BUG數(shù)量的控制，否則技術(shù)債務(wù)會像滾雪球一樣越來越大，本來我們可以好好做研發(fā)的，卻要去解決焦頭爛額的線上問題，這是不能容忍的。

在測試時或發(fā)布時阻礙較大

大致會有如下的阻礙:

• 致命性的BUG多，解決同上一個問題
• 上線過程中一堆環(huán)境問題
• 上線后一堆問題，和測試環(huán)境、開發(fā)環(huán)境表現(xiàn)不一致

我們是這么做的

MOCK

盡早穩(wěn)定好API接口的定義，測試人員開始寫MOCK(只需要寫個javascript腳本即可，對請求內(nèi)容進行判斷，然后返回特定內(nèi)容)，這樣就可以了，為什么要這么做？

• 后端開發(fā)API的實際邏輯實現(xiàn)會比較慢，前端需要使用MOCK來完成對接，快速實現(xiàn)各個頁面的邏輯聯(lián)通；
• 方便前端人員做前后端的集成測試，如果大家都按標(biāo)準(zhǔn)走，后續(xù)對接只需要更換服務(wù)器地址的配置即可完成無縫的切換工作；
• 測試人員在寫MOCK腳本的時候，會把業(yè)務(wù)場景都過一遍，增加了測試用例的品質(zhì)；
• 嗯。你還可以拿著MOCK給客戶演示??

容器化、自動化

• 一定要使用Docker，包括編譯代碼的編譯環(huán)境。比如gulp編譯網(wǎng)站的時候，研發(fā)人員自己的機器能編譯通過，放到別人的機器上編譯就不行，因為安裝的環(huán)境，類庫版本有差異。如果放到指定的docker里去編譯，則不會出現(xiàn)這個問題；
• 測試人員是對部署后的Docker容器進行測試，測試通過后，則是部署被測通過的鏡像到線上，確保環(huán)境是一致的（只是配置文件獲取的數(shù)據(jù)源不同，出現(xiàn)異常時調(diào)整配置即可）；
• 無論是哪個端，發(fā)布到測試環(huán)境和生產(chǎn)環(huán)境的程序，編譯、自動測試和部署的任務(wù)均在CI服務(wù)器上進行，而不是開發(fā)人員自己的機器，除了上面提到的環(huán)境問題，還有就是：放到CI上做，就需要寫好CI腳本，一切都是按照預(yù)定的計劃執(zhí)行。

所以，研發(fā)人員的研發(fā)環(huán)境，是一種習(xí)慣、文化，更是一整套生態(tài)，從物理上的工作環(huán)境到電腦里的系統(tǒng)環(huán)境，從功能到架構(gòu)，從研發(fā)到上線，每個環(huán)節(jié)都可能出現(xiàn)效率上的殺手。

后續(xù)

我主要會為大家講解，如何搭建一個完整的從 開發(fā)到上線的環(huán)境，并且為大家講解幾個CI案例, 同時實戰(zhàn)gitlab-ci.yml的寫法，讓每個團隊享受CI帶來的便捷和樂趣。

我們用的是阿里云（小公司嘛，哪有錢搞機房），因此，后續(xù)的部署講解均是基于阿里云的，大家也可以按照自己的需求，開發(fā)出部署其他云平臺的模塊，go-flow是插件化的。

涵蓋的內(nèi)容大致如下（后續(xù)根據(jù)實際情況做調(diào)整）：

• 使用 go-flow 搭建一整套研發(fā)環(huán)境
• 使用 gitlab-ci編譯一個APK
• 使用 gitlab-ci編譯一個todo程序的示例(go)，從代碼提交到發(fā)布的整套流程
• 使用 go-spirit快速發(fā)布mock服務(wù)
• PKI (Public Key Infrastructure) 證書使用

一句話：不玩虛的，實戰(zhàn)！實戰(zhàn)！

詳解前的Demo

先給大家放幾張我們現(xiàn)在正在使用的系統(tǒng)的圖片，全當(dāng)時給干澀的文字配個圖了。。。

使用go-flow搭建下面這些環(huán)境的執(zhí)行截圖，嗯，我給大家?guī)淼氖侨彝?，?dāng)然這些是基礎(chǔ)環(huán)境，每個公司都會有自己的環(huán)境需要搭建，大家可以為 go-flow 貢獻插件哦??

大家不用嘗試訪問圖中的地址啦，因為我迅速的使用 go-flow 釋放了這些資源??

我們研發(fā)所有的服務(wù)都做了客戶端證書的雙向認證，以防止外人的訪問（PKI）訪問服務(wù)時，會彈出如下提示：

沒有客戶端證書的人是無法訪問的。

Gitlab

每次提交代碼，都能觸發(fā)自動編譯和測試

部分任務(wù)可以指定為手動觸發(fā)，比如部署，因為不是每次提交代碼都需要部署

有編譯的詳細過程

不同的Runner用于跑不同的項目，比如編譯蘋果應(yīng)用的runner就需要跑在mac上，我們公司有一臺專門編譯iOS應(yīng)用的MacMini

LDAP

研發(fā)人員登錄公司內(nèi)部系統(tǒng)，都是使用的LDAP，用戶可以自己登錄修改密碼。

Graylog

日志系統(tǒng)，我就喜歡graylog，好用, 結(jié)合好 logrus_mate 就可以往不同的系統(tǒng)打日志了。

Redmine

簡單易用。

能看到最后，說明您很認真，歡迎加入我的QQ群進行更深入的交流：780798965

為研發(fā)人員創(chuàng)造一個高效的研發(fā)環(huán)境（二）- 實戰(zhàn)環(huán)境搭建