运维开发和测试中常见的8个问题

今天，我把精力集中在一些后端功能的转换上。在这个过程中，我探索了一些实践经验。

首先改造了后端基本函数，即通过数据库连接执行SQL语句。原始模式只支持一条SQL语句。在执行多个SQL语句时存在一些兼容性问题，所以它耐心地开始不断改进。最后，该功能已被改革为更常见的实现模式。

所以对我来说，这种转变的一个深刻见解是，技术上的改进实际上与健身相似，感觉功能几乎可以得到支持，并且可以被使用。然而，在随后的扩张中，动力会少得多。最近，如果你练习平面支撑2分半钟，那么1分半钟的开始时间将是最困难的，你想一直放弃。然而，如果你有一个明确的目标，你将有一个基本的要求和动力。

继续实现这个想法。事实上，有许多事情可以改进。我也反思了这个过程，发现目前主要有以下几类问题:

1)测试环境和在线环境的数据大不相同，很多场景在测试环境中很难模拟。如果测试要尽可能完整，在线数据需要快速同步以方便测试。

2)测试环境较少依赖于许多过程的测试，因此它只能尽可能多地模拟一些基本过程。对于更复杂的功能，模拟测试需要更多的时间，如果重新加工，成本相对较高。

3)在集成和调试过程中，如果要将某个过程串在一起，需要做一些嵌入点和日志记录。这个过程被重复收集和存储，这是不够透明的。

4)目前，程序变更部署和发布没有管道模式，许多快速部署都是基于手动补丁模式。

5)应用编程接口层设计不够清晰。目前，许多应用编程接口会在需求变更时对接口细节进行一些调整，所以文档与实现是不一样的。

6)在集成应用编程接口和工具类时存在冗余。目前，一个重要的需求方向是实现一些应用编程接口。如果它是一个基本的函数部分，它不仅可以通过应用编程接口调用来设计，还可以通过工具类方法来设计。然而，应该在代码的逻辑层实现无缝切换，以便只有一个代码源，并且逻辑分离不会由变化的同步引起。

7)目前在应用编程接口系统的设计中，模型的变化和状态传播是通过大块代码嵌入的，这不利于过程维护，并且具有很强的侵入性。

8)代码的容错处理不够健壮。有些函数仍然无法执行，但是返回了200个。

我相信只要有一些业务开发场景，这8个地方的问题都会或多或少地得到解决，这也是我最近想练习优化的一个变更面板。

在今天整理这些问题的过程中，我逐渐整理了一些想法，走了一些弯路，重新加工了它们。当很难继续下去时，我总是会在休息时得到一些处理的灵感。所以总的来说，我正在进行自我创新，这个过程也将使我从几乎先生转变。

在这些工作中，如何安顿设计思想和模型设计思想，我想我仍然要依靠我对功能和设计的逐渐提炼和追求。