用作產品的思路去開發基礎框架

前言

提升RD及QA同窗的人效最有效方式是將基礎組件或系統進行封裝與定製開發，爲上層使用人員（RD/QA）提供友好的接口，對於RD同窗來說不須要關注底層實現細節，可以更多的精力關注本身的業務開發。

產品化開發系統

剛接觸微服務的時候，看過一篇amazon的文章，做爲服務化系統與雲計算的鼻祖，amazon及貝索斯的前瞻性思考着實使人佩服，提出了數字化服務的概念。

amazon最開始是將圖書及電子資源的服務進行api化，提供本身內部其餘系統或合做夥伴進行使用，在最開始就提出了將每一個服務對於研發作到產品角度的友好，這也逐漸演化到了aws的性質，每一個商用的友好的服務都是一個獨立的產品。

其實咱們平常研發用到的好多基礎設施都具備這樣的特徵，好比ES，Kong，K8s，CAT及JDK，操做系統資源，Mysql監控，Spark UI等各類監控系統或可視化的調度操做界面供研發人員使用，友好的界面可能也是咱們喜歡用某種框架的緣由。

全部咱們會花好長時間去自研一套基礎系統，總體微服務系統中在服務降級，服務鏈路，慢查詢，輿情信息等系統都會有比較友好的系統，包含了友好的UI界面和簡單的操做按鈕，達到了能夠一鍵限流，流控可視化，一鍵擴容等效果，總體上提高了RD的人效，而不用每次都經過對接一個SDK去從頭開發，也不會由於SDK版本升級讓業務方從新上線發版。

像計算機同樣思考

常常見到好多公司的架構師指定各類使用規範，滿滿的一套wiki，運維和DBA同窗寫了各類工單操做wiki，每次也避免不了RD同窗就一樣的問題提問。

我總結這種交流和合做方式仍是人的合做方式，而不是計算機的合做方式。

將太多規範性的內容經過語言或者wiki交到人的手裏去實施，歸根結底是不靠譜的，人是會犯錯的，咱們能夠將這部分交給計算機，而將選擇權交到人，這樣可能達到最好的結果。

創建一套有效的監督系統，能夠更好的幫助咱們發現問題，而不是將問題淹沒在海洋裏。

要幸福

有的研發同窗感受不幸福，我猜：

不幸福的多是咱們到了互聯網時代，公司還在用軟件公司的角度去思考迭代，用大項目分層堆代碼的方式面對新需求的迭代，用人工的方式去回滾代碼及數據庫版本。

不幸福多是咱們到了大數據時代，還在用基礎的方式去處理認知，就像幾年前本身手寫分佈式多線程系統去作日誌處理而不敢去嚐鮮使用hadoop，spark，這樣咱們能夠花更多的時間去和產品對接，作出更酷的產品。

不幸福的多是咱們到了AI時代，還在各類登錄OA系統，點擊各類按鈕，選擇各類checkbox提交工單，目前NLP，基本的圖像識別，語音識別能夠用到咱們的研發系統中了，NLP雖然是一個值得付出一生的領域，可是簡單的分詞，類似性推理，能夠用到內部的系統中，咱們的chatops系統能夠幫助咱們簡單的鏈接全部想要的研發系統，OA系統等，雖然目前還很稚嫩，可是咱們是帶着將來去思考的，依舊很幸福。

從事編程行業應該是很幸福的，咱們能夠經過科技幫助人們生活變得美好而簡單，作基礎框架的好處就是咱們可讓RD的工做更加簡單，髒活累活交給咱們，看到你們經過一鍵點擊就可讓本身的系統具有了多實例交付，能夠幫助QA同窗更好的對每次新版本上線老接口的自動化迴歸測試，減小煩惱，框架開發者也是會很幸福的。

幸福來自於付出而不是索取。