unit-testing - 考虑到增强和重构业务关键应用程序的任务，对开发人员有什么建议吗？

Question

最近，我在工作中继承了一个业务关键项目以“增强”。在过去的五年中，该代码已被开发并通过了许多人的手。不再在公司工作的顾问和全职员工扼杀了这个非常微妙和过于敏感的应用程序。我们大多数人都必须处理遗留代码或此类项目......这是作为开发人员的一部分......但是......

有零单元和零系统测试。逻辑在存储过程、 View (是的，我说的是 View )和代码之间相互混合(有时无缘无故地重复)。文档？是的，对。
我害怕。是的，即使是最小的“调整”或重构也是非常神圣的。一个小事故，我的雇主就会遭受重大的收入损失和潜在的法律问题。

那么，有什么建议吗？我的第一个想法是开始针对现有代码编写断言/单元测试。然而，这只能到此为止，因为存储过程中嵌入了很多逻辑。 (我知道它可以测试存储过程，但从历史上看，它比单元测试源代码逻辑要困难得多)。
另一种或附加的方法是比较应用程序执行功能之前和之后的数据库状态，进行一些代码更改，然后进行数据库状态比较。

Answer 1

我只是重写了企业文件系统最复杂的子系统的数千行，使其成为多线程的，所以所有这些都来自经验。如果重写是合理的(如果重写是为了显着增强功能，或者如果现有代码阻碍了更多增强)，那么这里是指针:

你首先需要对自己的能力有信心才能做到这一点。只有当您对所涉及的技术有足够的经验时，才会出现这种情况。

沟通，沟通，沟通。让所有相关的利益相关者知道，这是一团糟，这是有风险的，这不能匆忙完成，这需要零碎完成——一次攻击一个区域。

由内而外地了解系统。记录每一个细微差别、技巧和技巧。记录整体设计。向任何老前辈询问您无法证明的任何代码存在的历史原因。这些是你不想踩的地雷——你可能会认为那些是无用的代码，然后在摆脱它们后后悔。

单元测试。通过任何已经存在的测试套件运行系统，否则首先为现有代码编写测试，如果它们不存在。

在重写过程中到处喷出调试代码 - 断言、日志记录、控制台打印(您应该能够打开和关闭它们，以及指定不同级别的输出，即控制详细程度)。根据我的经验，这是必须的，并且在重写期间有很大帮助。

浏览代码时，列出所有需要做的事情——你需要找出的事情、需要编写测试的事情、需要提问的事情、提醒你如何重构某些部分的注释代码，任何可能影响你重写的东西......你不能忘记任何东西!我使用 Outlook 任务执行此操作(只需确保您使用的任何内容始终在您面前 - 这是我一坐在 table 上就打开的第一个应用程序)。如果我被打断了，我会写下我一直在思考的任何事情，并暗示在回到任务后从哪里继续。

尝试在重写中避免黑客攻击(这是您重写它的原因之一)。想想你遇到的棘手问题。与其他人讨论它们并将你的想法与他们相提并论(没有什么比这更好的了)，并提出干净的解决方案。查看您放入待办事项列表的所有任务 - 为现有设计制作 10,000 英尺的图片，然后决定新重写的外观(在模块、子模块、它们如何组合在一起等方面)。

先解决最棘手的问题。这将使您免于遇到在隧道尽头附近无法解决的问题，并使您免于后退。当然，您需要知道最棘手的问题是什么——因此，在您尝试现有代码时，最好首先记录所有内容。