今天集中精力，一门心思来做一些后端功能的改造，在这个过程中摸索出了一些实践经验。
首先改造的是一个后端的基础功能，即通过数据库连接执行SQL语句，原有的模式只支持一条SQL语句，对于多条SQL语句的执行存在一些执行的兼容性问题，耐着性子开始持续改进，总算是把这个功能改造成为一个较为通用的实现方式了。文章源自玩技e族-https://www.playezu.com/185760.html
所以这个改造对我来说，其中的一个感悟是：技术改进其实和健身差不多，感觉功能可以支持了，差不多了，能用就行，而在后续的扩展中就会发现少了很多动力，最近练习平板撑，如果坚持2分半钟的话，那么1分半开始的时间就最为艰难的，时刻都想放弃，但是如果有了一个明确的目标也就有了一个最基本的要求和动力。文章源自玩技e族-https://www.playezu.com/185760.html
顺着这个实现的思路往下展开，其实可改进的事情就有很多了。我在这个过程中也做了反思，发现目前主要有以下几类问题：文章源自玩技e族-https://www.playezu.com/185760.html
1)测试环境和线上环境的数据差异较大，很多场景在测试环境难以模拟，如果要尽可能完整的测试，需要快速的同步线上的数据，方便测试。文章源自玩技e族-https://www.playezu.com/185760.html
2)测试环境的少了很多流程的测试依赖，所以只能够尽可能模拟一些基础流程，对于一个较为复杂的功能想要模拟测试，花费的时间比较多，而且如果返工，代价比较高文章源自玩技e族-https://www.playezu.com/185760.html
3)在集成和调试的过程中，如果要把某一个流程串起来，需要做一些埋点和日志记录，这个过程收收放放得反复进行，不够透明文章源自玩技e族-https://www.playezu.com/185760.html
4)程序的变更部署发布目前没有pipeline模式，很多快速部署都是基于手工补丁的模式。文章源自玩技e族-https://www.playezu.com/185760.html
5)API层的设计不够清晰，目前很多API在需求变更中会对接口细节做一些调整，所以文档和实现不大一样。文章源自玩技e族-https://www.playezu.com/185760.html
6)API和工具类的集成存在冗余，目前的一个重要需求方向是对于一些API的实现，如果是基础功能部分，其实不光可以通过API调用，也可以通过工具类的方法来进行设计，而在代码的逻辑层应该可以做到无缝的切换，这样代码的源只有一份，不会因为变更的同步而导致逻辑分离。文章源自玩技e族-https://www.playezu.com/185760.html
7)API体系的设计，目前对于model的变更和状态传播都是通过一大坨一大坨的代码来嵌入，这对于流程维护来说不够友好，而且侵入性较高。
8)代码的容错处理不够健壮，有些功能还有执行失败，但是返回200的情况。
这8个地方的问题我相信但凡有一些业务需求开发的场景都会或多或少碰到，而这也是我最近要践行优化的一个变革面板。
在今天整理这些问题的过程中，也逐步理清了一些思路，也走了一些弯路和返工，在难以进行下去的时候，总是在休息的时候会得到一些处理的灵感。所以整体来看，是在做自我的革新，而这个过程也会让我从差不多先生转换过来。
这些工作中，怎么把设计思想和模型设计的思路沉淀下来，我觉得还是得靠自己对于功能和设计的逐步细化和追求。