我們再回到業務層上來細致看一下如何提升研發效率。說到研發效率還真不只僅就是如何寫代碼這么簡單，要開發一個產品，并不是人越多越好，而是觸及人與人之間的信息傳送本錢，有時分人與人的溝通本錢以致大平寫代明的本錢，另外，當系統查復雜r以后，代碼應該寫在哪里，也就品人數 去理解這個原有的系統也變得很困難，由此可見， 大部分時間并設有真正化在完成業務需求一個系統的產品經理花上2周評價時間，然后開發同窗再用2周時間評價怎樣完成，最上，這樣的研發效率肯定是不合理的。所以要思索如何處置人性化，人與人溝通的問題，這是處置業務研發效率的關鍵所在。
1.溝通效率問題
有協作必然就有溝通，提升溝通效率最好的辦法就是構成默契，要構成默契就要經過規范和商定等伎倆把大家圈在同個言語頻道上。需求階段的溝通比較多，如統術語，需求結構化表達，統業務身份。
?。?）統一術語。這在一個公司非常重要，比如在某些公司，“PM"這個詞是指產品經理，而在另外些公司是指項目經理；還有諸如應用，系統，模塊這些基本的稱謂，假設大家理解不一樣的話會很糟糕。
在公司中構成術語也有些技巧。比如給產品取一個好名字，名字既可成為術講也可以是很好的傳播符號，像滴滴的個效勞框架叫DiSF （ didi service framework，滴師傅），這個名字有內容、有含義很容易被記住。在公司中與人溝通也是一樣，假設很難一句話向別人說清楚某個產品或者項目，那么推行起來就會比較費力，因此，把自己的產品，項目或任何需求向別人表達的事情術語化可以減少溝通的成個。
（2）結構化表達需求?；ヂ摼W公同中都是需求驅動產品和技術的，提出需求的人大多都是運營和產品經理而非技術人員，這就不可避免地存在不同崗位人員的溝通理解問題。需求的結構化表達就是把需求用“ 系列的術語、圖標、頁面等可以更好理解和呈現的方式（普通產出就是PRD）在同一個語境中表達出來，讓對方更好的理解。溝通需求的過程就是把不肯定性肯定下來的過程，需求越細致溝通越容易。把需求結構化，和把系統中需求經常改動的邏輯配置化要抵達的效果是樣的，最終產生的結果就是一個變卦記載。
（3）統業務身份。業務身份是管理一個業務在各個業務城中定義的業務規則索引，是一串平臺可識別的編碼，該編碼由構成業務的要素經過一定組合關系運算生成，在平臺的運轉城中，各個業務域的系統根據輸人的參數條件，中止業務身份判別運算，最終根據識別出的業務身份結果，執行該業務在本系統定義的業務規則。要完成統一業 務身份必需求處置：
系統之間同一項業務的聯通性問題，讓系統自動呈現業務整體視圖；
業務條件沒有生命周期管理、系統長期維護困難的問題，要統一業條件識別；
業務上下線相互影響、回歸工作量大和效率較低的問題。這就要對業務邏輯中止才干籠統，樹立封鎖性，從而隔離業務。
對業務身份中止統一管理，需求完成：對業務身份標識的統一注冊和管理，普通需求構建一個運營平臺；有業務規則的配置界面；規則的執行引擎，所以統一業務身份需求人口的注冊管理、規則的配置與變卦，以及規則的運轉域，缺一不可。
2.開發效率
如何高效地寫代碼是程序員永世的話題。這觸及很多要素，如程序員對代碼言語本身的控制程度（比如JDK8中引人閉包代碼可以使代碼更簡約），寫代碼所用的IDE以及快捷鍵的運用程度，等等。筆者在這里先拋開這些問題，闡述下從開發到測試再到運維的整個效率問題。
開發，人員都不希望別人亂碰自己寫的代碼，對代碼有絕對的控制權，所以普通都喜歡掌控（Owner）系統，即這個系統我說了算。在這種情況下，曾有一段時間我們把系統拆得很小，結果降生了很多同質的系統，越來越多地在做重復的事情；此后又閱歷了系統兼并的階段。但是，系統兼并也會帶來新問題，即開放過程中抵觸比較兇猛，包括打包部署的效率都很低，在這種情況下會有兩種處置方案：一是開發態和運轉態分別；二是對系統中止分層和籠統建模。
所謂開發態和運轉態分別，就是大家線下的開發都是獨立中止的，包括打包和部署，接口的調用分開，走遠程調用。但是在線上部署時，都是部署在同一個容器中，把遠程調用變本錢地調用。這種思緒我們在“兼并部署”一章中有引見，本質上可以做到開發態和運轉態的分別，同時統籌開發效率和運轉效率。
3.測試效率
整個軟件生命周期觸及很多環節：需求、開發、測試、上線、運維…觸及很多協作。這些環節都會對效果有影響。其中，測試效率非常重要，由于測試花費的時間幾乎和開發所花的時間是一樣的。關于如何提升測試效率，我們總結了一些理論閱歷，分述如下。
（1）全鏈路Beta測試
繼續堅持Beta環境與線上環境的分歧性，將中心鏈路上的應用，Beta環境HSF打通，減少90%由于環境問題招致的P1、P2缺點。
打通之后，可以完成以下效果
測試環境可以做到召之即來，揮之即去；
在分批發布前，可以在極短的時間內有針對性地考證中心功用；也可以選擇性地屏蔽 Cache的訪問；數據軌跡可以實時顯顯露。
4.運維效率
運維包括線上和線下兩部分，運維效率會在兩個環節表現得最明顯，一個是線下的打包編譯步驟、代碼分發步驟；一個是線上的下線一重啟一上線步驟、發布檢查步驟和回滾步驟。下面我們分別看看在這些環節有哪些中央可以優化。
1）打包編譯環節
優化流程。環境分配，可以預先分配好代碼copy，要主動準備而不用每次編譯代碼時再做環境方面的準備工作；
預處置。監控代碼版本修正，當代碼被修正后，自動觸發代碼兼并抵觸檢查做代碼編譯和打包操作，不要等到用戶點擊再觸發；每個分支代碼更新主動和主干做 Merge，發現有抵觸要主動通知相應開發人員修正，不要等到打包部署時再暫時修正；
代碼編譯優化。規則檢查，業務依賴的包要做依賴規范化管理，經過工具識別依賴；減少應用依賴 SNAPSHOT版本Jar，可以儉省 Maven編譯時間； Maven打包優化，優化 Maven配置減少不用要的消耗；
增量編譯。減少編譯時間的辦法之一就是只編譯變化的部分；比較代碼修正時間和編譯的代碼更新時間可以區分那些修正的類，并針對它們做增量編譯，大大減少編譯時間。
打包機器硬件升級。提升編譯速度的另一個辦法是升級機器硬件，運用更多的CPU或者更多的內存可以明顯提升編譯速度；多組機器 standby以處置并發修正情況，并不斷堅持應用處于可用狀態，減少開發上廁所的次數。
?。?）代碼分發步驟
代碼分發主要思索兩個問題，一個是代碼的下載，最好是支持P2P下載，這樣的下載效率最高（固然大部分情況是HTTP下載較多，但真心不建議采用）；二是假設代碼包比較大且同時下載的機器比較多時，要思索下載機器的網卡流量能否滿足，這點必需特別留意。
?。?）下線、重啟、上線步驟
下線環節。下線被動等候15秒安康檢查失敗，能否主動通知LVS下線，而不是被動等候3次3秒的檢查失敗后再下線；
重啟。初始化各種效勞，去掉不用要的效勞初始化，將一些效勞改成慢加載，部分效勞可以并行初始化。
?。?）回滾
回滾等于重新發布，直接應用本機的老war包快速重啟，不需求再走包分發網站樹立步驟，要有手動回滾腳本。假設回滾時間長則減少回滾批次，采用發布一批機器就下線一批機器的方式：下線的機器堅持 standby，老代碼不提供效勞，呈現問題后再立即下線新發布的機器，將 standby的機器立即上線。這樣可以快速抵達回滾的目的，在30秒內就能完成回滾。
