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

前言

提高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同學更好的對每次新版本上線老介面的自動化回歸測試，減少煩惱，框架開發者也是會很幸福的。

記得點贊轉發哦

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！