模块开发和测试方法

Question

我在某个地方读到过，如果在初始阶段不解决，那么解决bug的成本就会增加。在创建程序时，我应该采用哪种方法？

1. 按模块划分程序开发。完成一个模块的编码。在开始编写其他模块之前修复该模块的所有错误。
2. 按模块划分程序开发。完成所有模块的编码。然后开始修复整个程序中的错误。

这些方法中哪一种更好，为什么？

Answer 1

你在某个地方读到的东西是真的。在开发软件时，您希望最小化所有反馈循环(这是敏捷/精益开发的主要原则)。你越早发现需要改正，就越容易(努力、冒险.)这将是作出这一修正。

因此，如果我必须在您列出的两种方法之间进行选择，我将使用(1)，一次开发/测试模块，因为另一种方法具有您可能拥有的最大的反馈循环。编写完整的程序，然后再进行测试，这是自找麻烦。

然而，我想向你们指出更多的事情：

你似乎认为“bug”是一个编码错误。是的，编码错误是错误，但是在构建软件时，还需要注意其他错误类型：

• 设计错误-您的代码按预期工作，但您的设计不工作。也许它太复杂了，也许它没有正确地解决需求。
• 需求缺陷--您的代码按照预期和设计工作，但是您对用户需求的理解是不正确的。有时候那个用户就是你。这可能会发生，你会想象你希望你的应用程序的外观和行为。然后，您为它创建一个UI，并发现您的原始计划是完全不够的，因为它不能解决(或优雅地解决)您的程序所要做的任何问题。

您的任何一种方法都不适合查找这些其他类型的bug。就像编写代码错误最便宜一样，一旦您决定了策略，在编写过多的代码之前，需求和设计bug也是最便宜的。在你的程序大部分完成之后，设计错误比编码错误要昂贵得多。而需求缺陷通常意味着您需要完全重写程序的一部分。

换句话说，想象一下你的程序是由几个模块组成的。您编写和测试第一个模块，一切看起来都很好。然后编写并测试第二个和第三个模块，结果仍然很好。然后，你把它们组合在一起，却发现A模块的设计并不足以有效地与B模块集成，所以现在你又回来了，重新设计、编码和重新测试模块A，你认为这已经完成了。时间将被浪费。

更好的方法是为您的程序提供高级架构(一般模块布局)。也许您有一个UI、一些业务逻辑、一些通信模块和数据存储。在所有模块中编写一个最基本的代码(本质上只是一个框架代码)，然后测试整个程序。即使它所做的只是在没有任何有用工作的情况下启动和关闭。确保启动正常。然后向程序中添加一个功能。此功能可能跨越许多/所有模块。测试以确保该功能正常工作。继续这样做，直到你的程序完成。

这样，在了解整个程序是如何结合在一起之前，您不会花太多时间在模块A上。您还可以看到实时UI，并且能够与其交互，因此如果需要更改，您将能够在编写过多其他代码之前进行调整。

Answer 2

管理bug解决方案确实需要逐案处理，并根据业务需求和bug本身的性质进行调度。

尽管如此，如果您在处理某些代码时发现了一个bug，并且该bug会影响您继续实现某个特性的能力，那么它可能会被相对较快地处理，因此被安排为一个优先级。但是，如果发现了bug但没有直接影响您正在实现的特性，那么您需要对其进行日志记录，并至少进行一些调试以确定所发现的bug的范围和严重程度，然后相应地在迭代结束时，或者在项目的末尾，或者在发布后维护的一部分(如果bug不太可能出现，或者本质上不太严重的情况下)进行相应的调度。

理想情况下，我们都会编写没有bug的软件。然而，我们最接近这一理想的方法是编写软件，以确保尽可能减少出现bug的机会。这就是以下理想的地方，如坚实的、干净的代码、行为/测试驱动的开发、YAGNI、重构和所有其他可爱的小嗡嗡声--我们如此沉迷于这些词可能会有很大的好处。特别是，关键是保持我们的设计和代码的简单，精简，并尽可能干净，并具有高度的测试覆盖率。从本质上说，提前解决问题是为了避免错误过早失控。

当然，您永远也无法真正克服那些由于需求理解不足和逻辑不完善而产生的bug，但是从一开始就有一个好的方法来开发健壮的软件，您将有效地减少以后可能需要进行的bug搜索的数量。

Answer 3

延迟修复bug通常有两个问题: 1)您不知道修复它们需要多长时间；2)依赖于bug部分的代码的其他部分要么也会有错误，要么在bug修复之前很好地工作(然后变成bug)。

对于第一个问题，重要的是要跟踪并确定bug的优先级，因为在实践中，很难修复当场遇到的每一件小事(尤其是在最后期限内)。如果某个bug必须在发布之前修复，那么就尽早修复它，这样您就可以更好地管理您的计划(消除不精确的任务，更精确的任务将更容易管理)。

但是，第二个问题非常重要:除非您的设计特别清楚(以便跟踪程序的哪些部分取决于其他部分)，否则延迟修复bug可能会带来更多的问题，并且随着时间的推移，情况会变得更糟。由于这个原因，在修复bug之前开发依赖于它的模块往往是一个麻烦的处方。

因此，我对您的问题的回答是:在进入下一个模块之前，您不一定需要修复模块中的所有but，但是如果模块B依赖于but模块A，那么在开始编写模块B之前，修复A中所有已知的but。