我的任务是为我们公司的内部测试标准和程序制定一份文件。我一直在做大量的研究并找到了一些不错的文章，但我总是喜欢在这里与社区联系以获取意见。
话虽如此，我的问题是：你如何让一家拥有非常大的遗留代码库的公司，如果完全可测试的话，并尝试有效地测试你可以测试的东西？对于如何为紧密耦合的代码创建一些有用的自动化测试用例，您有什么建议吗？
我们所有的新代码都被编写为尽可能松耦合，我们都为新开发的方向感到自豪。作为记录，我们是一家从 VB 过渡到 C# ASP.NET 开发的 Microsoft 商店。
问问题
39 次
1 回答
0
这个问题实际上有两个方面：技术和政治。
Michael Feathers 的《有效地使用遗留代码》一书中对技术方法进行了很好的定义。由于您无法一次测试整个代码块，因此您可以沿着想象中的非架构“接缝”将其破解。这些将是代码中的逻辑阻塞点，其中一个功能块似乎与代码库的其余部分有些隔离。这不一定是拆分它的“最佳”架构位置，而是选择一个可以自行测试的隔离逻辑块。此时将其拆分为两个模块：大部分代码和您的独立函数。现在，在该点添加自动化测试以执行隔离功能。这将证明您对逻辑所做的任何更改都不会
现在您可以按照 SOLID OO 设计原则、DRY 原则等去重构隔离逻辑。Martin Fowler 的 Refactoring书是这里的绝佳参考。在重构时，将单元测试添加到新重构的类和方法中。尽量保持在您创建的拆分所绘制的“线后面”；这将有助于防止兼容性问题。
您最终想要的是一组结构良好的完全单元测试逻辑，遵循最佳 OO 设计；这将附加到一个临时兼容层，该层将其连接到您之前切割的接缝。对其他独立的逻辑部分重复此过程。然后，您应该能够开始加入它们，并丢弃临时层。最后，你会得到一个漂亮的代码库。
提前注意，这将需要很长时间。从而进入政界。即使您说服您的经理改进代码库将使您能够做出更好/更便宜/更快的更改，但他们的上级主管可能不会同意这种观点。高管们看到的是，重构代码所花费的时间不是用于添加请求的功能的时间。他们并没有错：你和我可能认为必要的维护并不是他们想要花费有限预算的地方。在他们看来，即使维护成本很高，今天的代码也能正常工作。换句话说，他们在想“如果它没有坏，就不要修理它。”
你需要向他们展示一个重构代码库的计划。这将包括方法、涉及的步骤、您看到的大部分工作以及估计的时间线。在这里提出替代方案也很好：完全重写会更好吗？你应该改变语言吗？您是否应该将其移至面向服务的架构？您是否应该将其移动到云中，并将其作为托管服务出售？所有这些都是他们应该在高层考虑的问题，即使他们今天没有考虑这些问题。
如果您最终让他们同意，请立即升级您的工具并建立一个现代开发链，其中包括同行代码审查和自动化单元测试执行、打包和部署到 QA 等实践。
我亲自在这棵树上吠了 11 年，我只能向你保证，这非常不容易。它需要在您组织的技术阶梯的顶端进行一路变革：CIO、CTO、开发高级副总裁或任何人。您还必须说服您的技术同行：您可能有些人对旧产品有着悠久的历史，但他们并不想改变它。他们甚至可能将您对其当前状态的抱怨视为对他们作为编码人员技能的人身攻击，并可能会破坏或沙包您的努力。
我真诚地祝你一切顺利，但愿你的事业好运！
于 2017-08-15T17:34:44.667 回答