“尽早发现”就是尽量在缺陷的注入阶段就发现缺陷，不让缺陷注入到下一个阶段。那么我们有什么办法来做到尽早发现呢？到目前为止，我们已经有足够的知识积累来解答这个问题啦。上一讲我们了解了缺陷发现的主要方法有”评审“和”测试“。
我们先来聊下“评审”。评审是可以针对任何成果物的。同学们应该想到了：为了尽早发现，我们只需要在成果物完成后，尽快对成果物进行评审，就可以尽早发现成果物中的缺陷了。软件开发“流水线”涉及的成果物很多，比如：PRD文档，UI图，设计文档，测试用例等等，这里就不再一一列举啦。
接下来我们来看“测试”。测试是缺陷发现的重要方法之一，但是处于软件开发瀑布模型中靠后的环节。我们想要尽早测试，但是他就是排在后面怎么办呢？我们在《第5讲：软件开发中的“流水线”》中已经介绍了瀑布模型的升级版“V模型”，将用例的编写提前完成。编写用例时，需要一些更细节的信息，这样就反过来使得需求，设计文档中的缺陷被尽早的发现了。这一段如果不大理解，可以重新复习下第5讲。另外，关于测试大虾再扩展下，我们一直说的“持续集成”，“尽早集成”其实也是为了尽早暴露出缺陷，而不是等到项目后期，把代码统一合并。大虾经历过那个年代，的确是噩梦。
不要以为这样就完了。目前我们谈到的尽早发现是从需求文档的尽早评审到测试结束的整个过程。而我们漏掉了“流水线”中非常关键的一环，需求文档是否能正确反映客户的真实需求。毕竟我们之前也提到过的：“软件质量是指软件满足用户需求的能力，而不是多数程序员认为的 – 满足需求文档的能力。” 那么我们该如何解决这个GAP呢？有一个建议就是“快速原型”，尽快的做出可以点击操作的原型，然后让客户有直观的感受，这样再沟通起来就方便多了，不仅可以减少误解，客户也更容易提出自己的想法。
最后，大虾再举一个尽早发现的例子，这个已经不属于我们“软技能”的范畴了。不知道同学们是否和大虾一样，相比运行时出异常，我们更希望编译器在编译阶段就帮我们检查出错误。当然如果以后编译器发展到，我刚开始写错时就纠正我，那就更棒啦。
综上所述，我们可以看出：很多工具，模型，理念等等的发展，都是为了缺陷的尽早发现。我们在项目中也要多思考怎样能让缺陷尽早暴露出来，并尝试往这个方向努力。
下一讲我们将介绍 – 如何衡量“尽早发现”做得好还是不好“。敬请期待！“尽早发现”马上就要讲完了，后续章节我们会介绍《第7讲：高质量的秘诀 – 六句真言》中涉及到的其他5句“真言”。后续更加精彩，记得关注大虾，不要错过更新哈。