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

[[283991]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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