運維開發和測試中常見的8個問題

這是學習筆記的第 2167 篇文章

今天集中精力，一門心思來做一些後端功能的改造，在這個過程中摸索出了一些實踐經驗。

首先改造的是一個後端的基礎功能，即通過資料庫連接執行SQL語句，原有的模式只支援一條SQL語句，對於多條SQL語句的執行存在一些執行的兼容性問題，耐著性子開始持續改進，總算是把這個功能改造成為一個較為通用的實現方式了。

所以這個改造對我來說，其中的一個感悟是：技術改進其實和健身差不多，感覺功能可以支援了，差不多了，能用就行，而在後續的擴展中就會發現少了很多動力，最近練習平板撐，如果堅持2分半鐘的話，那麼1分半開始的時間就最為艱難的，時刻都想放棄，但是如果有了一個明確的目標也就有了一個最基本的要求和動力。

順著這個實現的思路往下展開，其實可改進的事情就有很多了。我在這個過程中也做了反思，發現目前主要有以下幾類問題：

1）測試環境和線上環境的數據差異較大，很多場景在測試環境難以模擬，如果要儘可能完整的測試，需要快速的同步線上的數據，方便測試。

2）測試環境的少了很多流程的測試依賴，所以只能夠儘可能模擬一些基礎流程，對於一個較為複雜的功能想要模擬測試，花費的時間比較多，而且如果返工，代價比較高

3）在集成和調試的過程中，如果要把某一個流程串起來，需要做一些埋點和日誌記錄，這個過程收收放放得反覆進行，不夠透明

4）程式的變更部署發布目前沒有pipeline模式，很多快速部署都是基於手工修補程式的模式。

5）API層的設計不夠清晰，目前很多API在需求變更中會對介面細節做一些調整，所以文檔和實現不大一樣。

6）API和工具類的集成存在冗餘，目前的一個重要需求方向是對於一些API的實現，如果是基礎功能部分，其實不光可以通過API調用，也可以通過工具類的方法來進行設計，而在程式碼的邏輯層應該可以做到無縫的切換，這樣程式碼的源只有一份，不會因為變更的同步而導致邏輯分離。

7）API體系的設計，目前對於model的變更和狀態傳播都是通過一大坨一大坨的程式碼來嵌入，這對於流程維護來說不夠友好，而且侵入性較高。

8）程式碼的容錯處理不夠健壯，有些功能還有執行失敗，但是返回200的情況。

這8個地方的問題我相信但凡有一些業務需求開發的場景都會或多或少碰到，而這也是我最近要踐行優化的一個變革面板。

在今天整理這些問題的過程中，也逐步理清了一些思路，也走了一些彎路和返工，在難以進行下去的時候，總是在休息的時候會得到一些處理的靈感。所以整體來看，是在做自我的革新，而這個過程也會讓我從差不多先生轉換過來。

這些工作中，怎麼把設計思想和模型設計的思路沉澱下來，我覺得還是得靠自己對於功能和設計的逐步細化和追求。