编写可维护的JS

永远的偶像-孙悟空

0.

当你开始工作时，你不是在给你自己写代码，而是为后来人写代码。 —— Nichloas C. Zakas

本文主要是《编写可维护的JS》的读书笔记，和博客大牛的内容，以便自己在开发中也以这样的方式来要求代码，不像以前只单个考虑，现在是整体考虑。作者写这本书的时候（大概2012-2013年）ES6还没出来，考虑到当前MV*时代下，大家几乎都在写ES6，所以本文会针对ES6作特别说明（原书内容针对ES5）。原书作者结合自己的工作经验（2006年开始在雅虎为期5年的工作）写出了这本书，作者在书中浓墨重彩强调的东西，我们现在看来都稀疏平常（如：为什么需要禁用with和eval，为什么始终使用===和!==进行比较），在这些内容上我会一笔带过，假定你已经熟知这些基本常识了。

我们知道JS语言有着先天的设计缺陷（ES6之后才好转了不少），如何不刻意学习如何编写优质易维护的代码，你很容易就写出糟糕的代码（虽然它可以运行）。

• 关于代码的维护，你需要明白以下四点：
• 软件生命周期中80%的成本消耗在了维护上。
• 几乎所有的软件维护者都不是它的最初作者。
• 编码规范提高了软件的可读性，它让工程师能够快速且充分地理解新的代码。
  如果你将源码作为产品来发布，你需要确保它是可完整打包的，且像你创建的其他产品一样整洁。
  对的，你写的代码很大概率上，并不是由你来维护的。因为你可能换公司了，可能去做新项目了，也可能你压根就不记得这段代码是你六个月前写的。所以，不要抱着“我就是来搬砖的，随便写写，改不动了就溜了”的态度来写代码，相信读者你也维护过别人写的代码，吐槽过那难以理解没有任何注释的代码，恨不得把写那代码的人拉过来打一顿。所以，请不要成为你所讨厌的人。编写出可维护的代码，既是职业素养的问题，也是你专业精神的体现。

学习了作者：康斌他的链接：https://www.jianshu.com/p/bd4ae4a61af3

关于如何编写可维护的JS，我将从 编程风格 、编程实践 和 工程化 三个方面进行阐述。

程序是写给人读的，只是偶尔让计算机执行一下。 —— Donald Knuth

我们会经常碰到这两个术语：“编程风格”(style guideline)和“编码规范”(code convention)。编程风格是编码规范的一种，用来规约单文件中代码的规划。编码规范还包括编程最佳实践、文件和目录的规划以及注释等方面。本文集中讨论JS的编码规范。

为什么要讨论编程风格？每个人都有自己偏爱的编程风格，但更多的时候我们是作为团队一员进行协作开发的，统一风格十分重要，因为它会促成团队成员高水准的协作（所有的代码看起来极为类似）。毫无疑问，全球性的大公司都对外或者对内发布过编程风格文档，如：Airbnb JavaScript Style Guide, Google JavaScript Style Guide等，你若仔细阅读会发现它们很多规范都是相同的，只是部分细节略有差异。

在某些场景中，很难说哪种编程风格好，哪种编程风格不好，因为有些编程风格只是某些人的偏好。本文并不是向你灌输我个人的风格偏好，而是提炼出了编程风格应当遵循的重要的通用规则。