背景

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

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

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

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

已读完书籍：《架构简洁之道》、《深入浅出的Node.js》、《你不知道的JavaScript（上卷）》、《你不知道的JavaScript（中卷）》、《你不知道的JavaScript（下卷）》、《数据结构与算法JavaScript描述》、《WebKit技术内幕》。

当前阅读周书籍：《前端架构：从入门到微前端》。

代码之旅，规范化开发

技术在不断演进，帮助我们不断地提高生产力、使流程规范化。过去我们手动下载依赖，现在可以一键安装依赖；过去需要单独进行测试，现在可以在提交代码后自动测试。随着我们不断地优化开发流程，这些工作越来越自动化。

基础规范

基础规范，它们更多地关注代码的可读性，而不是代码的质量。为了提升代码的可读性，我们需要做到以下几方面：

• 规范代码组织结构。
• 统一代码风格，即源代码的书写风格。
• 组件、函数等命名规范。
• 开发工具规范。

在这些实践中，有些并不仅仅是实践，它还反映了架构的模式，如代码组织结构——从代码的组织构建上，我们可以真真切切地感受到它与系统架构的相似之处。由于应用内的代码复用采用组件化的架构，所以我们应该隔离不同的组件。比如，在Angular生成的组件（component）中，我们就可以看到一种组件完全独立的存在形式。

代码组织决定应用架构

不同框架有不同的文件组织方式，不同团队也有不同的规范。

当我们定下了前端应用的架构时，我们应该按照与架构相似的方式来编写，以免随着代码架构的变化而腐烂。当架构在未来发生变化的时候，我们就需要相应地更改代码的组织方式。

统一代码风格，避免架构腐烂

真正了解一个项目代码的工作——阅读代码。迎面而来的是代码的风格、写法，然后才会注意到函数的实现。

作为一个工程师，每天不得不面对其他来源的代码，或从StackOverflow/Google上搜索到的代码，或从GitHub上复制的代码，又或者阅读别人的面试作业。看到代码的第一眼，可能就觉得这份代码不适合自己的口味。原因有很多，比如，代码里使用四个空格，而不是两个。在日常的工作中，如果你都不想多看几眼项目中别人的代码，那可就糟糕了。

使用Lint规范代码

为了规范代码，我们需要诸如TSLint及CSSLint类型的代码扫描工具。我们可以利用这些Lint工具，通过配置语法检测规则来对代码风格进行检测。也可以关闭所有的规则，只运行基本语法验证，这一切都取决于我们的意图。

对于代码风格来说，有太多需要规范的地方，比如下面这些事项：

• 是否以分号（;）结束语句。
• 缩进四个空格，还是两个空格。
• 判断是否相等的时候，使用===，以避免类型转换。
• 函数大括号是否换行。

通常，我们可以生成自己的配置选项，也可以使用其他团队、组织创建好的风格配置。比如，Airbnb创建的eslint-config-airbnb规范，对于编写JavaScript的人来说就相当不错。我们可以在它的基础上修改出符合要求的规范，从而节省大量的时间。

规范化命名，提升可读性

命名，对于程序员来说是一件相当头疼的事，对于英语不是母语的开发人员来说更是如此。为了取一个变量名，我们需要打开翻译软件、网站，输入对应的中文名，以获取可能的英语单词。再按自己的经验来决定使用哪个单词。即便如此，一个英文单词又可能拥有多个中文含义，我们又需要进一步翻译成中文。即便最后我们决定使用这个单词，在和其他程序员讨论代码的时候，可能还会对这些代码有一定的争议。

这个头疼的问题不是我们使用规范能解决的，但是我们可以通过制定命名规则来统一命名方法。

命名法

对于阅读代码来说，一个简单有效的函数名、变量名，远远比冗长的注释来得更加有用。而这些函数名、变量名本身应该也是容易阅读的，比如gettypebyid这种全小写的方式，对于开发人员来说相当不友好。如果读者也接触过不同的语言就会发现，语言间的差距不仅体现在使用上，还会体现在函数、变量的命名上。下面是几种常用的命名规则：

• 驼峰命名法，译自CamelCase，类似于骆驼的后背形状一样高低起伏。这个命名法来源于Perl语言，其展现形式是在单字之间通过首字母大写来展现，如“getTypeById”。在前端开发中，这种命名规则较为常见。
• 下画线命名法，即通过下画线来分割单词，如“get_type_by_id”就是采用这种命名方法。下画线（_）的分割方式非常显眼，它也更容易让开发人员区别单词。在Python语言中，这种命名方式特别流行。
• 匈牙利命名法，最初是由一个匈牙利程序员Charles Simonyi发明的，其命名规则是：属性+类型+对象描述。如“strFirstName”便是这样的形式，变量中的“str”表示这个变量的类型是string，再比如“iAge”中的“i”表示这个变量的类型是int。

CSS及其预处理器命名规则

除了代码，CSS的命名规则也是值得进行规范的。它存在于HTML文件和JavaScript代码中，以及自身的CSS文件中。

对CSS进行命名规范的主要原因是，如果不同页面、组件中定义的样式发生冲突，就会导致页面UI受到影响。而在诸如Angular这样的Web Components框架里，它会将一个组件内的CSS代码进行编译，使它只在自己的组件里生效。

在规模比较大、技术栈统一的前端团队里，会开发一套统一的编码规范。比如“Airbnb CSS/Sass指南”，它里面会定义一些常见风格的写法，并且会编写CSS Lint工具。

组件命名规则

对于团队而言，组件的命名规则也需要规范，特别是对于使用组件化框架的项目而言，有如下几种不同的命名方式：

• 按照功能来命名，比如SideBar就是一个侧边栏功能的组件。
• 按页面来切分组件，比如NewsItem就是用于展示新闻的组件，它既用于列表页，又用于相关新闻页。
• 按上下文来命名组件，如NewsChildItem就是按需要将上一个组件的某个共用元素拆分出来。

总结

本篇文章从浏览项目的代码开始，讨论关于代码不同部分的规范制定——从代码的组织架构、风格，到命名规范、开发工具等。

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