如果把Node.js作为开发语言，做成一个最终的系统，除了编码的基础，我们还需要一些额外的东西，包括工程化、架构、容灾备份、部署和运维，只有这些都做好了，才称之为一个好的软件产品。
首先是目录结构，对于Web应用，组织方式有各种各样，但遵循单一原则即可，常见的Web应用都是以MVC为主要框架，其他部分都在这个基础上进行扩展，对于目录结构里的每个文件夹，都是分门别类好的。一些成熟的Web框架，例如Express，还提供了命令行工具来初始化Web应用，为开发者提供了一个较好的起点。里面有个特殊的文件夹node_modules，这个文件夹装的都是项目的依赖包，通常不加入版本控制里面，我们在一开始的时候通过npm install的命令来安装package.json里面的依赖包的时候会自动生成这个文件夹。
在项目成员数量较多的时候，多个人维护一个项目的情况很常见，这时候容易出现团队成员水平不一的问题，为了统一良好的编码风格，有助于帮助一旦早期不注重可维护性，后期项目代码的迭代和bug修复都会耗费巨大的成本的情况。解决的方法有两类，一种是通过文档来约定，一种是通过提交代码强制检查来约定，前者靠自觉，后者靠工具。Eslint的出现很好的解决了这个问题，它定义了代码的编写规范，一旦团队成员的代码不符合这个规范，则无法通过检查。
在实际的项目中，当开发者完成了代码的编写之后，如果直接部署到生产环境当中，会有很多不确定的因素，比如出现了一些隐藏的bug，会直接影响用户的使用，为了解决这个问题，我们需要准备一个测试的环境，先把代码部署到测试的环境，测试通过之后，再部署到生产环境中，这样可以减少bug的发生次数。
在真实的项目中，开发只是整个投入的一小部分，真正在线上运转起来的时候，问题会接踵而至，无论写多么缜密的代码，都会有bug的出现，与其后期修复它，不如多建立一些排除和跟踪的机制，而日志就是最常见的一种，在健全的系统中，完善的日志记录能够最快的定位和还原现场，通过日志来定位问题也是成本较小的一种方式。这种非结构化、轻量的记录方式容易实现，也容易扩展。
