今天集中精力，一門心思來做一些后端功能的改造，在這個過程中摸索出了一些實(shí)踐經(jīng)驗(yàn)。

[[283991]]

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

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

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

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

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

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

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

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

6)API和工具類的集成存在冗余，目前的一個重要需求方向是對于一些API的實(shí)現(xiàn)，如果是基礎(chǔ)功能部分，其實(shí)不光可以通過API調(diào)用，也可以通過工具類的方法來進(jìn)行設(shè)計，而在代碼的邏輯層應(yīng)該可以做到無縫的切換，這樣代碼的源只有一份，不會因?yàn)樽兏耐蕉鴮?dǎo)致邏輯分離。

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

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

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

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

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