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

[[283991]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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