随着时间的推移，您如何跟踪现有的需求？

Question

我是一个软件工程师，在一个复杂的，正在进行的网站上工作。它有很多移动部件，以及一个由UI设计人员和业务人员组成的小组，增加了新功能，并对旧特性进行了调整。在过去的一年左右，我们增加了数百个有趣的小边缘案例。规划、实施和测试它们不是一个问题。

当我们想要重构或添加另一个新特性时，问题就会出现。没有人记得一年前的一半旧的特征和边缘的情况。当我们想要添加一个新的更改时，我们注意到代码在其中做了各种各样的事情，我们不完全确定哪些是有意的需求，哪些是毫无意义的副作用。去年是否有人要求登录令牌只有效30分钟，或者有些程序员只是选择了一个合理的默认设置？我们能换一下吗？

回到最初设想该产品时，我们创建了一些描述站点工作方式的文档。从那时起，我们创建了一些描述新特性的额外文档，但是没有人会在请求新特性时返回并更新这些文档，因此唯一权威的文档就是代码本身。但是代码没有提供任何理由，也没有采取行动的理由:只有如何，从来没有原因。

其他长期运行的团队会做什么来跟踪需求是什么以及为什么？

Answer 1

单元测试是你的朋友。

编写单元测试的主要原因之一是保护代码不受未来更改的影响。如果您将单元测试附加到每个所需的行为，那么将来的增强就不可能导致代码做“奇怪的事情”。

有趣的是，单元测试也成为程序员发现很难维护的活文档。如果您有一个名为DisableAccountAfterThreeWrongPasswords的单元测试，那么需求就会在那里捕获。如果您将来将它更改为四个错误的密码(比方说)，那么测试将失败，您将被迫更新它--大概还有测试名称。

当然，将单元测试添加到复杂的遗留系统中并不容易，代码通常需要以一种使其可行的方式进行架构设计。首先，我将重构代码中最“僵化”的部分，并在重构时创建测试，然后在继续增强应用程序时扩展测试集。

Answer 2

我希望您有一些VCS (最好是DVCS) -提交消息和更改日志是一个很好的起点。

创建内部Wikis文档太重，无法编辑和维护。(但Sharepoint 2010是一个例外，如果使用正确)。在高层次的设计决策中，努力保持这些更新(这不需要太大的努力)。

拥有一个良好的bug/特性数据库(如JIRA )，并保持当前工作的更新。其中最好的部分是提供的历史。通过复制粘贴邮件/团队会议记录来创建任务/bug。

添加大量的代码注释，并引用上面的bug数据库。

使用代码评审工具检查您的代码，在那里维护cr注释。将JIRA任务链接到此，从而确保您能够记住您的代码决策。

备份一切！:)