代码重要吗？当然，代码就是设计，代码是最有价值的交付物。但是，你真的会写代码吗？你写出的代码究竟应该怎样定义它呢？

好的代码，就像一本好书，写作技巧高超、耐人回味、文章分章明确、每一章都有清晰的主旨；又像是一辆配备了优秀音响和杯架的汽车，这辆车在行驶到最高速度的时候，你听不到噪音，也不用担心水会洒出来。在它出现故障的时候，任何一名修理工都可以使用最常见的工具，在最短的时间里轻松将其修好。 而不好的代码，就像是初出茅庐的作家写的书，各章节没有明确的主旨立意，纷乱错杂，通篇都在重复一句话，不明所以，故事设定不完整；就像是一辆向你承诺最高速度可以达到200MPH，但是音响只能播放老式的磁带，而且杯架还不稳的车。你在调整反光镜角度的时候，汽车都会突然出现故障，而且一般的修理工还修不了这辆车，必须要找专家，让专家在生产线上使用专业的工具来修理。

要想写出好的代码，你一定要牢记以下内容

• 可读性??不只是你，还有你身边与你合作的其他开发者

开发者大量工作时间并不是在编写代码，而是阅读代码，调试代码，查阅他人提交的开发文档，学习新的库等；当阅读代码时，开发者实际上是充当代码解释器的角色，在他们的头脑中执行代码，并试图记住当前执行状态。 这就是程序员在阅读代码过程中被打搅脾气暴躁的原因。

你应该意识到时间=金钱， 即使是一个努力工作的开发者，在做下面的事时仍然浪费了大量时间：

• 实现一些现在不需要，以后也可能永远用不到的功能。

• 做一些没有实际价值的改进。 例如，花费一周时间优化一个函数的执行时间，而该函数在1小时内仅被调用10ms的时间。

• 编写的代码难以调试，却还要试图从中找出错误。

• 编写的代码他人难以理解。 注意，“他人”也可能是短短一周后的你。

• 可维护性??让你的代码在修改的时候很简单

编写时可维护性：指在程序或系统上线后爆出 BUG，开发团队能够及时扑灭这个 BUG 且不会爆出其他 BUG。保持方法的原子性，提高代码内聚，能使某处修改的影响降到最低，这样某处方法出现 BUG，也不太会影响到其他模块的正常运作。编写时可维护性还包括了代码的「可测试性」。

JavaScript Module AMD 标准执行者（如 require.js）和 CMD 标准执行者（如 sea.js）要求谨慎使用全局变量，将变量限制于一个个模块之中，使得 JavaScript 代码变得更有条理且更便于维护。

运行时的可维护性：指在系统运行过程中（或无需再次编码发布、只需系统重启一次）修改系统的某项配置并使其生效，且不影响现在正在进行的业务和用户的操作。这要求软件工程师不能把代码写死。例如配置文件、数据库连接字符串、资源文件、日志等。

• 简洁性??不要让你的代码看上去毫无必要的复杂

我认为简洁性就是1个模块只做1件事情。把很多功能都放到1个模块中，只会带来麻烦。不仅仅是设计时，各种功能之间相互的缠绕把设计人员绕进去，也不利于代码的阅读，影响设计的维护。

• 效率性??尽可能的让你的代码获得最快的运行速度

对于每一个程序员来说，程序的运行效率都是一个值得重视，并为之付出努力的问题。那么到底怎么做才能提高代码的运行速度呢？我们可以试着通过尽量减少值传递，多用引用来传递参数；避免使用多重继承；尽量少使用dynamic_cast；多用直接初始化等手段来改变运行效率。

• 明确性??如果你的代码能够做到不解自明

在大多数时候，你根本无需为其配备说明文档。在为方法和属性命名的时候，做到尽可能的合理。把长的代码进行拆分。不要复制/粘贴代码块。

其实，好的代码就是是可读的，可理解的，覆盖了自动化测试的，不过于复杂，并且能办好我们需要它做的事情。” right？