背景

去年下半年，我在微信书架里加入了许多技术书籍，各种类别的都有，断断续续的读了一部分。

没有计划的阅读，收效甚微。

新年伊始，我准备尝试一下其他方式，比如阅读周。每月抽出1~2个非连续周，完整阅读一本书籍。

这个“玩法”虽然常见且板正，但是有效，已经坚持阅读九个月。

已读完书籍：《架构简洁之道》、《深入浅出的Node.js》、《你不知道的JavaScript（上卷）》、《你不知道的JavaScript（中卷）》、《你不知道的JavaScript（下卷）》、《数据结构与算法JavaScript描述》、《WebKit技术内幕》、《前端架构：从入门到微前端》、《秒懂算法：用常识解读数据结构与算法》、《JavaScript权威指南》、《JavaScript异步编程设计快速响应的网络应用》。

当前阅读周书籍：《编写可测试的JavaScript代码》。

现有技术篇

敏捷开发

敏捷开发是大量实践中一个比较大的方法。敏捷方法主要是应对软件应用程序开发的“瀑布”模型，瀑布模型开发使用离散性的序列化过程。例如，瀑布模型首先是需求规范编写，接着程序员编码、测试人员测试、应用程序部署，然后回头重新更新新的需求。该过程的每一步都是连续且独立的。因此，编写需求规范时，程序员和测试人员都要等待，程序员编码时，测试人员再等待，而测试人员在测试的时候，所有人都在等待，等等。

敏捷开发尝试以更加灵活的方式让每个阶段都并行发生。软件能用是首要任务，与其花大量的时间等着上一步的完善交接，不如每个团队进行短周期的迭代，以便时刻都有事做。大量的工作被分解成可以预估的小块。敏捷开发尝试打破开发周期内每个小组的壁垒，这样他们可以一起工作，从而减少相互之间交接的时间。与客户沟通有助于确定最终的交付成果。

注意，使用敏捷开发方法，并不一定意味着应用程序完成得更快且质量更高。敏捷开发的最大优势是它处理需求变更的方式。在瀑布模型中，任何改变都需要贯穿整个过程。敏捷开发的短周期允许变更，以便将这些变更整合到最终的产品中。如果你听说过fail fast、release often、backlog、standup或者和continuous相关的词语，你可能已经在使用敏捷开发了。某种程度上，大多数现代开发都使用敏捷开发。

基本思想是：快速迭代和持续交互可以加快高质量软件的交付。

敏捷开发本身没有提到如何编写软件，相反，它建议了一些适合敏捷哲学的方法。例如，“用户故事（user story）”是由“用户（user）”描述一个应用程序该有的特性的句子。这些故事是用户想在应用程序中体现的产品特性。使用你的应用程序或API的用户，可以是普通的用户，也可以是能够帮你定义最终产品的另外一组开发人员。结对编程是一种经常与敏捷开发一起使用的开发方法。结对编程最纯粹的形式就是两个程序员坐在同一张桌子旁，看同一个屏幕、键盘以及鼠标，一起进行编写软件。其中一个开发人员敲代码，而另一个开发人员则积极调试和思考代码。两个大脑通常比一个更聪明，与两个人单独进行编码相比，结对编程能够更快地发现并解决问题。

测试驱动开发

测试驱动开发（TDD）是敏捷软件开发的推荐做法。TDD希望在编写代码之前先编写测试。这些测试提供了必须遵循预期功能的代码。编写测试失败后（刚开始还没编写代码肯定会失败），接着开始编写代码，以便确保测试能够通过。保持测试领先于开发，永远不会有未被测试的代码，至少这是TDD的理论。在现实中，往往开始时，开发人员会沿着这条路走，并开始编写测试，但很快功能代码就会超过测试代码。呵呵，至少你得到了一些测试！

在新建项目或模块时，使用TDD的效果显然是最好的。如果只是需要单元测试，那它也是最成功的。在编写代码之前，编写完整的集成测试是令人望而生畏的！TDD也为重写现有遗留代码提供了一个很好的理由或借口。如果开发人员在为“已存在的代码编写一大堆测试”和“在编写自己新代码的同时进行测试”中做选择，大多数开发人员可能会选择后者。当然，开发人员不一定只有一个选择，如果对现有已存在代码编写测试是下一步的话，那就不要指望他们能有开心的笑容以及很高的效率。

无论如何，TDD不是一件坏事；事实上，它可以是一件非常好的事情。TDD是一个伟大的开始，不管是整个应用程序还是一个单一模块—所有人都喜欢编写新代码，如果编写新代码之前的“成本”仅仅是先编写测试的话，那就随它去吧。因为开始时没有代码，所以编写测试的“成本”是最小的。

在2005年针对加拿大的大学生开展的一项有趣的研究发现，TDD使程序员更有效率，因为他们写了更多的测试。虽然这很有争议，但更有趣的是，研究人员也观察到，随着编写测试数量的增加，软件质量很少呈线性提高，这与采用的开发战略无关。最好是要知道，测试的数量和更高的代码质量是成正比的。从中能得出的结论是，任何能让开发人员在编码前、编码中、编码后进行编写测试的方法都是非常好的方法。

行为驱动开发

行为驱动开发（BDD）是在TDD的基础上发展而来的，它为开发人员和非开发人员提供了一种通用语言，用于描述正确的应用程序行为和模块行为，该通用语言是日常语言。例如，提供用于定义被测试模块的行为的描述，比如“如果购物车是空的就不能进行结账”，而不是写一个名为testEmptyCart的测试。使用通用语言定义的测试或预期，可以让任何人都能更容易地了解被测试的内容，并且有助于定义测试和期望应该是什么样的。

相对于代码，BDD是利用敏捷用户故事来定义测试。用户故事可以直接转化为测试。用户故事通常必须遵循特定的模板形式：作为一个[人/角色]，我需要[某些功能或权利]，以便能[得到相应利益或达到相应的结果]。

正确填写每个空白项，如作为一位Yahoo！Mail用户，我想将照片附加到电子邮件中，以便我的收件人都可以看到它。这个用户故事可以转化为Yahoo！Mail产品的一组功能需求和测试。

BDD对于获得非项目团队成员（技术人员或非技术人员）的正式反馈很有用，从而帮助你理解系统应该如何操作。用户故事通常可以直接转化成测试—或者任何可以促进集中测试（更多测试）的内容，这是一件非常好的事情！

总结

瀑布（Waterfall）、螺旋（Spiral）、敏捷（Agile）以及其他方法都很好用，但都没有产生可测试的代码，更不用说可测试的JavaScript了。同样，TDD、BDD以及其他形式的开发方式也不一定确保有可测试的JavaScript。怎样才可以确保生成可测试的JavaScript？确保编写出整洁、松耦合并有足够注释，且确保别人能够接手维护的代码，才能够编写可测试的JavaScript。编写、阅读和维护可测试的JavaScript并不一定需要测试驱动、行为驱动或任何其他“驱动”型的开发方式。然而，遵循任何强调与编码一起测试的实践是一件有益的事情。要谨记的最重要的事情是我们编写的代码并不是凭空存在的。前面编写的任何专业代码，都将被我们自己或者别人查阅、编译、调试，并最终使用。最后，我们编写出代码，让别人来维护、研究和使用。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。