运维开发和测试中常见的8个问题
这是学习笔记的第 2167 篇文章
今天集中精力，一门心思来做一些后端功能的改造，在这个过程中摸索出了一些实践经验。
首先改造的是一个后端的基础功能，即通过数据库连接执行SQL语句，原有的模式只支持一条SQL语句，对于多条SQL语句的执行存在一些执行的兼容性问题，耐着性子开始持续改进，总算是把这个功能改造成为一个较为通用的实现方式了。
所以这个改造对我来说，其中的一个感悟是：技术改进其实和健身差不多，感觉功能可以支持了，差不多了，能用就行，而在后续的扩展中就会发现少了很多动力，最近练习平板撑，如果坚持2分半钟的话，那么1分半开始的时间就最为艰难的，时刻都想放弃，但是如果有了一个明确的目标也就有了一个最基本的要求和动力。
顺着这个实现的思路往下展开，其实可改进的事情就有很多了。我在这个过程中也做了反思，发现目前主要有以下几类问题：
1）测试环境和线上环境的数据差异较大，很多场景在测试环境难以模拟，如果要尽可能完整的测试，需要快速的同步线上的数据，方便测试。
2）测试环境的少了很多流程的测试依赖，所以只能够尽可能模拟一些基础流程，对于一个较为复杂的功能想要模拟测试，花费的时间比较多，而且如果返工，代价比较高
3）在集成和调试的过程中，如果要把某一个流程串起来，需要做一些埋点和日志记录，这个过程收收放放得反复进行，不够透明
4）程序的变更部署发布目前没有pipeline模式，很多快速部署都是基于手工补丁的模式。
5）API层的设计不够清晰，目前很多API在需求变更中会对接口细节做一些调整，所以文档和实现不大一样。
6）API和工具类的集成存在冗余，目前的一个重要需求方向是对于一些API的实现，如果是基础功能部分，其实不光可以通过API调用，也可以通过工具类的方法来进行设计，而在代码的逻辑层应该可以做到无缝的切换，这样代码的源只有一份，不会因为变更的同步而导致逻辑分离。
7）API体系的设计，目前对于model的变更和状态传播都是通过一大坨一大坨的代码来嵌入，这对于流程维护来说不够友好，而且侵入性较高。
8）代码的容错处理不够健壮，有些功能还有执行失败，但是返回200的情况。
这8个地方的问题我相信但凡有一些业务需求开发的场景都会或多或少碰到，而这也是我最近要践行优化的一个变革面板。
在今天整理这些问题的过程中，也逐步理清了一些思路，也走了一些弯路和返工，在难以进行下去的时候，总是在休息的时候会得到一些处理的灵感。所以整体来看，是在做自我的革新，而这个过程也会让我从差不多先生转换过来。
这些工作中，怎么把设计思想和模型设计的思路沉淀下来，我觉得还是得靠自己对于功能和设计的逐步细化和追求。
近期热文：
迁移到MySQL的业务架构演进实战
数据库修改密码风险高，如何保证业务持续，这几种密码双活方案可以参考
MySQL业务双活的初步设计方案
如何优化MySQL千万级大表，我写了6000字的解读
一道经典的MySQL面试题，答案出现三次反转
业务双活的数据切换思路设计（下）
业务双活的数据切换思路设计（一）
MySQL中的主键和rowid,看似简单,其实有一些使用陷阱需要注意
小白学MySQL要多久?我整理了10多个问题的答案
转载热文：
《吊打面试官》系列-Redis基础
唯一ID生成算法剖析，看看这篇就够了
关于大数据运维能力的一些思考
DBA菜鸟的进化简史：不忘初心，记工作中踩过的三个坑
美女主持直播,被突发意外打断!湾区网友却高喊: 我懂!超甜
QQ群号：763628645
QQ群二维码如下， 添加请注明：姓名+地区+职位，否则不予通过
点在看，让更多人看到