今天专心致志的做了一些后端功能的改造，过程中摸索出一些实战经验。首先要改造的是后端的一个基本功能，即通过数据库连接执行SQL语句。原始模式只支持一条SQL语句。多条SQL语句的执行存在一些执行兼容性问题。耐心点，继续改进。最后，这个功能被转化为一个更通用的实现。所以对我来说，对这个转变的一个感悟是：技术提升其实和健身差不多。感觉功能可以支持。平板支撑，如果坚持2分半钟，那么第一分半钟是最难的时候，一直想放弃，但是如果目标明确，就会有最基本的要求和动力。按照这个实现的思路，其实还有很多可以改进的地方。我也在这个过程中反思，发现主要有以下几类问题：1）测试环境和线上环境的数据差异很大，很多场景在测试环境中是很难模拟的。如果想要测试尽可能完整，就需要快速同步线上数据，方便测试。2）测试环境缺少很多流程测试依赖，只能尽可能模拟一些基本流程。对于比较复杂的功能，如果要模拟一个测试，会花费很多时间，而且如果返工，成本会比较高。3）在集成调试的过程中，如果想把某个流程串起来，需要做一些埋点和日志记录。这个过程反复进行，不够透明。4）程序变更部署发布目前没有pipeline模式，很多Rapid部署都是基于手动patch模式。5）API层设计不够清晰。目前很多API在需求变化的时候都会对接口细节做一些调整，所以文档和实现是不一样的。6）API和工具的集成存在冗余。目前一个重要的需求方向是一些API的实现。如果是基础功能部分，不仅可以通过API调用，还可以通过工具进行设计。在代码的逻辑层，应该可以无缝切换，这样代码只有一个源头，不会因为变更的同步而造成逻辑分离。7）API系统的设计。目前模型变更和状态传播都是通过大量代码嵌入，对流程维护不够友好，侵入性强。8）代码的容错处理不够健壮，有些函数执行失败，但是返回200。相信在任何开发一些业务需求的场景下，或多或少都会遇到这8个地方的问题，这也是我最近练习优化的一个变更面板。在今天整理这些问题的过程中，逐渐理清了一些思路，少走了一些弯路和返工。当难以进行时，我总是在休息的时候得到一些应对的灵感。所以整体来说，我是在做自我创新，这个过程也会让我从Mr.Almost转行。在这些任务中，如何沉淀设计和模型设计的思路，取决于我对功能和设计的逐步细化和追求。
