如何能讓開發效率快10x倍?
01-26
為什麼開發慢?
據我不完全的觀察,開發的過程是這樣的
如果是測試環境,那為什麼慢呢?- 測試環境又不好使了,誰又改了什麼
- 沒有真實的流量,線下的小白鼠沒有代表性
如果是生產環境,那為什麼慢呢?
- 部署不能太快了,得慢慢來,免得掛了
- 開流量得小心又小心,免得掛了
所以要讓開發速度變得更快,就是要更快地做想要的改動,然後更快地得到好使還是不好使的反饋。
以下為科學幻想實現原理
願景已經很清楚了。那麼怎麼實現呢?
大部分業務系統都是支持多用戶的。用戶與用戶之間的數據是隔離的。我們可以通過在線上增加測試用戶的方式,在生產環境直接跑測試。
然後我們可以在產生環境運行多個版本的代碼,通過給流量打標籤,中間件導流控制不同流量在模塊之間的走向,從而起到引流到被測模塊的目的。- 被測模塊部署到生產環境的隔離區域,不接真實流量
- 線上錄製真實流量
- 根據捕獲的真實流量構造測試請求
- 根據捕獲的真實流量準備灌入測試數據
- 發測試請求,通過引流讓其流經被測模塊
- 查看響應,以及所有的副作用
第一步:部署模塊到生產環境,但是不接流量
就是部署到一台獨立的機器(可以是容器,節省成本)。然後通過中間件控制真實流量不要過來。如果在線有開發環境,比如基於瀏覽器的IDE,這個部署成本可以更低。第二步:獲取真實流量
把業務邏輯的入和出都劫持下來,通過網路代理獲得所有的請求和響應數據。如果需要捕捉特定類型的請求,可以把預期的類型參數加到錄製的邏輯,有選擇的錄製。第三步:構造測試請求
- 圈定測試的scope
- 修改入口處的request
- 控制第三方模塊的response
第四步:灌入測試數據
這一步很簡單,就是測試司機開戶,測試乘客開戶這樣的過程。把真實的司機乘客等業務流程參與方的數據灌入到資料庫里。以便流量回放時使用。
特別注意此處相比線下測試可以節省大量的配置數據的複製和還原。
第五步:發測試請求
被測的模塊未必是入口的模塊。所以可能需要讓流量穿過一些生產環境的正式模塊,再流到測試中的被測模塊版本。
在需要控制一些測試邊界範圍外的系統response時,可以通過出代理來mock數據
第六步:查看結果
這個就回到了流量錄製這一步了。通過查看錄製的請求處理過程,可以人工判斷被測代碼是否符合。如果需要變成自動化測試,人工再標記一些需要比對的結果欄位,然後把處理過程保存到自動化測試系統里。
總結
好處
- 線下測試掛了,第一反應是不是環境問題。線上要可靠得多
- 節省大量構造測試數據的時間
- 需要灌入資料庫的測試數據比線下搞要少
- 運營配置等依賴不再是問題
難點
- 測試數據不要污染正式的運營數據
- 根據Log複製用戶,這一步和具體業務相關,需要理解log
- 支撐整個框架的中間件的穩定性和性能,不影響線上正式業務
但是如果這個科幻真的實現了,我們離
就不是很遠了。
推薦閱讀:
※如何看待重型敏捷管理框架?
※敏捷實際是迭代的瀑布模型的變種,這種觀點對嗎?
※如何看待 PMI 推出的敏捷認證 PMI-ACP?