背景

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

我總結的幾個會影響交付進度的關鍵問題

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

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

如何解決？

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

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

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

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

工位周邊的環境干擾

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

電腦的軟件環境或硬件環境出現問題

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

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

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

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

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

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

需求變更或理解不到位

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

龐大的技術桟

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

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

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

架構上有重大設計缺陷

架構本身是隨著環境的變化而發生變化的，需求、體量、痛點是推動架構變化的主要原因，我之前做的是廣告行業的技術架構，當時的痛點有如下幾點(有些記不清了)：

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

再說說我們P2P行業的痛點:

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

P2P的業務特點如下

• 需要和第三方資產對接；
• 需要和銀行、支付渠道對接；
• 需要和金融辦要求的監管系統對接，比如合同、標的信息等等，都是要傳過去的；
• 需要給客服提供客服平臺；
• 需要給管理員提供管理平臺；
• 有APP、PC這些自然是不用說了；
  • 活動推廣的體系你得有吧？；
  • 用戶活躍度追蹤的體系你得有吧？
  • 安全體系你得做吧？
• 最主要的特點是：不能錯??！每天的交易都要和銀行、資金通道對賬，每天清算。

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

除了業務上有痛點，公司體量小，本身也會有一個致命痛點

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

基于這些問題，我們就有了一個架構設計的思路：

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

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

go-spirit

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

前幾周都在寫Bug，后幾周都在改Bug

Code Review

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

• 我們不要在for循環里一條條去執行sql來查詢結果，而是應該在for循環前先一次性查回來再處理；
• 涉密的內容不要提交到代碼庫；
• …...

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

擼代碼前做技術設計

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

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

在測試時或發布時阻礙較大

大致會有如下的阻礙:

• 致命性的BUG多，解決同上一個問題
• 上線過程中一堆環境問題
• 上線后一堆問題，和測試環境、開發環境表現不一致

我們是這么做的

MOCK

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

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

容器化、自動化

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

所以，研發人員的研發環境，是一種習慣、文化，更是一整套生態，從物理上的工作環境到電腦里的系統環境，從功能到架構，從研發到上線，每個環節都可能出現效率上的殺手。

后續

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

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

涵蓋的內容大致如下（后續根據實際情況做調整）：

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

一句話：不玩虛的，實戰！實戰！

詳解前的Demo

先給大家放幾張我們現在正在使用的系統的圖片，全當時給干澀的文字配個圖了。。。

使用go-flow搭建下面這些環境的執行截圖，嗯，我給大家帶來的是全家桶，當然這些是基礎環境，每個公司都會有自己的環境需要搭建，大家可以為 go-flow 貢獻插件哦?

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

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

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

Gitlab

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

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

有編譯的詳細過程

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

LDAP

研發人員登錄公司內部系統，都是使用的LDAP，用戶可以自己登錄修改密碼。

Graylog

日志系統，我就喜歡graylog，好用, 結合好 logrus_mate 就可以往不同的系統打日志了。

Redmine

簡單易用。

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

為研發人員創造一個高效的研發環境（二）- 實戰環境搭建

本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得，所有資料僅供用戶學習參考，本站不擁有所有權，如您認為本網頁中由涉嫌抄襲的內容，請及時與我們聯系，并提供相關證據，工作人員會在5工作日內聯系您，一經查實，本站立刻刪除侵權內容。本文鏈接:http://www.webpost.com.cn/13838.html