背景

對(duì)于追求效率的程序員來(lái)說(shuō)，影響工作效率的事情，是深?lèi)和唇^的，當(dāng)大家拿到任務(wù)的時(shí)候，其實(shí)對(duì)于工作量的評(píng)估，心中大致都是有一個(gè)數(shù)的，然而，為什么我們交付的時(shí)候，大部分情況下會(huì)比估算的時(shí)間長(zhǎng)呢，有時(shí)候還會(huì)長(zhǎng)達(dá)幾倍之多？

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

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

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

如何解決？

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

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

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

我來(lái)簡(jiǎn)單說(shuō)一下我們是怎么解決這些問(wèn)題的吧，希望大家能夠給予建議，同時(shí)也很高興能幫助到大家。

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

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

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

我強(qiáng)制給大家配備Macbook Pro Retina, 強(qiáng)制大家使用如下工具：

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

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

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

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

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

需求變更或理解不到位

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

龐大的技術(shù)桟

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

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

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

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

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

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

再說(shuō)說(shuō)我們P2P行業(yè)的痛點(diǎn):

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

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

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

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

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

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

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

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

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

go-spirit

想要快速入手go-spirit請(qǐng)戳這里

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

Code Review

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

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

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

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

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

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

在測(cè)試時(shí)或發(fā)布時(shí)阻礙較大

大致會(huì)有如下的阻礙:

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

我們是這么做的

MOCK

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

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

容器化、自動(dòng)化

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

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

后續(xù)

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

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

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

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

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

詳解前的Demo

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

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

大家不用嘗試訪問(wèn)圖中的地址啦，因?yàn)槲已杆俚氖褂?go-flow 釋放了這些資源?

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

沒(méi)有客戶端證書(shū)的人是無(wú)法訪問(wèn)的。

Gitlab

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

部分任務(wù)可以指定為手動(dòng)觸發(fā)，比如部署，因?yàn)椴皇敲看翁峤淮a都需要部署

有編譯的詳細(xì)過(guò)程

不同的Runner用于跑不同的項(xiàng)目，比如編譯蘋(píng)果應(yīng)用的runner就需要跑在mac上，我們公司有一臺(tái)專(zhuān)門(mén)編譯iOS應(yīng)用的MacMini

LDAP

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

Graylog

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

Redmine

簡(jiǎn)單易用。

能看到最后，說(shuō)明您很認(rèn)真，歡迎加入我的QQ群進(jìn)行更深入的交流：780798965

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

本頁(yè)內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過(guò)網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁(yè)中由涉嫌抄襲的內(nèi)容，請(qǐng)及時(shí)與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會(huì)在5工作日內(nèi)聯(lián)系您，一經(jīng)查實(shí)，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://caipiao93.cn/13838.html