容错

　　在部署的时候也需要考虑的，就是你还需要考虑如果你的应用崩溃后，将会发生什么。应用最好在系统监测程序下受控，例如Ubuntu的upstart。配置upstar十分琐碎，但可以在应用崩溃时，处理开始，结束，和重启，所以还是值得的。Foreman有一个导出功能，可以为你的foreman-backed应用生成upstar配置。

　　即使应用可以在崩溃后重启，但是这样做的含义是什么?这样会让服务在某些时候中止么?会丢失数据么?会留下一些为完成的任务么?一串问题你需要在设计时考虑，冗余是一个很好的解决方案。例如，你需要在多台服务器之间传输数据，可以考虑增加一个反向代理(负载均衡，例如 HAProxy 或者web服务器，例如 nginx)，从负载中移除应用中的不完善实例，直到健康检查达到合格分数为止。

　　效率和可伸缩性

　　也许在开始阶段我们很少考虑，但随着你的应用的成长，事务压力会不断增大，你也许需要考虑让应用变得更高效，甚至是可伸缩性。这里存在的风险是过早的优化。你不需要担心让你的应用拥有超强的可伸缩性或者拥有超级性能，因为在真正面对这么高的负载的之前，你为什么为此而苦恼呢?你还是把最宝贵的时间放在核心组件的构建上，或者"最小的可行性"，就如，刚开始启动，至少先到达需要扩展的阶段。

　　当你的应用在单节点和单实例的情况已不能满足需求的时候，你有几个选择，所有的权衡，就像在雷区中摆布一样。首先要做的是，找出瓶颈。为什么应用会那么慢?是不是CPU占用率已达到顶峰值?是不是硬盘I/O不够大或者是否足够的连贯?

　　有时候最直接的答案是把应用迁移到拥有足够资源的服务器上。如果这对于你来说，是可行的，那么任务就比在多节点上重新架构你的应用要简单的多，但是如果应用增长速度很快，那这个可不是最好的解决方案。但是这个方法可能会消耗你大量的时间去构建。

　　在多个服务器上横向扩展应用，是一个棘手的方案，并且引入大量的错误，但是长期来说却带来生命力和令人着迷的技术挑战。

　　文档和组内协作

　　一个应用如果没有文档，就像一个包装盒没有说明书一样。你可以找出需要做什么，但这样做是笨拙的，浪费时间和不精确的。最好你能提供清晰的文档描述，简要说明你的代码。这样做不单单是帮助其他人很快的上手和快速的开发，而且还能帮助你在六个月后重新拾起这个应用，修复臭虫。

　　我并不主张像写小说或者教程一样去描述你的代码。很多代码可以自解释，只要代码足够的简洁。相反，你的文档需要描述的是，代码未能解释的灰色地带。注释可以描述代码的功能性，还有描述设计的理念，平衡，依赖，陷阱，边缘例子和其他需要考虑的东西。随着应用的成长，代码的描述文档也会增长，以反映应用变得越来越稳定的过程。在应用还处于初级阶段的时候，没必要太投入去编写文档。因为文档在初期会经常改变，当你花了很多时间在它身上的时候，可能会很快又被废除掉。

　　每个应用程序都应该包括一个README[MD]，其中包含所有需要知道是应用程序正常工作的细节。通常这包括：

　　应用程序其目的的简短说明

　　• 安装说明

　　• 启动说明

　　• 测试说明

　　• 如何部署

　　• 其他需要知道的点

　　我们需要一个模块提前代码里的注释并生成干净，有吸引力的文档。我们会使用一个叫 docker 的模块在我们的app中。

　　测试

　　以前我压根没有认识到测试有多么重要，也没有被(QA)烦过。可能是因为我(太牛了)从来没有遇到这样悲催的情况：多年以后，之前开发的应用开始出问题了，你无法保证哪部分还正常工作，哪部分就快瘫了。可是现在，经历过这些狗血的事情后。我知道，我们需要测试，我们需要伟大的QA!

　　严格的测试可以造就好的应用。你需要考虑横向地把应用切分为组件，而让组件可以单独的测试。这超越了基本的单元测试的迂腐，包含更多信息的组件和集成测试，可以让你找到一个方法，以保证你的应用可以很好的集成在一起工作。

　　最好的方式是在你开发应用的时候编写测试用例(一旦你有足够的信心，你测试的功能不再有变化)，那样随着应用的开发进程，测试也可以得到足够的保证。这样可以保证在开发新的功能的时候不会打断现有的功能。测试同样给其他开发者提供一个很好的例子，理解应用各个组件如何工作和结果是什么。

　　现在有大量的测试框架可供选择，不同的技术( BDD, TDD). 我们尝试过 vows 和 tap，但是我目前更喜欢用 mocha和 should.js，因为我觉得使用它们，比使用纯javascript，更能平衡架构和工具，同时允许使用同样的代码库，脚本文件，而且还能在你的测试用例中启动服务器。

　　依赖

　　Node拥有一个强大的模块系统和被称为npm的包管理工具，npm能帮助你无缝的集成各种模块到你的应用中。npm给你提供了一个非常丰富的开源模块的目录 索引，你可以找到你想要的。

　　一旦你知道你的应用需要什么组件(例如和redis数据库沟通的是什么客户端)，明智的选择是首先检查现有的配置索引中的用户级节点模块。Node.js是黑客们中最喜欢的实验工具，所以这里有很多模块可供你尝试。自然，这些组件的质量都不一样，所以你需要了解哪些是好的模块，哪些却不是(名单：README， 测试，例子，作者)，但是基本上可以提供给你所有你需要的。