內容來源：2018 年 5 月 19 日，G7匯通天下技術合夥人廖強在“PHPCon China 2018 技術峰會”進行《敏捷工程實踐與自動化》演講分享。IT 大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發佈。
閱讀字數：5125 | 13分鐘閱讀
嘉賓演講視頻回放及PPT，請複製鏈接：http://t.cn/Req3YRK，粘貼至瀏覽器地址欄即可。
摘要
本次演講會深入介紹G7在產品研發過程中去除重複性工作的技術規範、細節和背後的思考，以及G7的技術體系如何平衡效率和規範的衝突。
業務對技術的要求
之前有人提問“如何提高自己的工資”，其實個人認為這取決於你貢獻的價值到底有多大。我09年進入百度的時候，高併發的場景很是流行，當時那些技術較強的人都能夠解決關於高併發的問題，會採用各種技術手段進行極致的調優。
我們再回過頭來看下，現今的互聯網經過不斷髮展之後，很多基礎組件已經變得非常豐富和完善，比如web Server 從Apache到Nginx，緩存也開始出現了，數據庫索引的正確使用方式也被大家所熟知等等。慢慢的關於性能瓶頸的問題大家很少再遇到了，這其實是由於我們的系統變得越來越複雜，業務對技術的要求變成了既快又好，“快”指的當然就是工期短，而“好”則是可維護性強，能支持後續的發展。如果能做到這兩點，那麼你的價值就會得到很大的提升。
要做到又快又好，還有一個核心的原則——所有重複的都應該被自動化。它帶來了兩個好處，一是標準，不用再寫過多的代碼，二就是“快”。接下來的內容將會反覆提到這一理念，首先讓我們從研發的角度來過一遍整個項目的流程。
項目流程
標準API定義
隨著微服務化的流行，團隊之間的協作變得越發重要。原先的接口定義一般採用的是IDL的方式，不過IDL的問題在於標準是自己定義的，且無法在瀏覽器上直觀的閱讀和感受。所以整個流程的第一件事情就是標準API的定義，為此需要用到Swagger，但不必預先就定義好，因為長期來看業務的發展會促使代碼變更，而接口卻並不會跟隨改變，這時接口文檔和代碼的表現就會不一致。因此為了減少人為因素的干擾，我們需要做到的是100%同步。
當配置好Swagger之後就可以通過一些方式自動的生成接口定義，同時訪問服務地址也能獲取到接口的標準，還可以進一步的通過頁面展示接口的具體內容。不過這種方式需要重複寫很多的註釋，而且這些註釋並沒有作用於代碼，同時代碼和註釋也無法保障同步。
正常來說各種框架中都會有路由功能，能夠直接定義路由的處理方法和請求方式。有了這一層支持就意味著在Swagger中的註釋已經無用，我們只需要分析這裡的語法拿到對應的值就夠了，這樣也可以實現接口的同步。
上圖這種方式保證了開發人員在寫代碼的時候一定會去寫註釋，而這樣的註釋才算是真正有意義且能夠成為對API的描述。
枚舉的可維護性
可以發現上面的API描述，其實是定義了一個枚舉，用不同的數字表示不同的狀態。這樣雖然可以節省字節，但是其他人員在使用的時候卻需要查看描述來確定各數字代表的含義。
為了解決這樣的問題，我們又新定義了一個enum標籤。因為這裡所有的代碼都可以通過語法樹查看到，所以我們這裡做了一些註釋。同時Go可以通過interface定義如何解析注入的字段，CERT_TYPE__ID_CARD和CERT_TYPE__PASSPORT在注入的時候就會被轉成對應的數字。 圖中左邊就是實際的使用情況，可以看到傳遞的直接是字段名，這樣的方式能讓人很好的理解參數的含義。
上圖的界面大概的展示了最終的效果。
數據庫操作的重複性
當接口定義好之後，到了正式的開發階段首先要做的肯定是定義數據結構。這個階段也會出現各種問題，比如要寫很多重複的增刪查改方法；在定義完數據結構之後還得生成創建對應table的SQL語句，當model發生改變的時候需要重新調整修改SQL，如果有多種環境，一段時間之後對應的數據庫可能還會不一致。
我們之前是通過寫代碼來定義外部的元素，而如果定義一個model讓它完成所有的工作，那麼就只需要定義正確的數據庫的表結構就能完成創建工作。如上圖定義了數據庫的各種結構細節，通過解析它就能自動的執行對數據庫的相關操作，比如檢測數據庫和表是否存在，沒有的話就自動創建；檢測表的字段和定義是否一致。這樣在啟動的時候就能保證model和表結構的一致，需要注意的是這種方式我們只在非線上環境中使用。通過檢測env環境變量來獲知當前運行環境，從而決定是否啟用該功能。
另外針對第一個問題也有了解決方案。如果發現第一個ID為主鍵就能夠自動生成所有的增刪查改方法，唯一索引同樣也是這種原理，對於普通索引只要符合最左前綴原則其實組合也沒有太多。
Client代碼的重複性和準確性
正常來說數據庫代碼寫完之後，就輪到了邏輯代碼的編寫。這個過程中會請求很多的外部服務，開發人員需要寫大量的請求代碼，同時這些代碼還需要經過測試人員的測試。
手動的編寫無疑是繁瑣的，有了標準API之後其實完全可以通過上圖的方法自動生成請求代碼。
在微服務中我們經常需要做服務治理，一般的做法是根據Request ID獲取到請求鏈，但是這種方式準確率並非100%，因為有可能請求只監控到一天中的某個階段的流量。
採用自動化生成之後就意味著能夠完全確定所調用的服務，每個服務的依賴層級也能明確的知曉。最後我們就能繪製出上面這樣的結構圖，其中圓點越大表示依賴越多。
Mock
在測試的時候一旦碰到與環境相關的內容就會變得非常麻煩，那麼可不可在不部署任何東西的情況下就能測試到所有的業務邏輯呢？其實在以上的所有部分全部標準化之後，測試的時候不是必須要去請求外部。比如在知道了client擁有的方法之後，只需要定義好interface，然後編寫測試代碼的時候實現另一個interface注入其中就能測試所有的業務邏輯，並且還可以自由的構造下游想返回的數據。
配置管理
上線時候的配置管理有很多種方案，有中心化管理、通過代碼倉庫管理，其中還會涉及到數據庫密碼這樣的私密信息，以及各種其他的問題。
我們對此的思路稍微有些不同——配置被直接當成了代碼，不存在配置文件。配置文件的問題在於程序的邏輯被外部的因素控制，而且控制細節也不容易被知曉。
配置代碼內部首先有一些默認值方便處理，然後會定義一些configTag用來表明該參數可以從外部注入，具體的注入方式通過環境變量完成。程序啟動的時候會讀取其中的環境變量，然後去匹配配置代碼中的參數更改對應的值。
CI Flow
配置管理問題解決之後就輪到了CI Flow。為了應對業務高速發展的場景，我們實現了一種新的Flow，所有的代碼都是在master上，每次開發新功能的時候都會新建一個feature，開發完成之後會打上規定格式的tag，然後我們會對應的將程序打包併發布到測試環境，測試沒問題之後會再次打上demo的tag，識別到這個tag之後就會再將程序放到demo環境中驗證，最後合併到master上。這樣在並行開發的時候互相之間就不會產生影響。
未來待做的
原先產品提出需求之後，是先開發完之後再進行測試，這種方式效率並不高。其實開發定義好標準接口以及邏輯處理方法之後，開發部分的內部實現和測試部分的編寫是可以並行的。所有我們希望構建這樣一種模式，即開發定義好基礎框架後，測試能夠緊隨其後編寫代碼。雖然這樣會模糊測試和開發的邊界，但是我們的另外一個理念就是所有人都是開發。
以上為今天的全部分享內容，謝謝大家！
閱讀更多 IT大咖說 的文章
