我们应该编码性能还是稳定性？
在某个时间点，你会做出设计选择，并与管理层进行辩论。就我而言，我必须与高级管理层就我的职位和设计选择进行辩论，但令人沮丧的是，管理层只追求业绩，而我认为稳定是必须的，而业绩可以在以后实现。
例如，由于某些进程缺乏事务性，我们面临着一种设计上的选择，即制定一种恢复机制，即我们需要保证这些进程的事务性，使它们完全完成，或者回滚它对数据库所做的更改。当前的代码使得这很困难，因为我们正在使用存储过程来管理自己的事务。这意味着，如果进程调用3或4个存储过程，则存在3或4个事务，如果我们希望恢复过程，则需要回滚这些更改(是的，它们当时已提交，这意味着我们需要对数据库进行更多事务处理，以便使其处于一致状态，或者至少以某种方式“忽略”这些记录)。
当然，我希望从存储过程中删除事务，并在流程结束后在代码中提交事务，如果流程有异常，则将其回滚。
实际情况是，管理层认为这种方法会使流程变慢，并且会对我们的代码产生很大影响。我认为这是正确的，但我也认为，使回滚过程本身显然是重新发明车轮，容易出错和IMHO，它将需要太多的时间来稳定。
那么，在前面的例子之后，在这种情况下最有益的方法是什么呢？我的意思是，我想要一个双赢的局面，但我认为这显然是不可能达成一致的，因为每次我想谈论这个问题时，我都会得到这样的回应：“应该有另一种方式”、“你不应该告诉我没有办法”、“这是不可能的”、“业绩会下降”等等，我想我会结束让这个假象恢复的过程只是为了遵守管理。
OTOH，我可能是错的，我应该不抱怨地做别人告诉我的事情。
回答 4
Software Engineering用户
发布于 2013-09-14 09:51:36
我想，这里关于PSE的所有好建议--宁愿使用可维护的代码而不是快速代码--只要你们都有自己的意见，而不是事实，就不会说服你们的管理层。这是我的建议，你可以在你的具体情况下采取行动。
由于存储过程自己提交而无法控制外部事务，因此很难在组合进程中重用该过程(这对于任何类型的代码更新数据库、存储过程都是如此)。我认为这通常是一个严重的设计错误，通常是由初学者造成的(但我经常从或多或少“经验丰富”的开发人员那里看到这种情况)。
情况是，管理层认为这种方法...将在我们的代码中产生很大影响。
当然，它会影响您的代码(它将增强其设计)。但是在大多数情况下，IMHO可以以某种方式重构现有代码，破坏代码的风险并不太大。对于这些存储过程中的每一个，添加一个参数(例如bool autoCommit)，该参数允许选择性地关闭提交。将启用提交的操作设为默认(通常对现有代码的影响很小)，并确保到目前为止没有中断任何操作。
然后，制作代码的测试版本(或者至少是一个有代表性的示例)，它使用新特性从外部控制事务。这给了你一个衡量绩效影响的机会--并证明或否定管理层的反对意见。这还将允许直接比较旧代码和新代码，以显示新解决方案有多好。
稍后，您可能会考虑将更改的过程重构到不再需要autoCommit参数的状态。
Software Engineering用户
发布于 2013-09-14 06:42:57
按照优先级顺序，代码应该是可维护的、有效的和有效的。
没有必要让高性能代码不做它应该做的事情(有健壮性)，而且每当您遇到错误或性能问题时，可维护性就会产生影响。我没有数据库方面的经验，但如果这个原则也不适用于数据库，我会感到惊讶。
现在最困难的是让管理层接受这一点。顺便问一下，表演到底是个问题吗？
Software Engineering用户
发布于 2013-09-14 09:45:53
你要寻找的是两件事:正确性和效率。正是如此，充分的简单性将给您提供明显的正确性，并使效率易于实现。
然而，你的系统已经过了很久了。除非有一些彻底不同的方法来解决这个问题，这将大大简化事情，实现正确性和效率都将是困难的。如果您想从相同的代码中同时出现这两种情况，则很可能会失败。
这里唯一的方法是使用测试。您将有一个单独的简单代码体，这些代码与效率无关，而与正确性有关。一旦您的测试就绪，您就可以实现实际的解决方案，并与其进行斗争，直到它足够快，而所有的测试通过。
https://softwareengineering.stackexchange.com/questions/211470
复制相似问题
腾讯云开发者
