第一章 总则

第一条 目的

前端开发是一系列工具和流程的集合&＃xff0c;本规范旨在提升前端代码的质量&＃xff0c;对前端开发进行全方位指导&＃xff0c;统一编码规范、提高可读性、降低维护成本&＃xff0c;以实现高效、可持续的工作流。

第二条 范围

本标准适用于所有的Web应用及App开发。

第二章 开发规范

第三条 一般规范

应用在HTML、CSS、Javascript等的通用规则。

3.1 通用规范

3.1.1 技术选型

前端是一门发展中的技术&＃xff0c;标准、框架等更新速度快、调整幅度大&＃xff0c;技术选型时应考虑到开源技术中适用于当前项目的多种可能&＃xff0c;多角度考察比较&＃xff0c;并从中选取框架运行稳定的版本&＃xff0c;在技术储备充足时&＃xff0c;应兼顾考虑相对前沿技术。

3.1.2 目录结构

规范的文件目录结构有助于提高项目的逻辑结构合理性&＃xff0c;对应用扩展和合作&＃xff0c;及团队开发均有益处。
应用的核心框架、静态资源、脚本模块、上传文件等应分置不同文件&＃xff0c;严格遵循模块化开发的要求&＃xff0c;尽量做到规范化。不需要直接暴露给用户的文件&＃xff0c;应该放在web服务器访问不到的目录&＃xff0c;避免泄露设置信息。

3.1.3 文件资源命名

1).项目命名全部采用小写&＃xff0c;以下划线分隔&＃xff1b;
2).使用驼峰方式命名文件名与文件所在的文件夹&＃xff0c;便于统一配置&＃xff1b;
3).确保文件命名总以字母开头而不是数字&＃xff1b;

3.1.4 编码格式

通过声明一个明确的字符编码&＃xff0c;让浏览器快速确定适合的渲染方式&＃xff0c;通常指定为’UTF-8’。

3.1.5 文本缩进

采用四个空格或者Tab缩进&＃xff0c;不要混用。

3.1.6 代码注释

注释是对无法自我说明的代码进行解释&＃xff0c;注释可提高代码的可维护性、可读性&＃xff0c;开发人员应在必要时添加符合规范的注释。注释应至少包含方法、函数的作者/维护人&＃xff0c;描述&＃xff0c;出入参&＃xff0c;示例及维护日期等信息。如下场景必须添加注释&＃xff1a;

1). 核心代码及较晦涩部分。
2). 易存在错误的代码段。
3). 浏览器特殊的HACK代码。
4). 业务逻辑强相关的代码。

3.1.7 代码检查

对于Javascript这种弱类型的编程语言&＃xff0c;严格遵循编码规范和格式化风格非常重要。前端开发人员需严格遵循开发规范&＃xff0c;并使用自动代码检查工具(如ESLint)降低语法错误&＃xff0c;确保代码正确执行。
ESLint是一款检查JS代码是否规范的工具&＃xff0c;用来检查JS代码的规范性。它提供了配置的方法&＃xff0c;来检查不符合开发规范的错误&＃xff0c;并支持ES6语法。

3.2 HTML规范

3.2.1 文档类型

使用HTML5的文档类型声明&＃xff1a;。


3.2.2 脚本加载

出于性能考虑&＃xff0c;脚本应该异步加载。脚本引用写在body结束标签之前&＃xff0c;并带上async属性&＃xff0c;避免阻塞CSSOM执行。

3.2.3 语义化

使用合适的HTML元素&＃xff0c;可提高代码的渲染效率&＃xff0c;有利于提升SEO&＃xff0c;对于可访问性、代码重用、代码效率有重要意义。

3.2.4 关注点分离

结构、表现、行为分离是前端开发工程化的最佳实践&＃xff0c;为保持代码干净整洁可维护&＃xff0c;降低代码耦合度&＃xff0c;并进行工程化&＃xff0c;应严格遵循三者分离的规范要求。

3.3 CSS规范

3.3.1 选择器

1). 构建选择器时应使用清晰、准确、有语义的类名。
2). 选择器的设计应尽可能精准&＃xff0c;避免使用标签选择器&＃xff0c;使用类名而不是元素&＃xff0c;这样更容易维护。
3). 减少选择器的长度&＃xff0c;每个组合选择器的长度应控制在3个以内。

3.3.2 属性

css提供了各种缩写属性&＃xff0c;如font字体、transiton变换、animation动画等&＃xff0c;使用缩写属性对于代码效率和可读性亦有裨益。

3.3.3 重绘重排

为了保证更好的可读性和渲染效率&＃xff0c;样式声明应该遵循以下顺序&＃xff1a;

1). 结构性属性&＃xff1a;

a). display, float&＃xff0c;visibility&＃xff0c;overflow, clear等
b). position, left, top, right, z-index 等.
c). border &＃xff0c;width&＃xff0c;height 等.
d). margin, padding

2). 表现性属性&＃xff1a;

a). font, text&＃xff0c;word&＃xff0c;opacity 等
b). color&＃xff0c;background等
c). transition&＃xff0c;animation&＃xff0c;content等

3.3.4 代码组织

1). 以组件为单位组织代码。
2). 制定一个一致的注释层级结构。
3). 当使用多个 CSS 文件时&＃xff0c;通过组件而不是页面来区分他们。

3.3.5 效率工具

预处理工具和后处理工具能提高css开发效率&＃xff0c;推荐使用less、sass、stylus及postcss等工具使用模块化开发以提高效率&＃xff0c;CSS reset文件宜采用开源标准&＃xff0c;如normalize.css等。

3.4 图像规范

3.4.1 图像压缩

所有的图片必须经过压缩和优化才能发布。

3.4.2 图片格式

背景图建议使用PNG格式&＃xff0c;在需要兼容古老浏览器(IE8及以前)的项目中&＃xff0c;尽可能选择PNG-8而不是PNG-24。
内容图片建议使用JPG。
装饰性图使用PNG。

3.4.3 CSS Sprite

CSS Sprite可以减少HTTP请求数&＃xff0c;是推荐使用的图片处理技术。

3.4.4 图标字体

图标字体可大幅减少零碎小图标的使用&＃xff0c;可使用图标字体的场景应减少图片的使用。

3.4.5 其他

图片是web应用中最耗费资源的内容&＃xff0c;应尽量减少图片的使用&＃xff0c;可使用CSS、Canvas、SVG等技术实现的简单样式应避免使用图片。

3.5 Javascript规范

3.5.1 严格模式

严格模式 ‘Use strict’ 对不同的JS语境会做严格地错误检查&＃xff0c;使用严格模式也可确保代码更加健壮、运行更加快捷&＃xff0c;并禁止使用未来可能被引入的预留关键字。

3.5.2 代码风格

本规范无意于规定是否需要空格、分号等代码风格问题&＃xff0c;关于这等规范&＃xff0c;建议采用统一的ESLint配置以解决代码风格问题(参考standardjs风格)。

3.5.3 标准特性

优先考虑使用标准特性&＃xff0c;为最大限度的保证扩展性与兼容性&＃xff0c;首选标准特性&＃xff0c;而不是非标准特性&＃xff0c;如&＃xff1a;首选string.charAt(3)而非string[3]。

3.5.4 函数式编程

函数式编程可以简化代码并缩减维护成本&＃xff0c;易复用、利于降低耦合度。
例外&＃xff1a;在“重代码性能&＃xff0c;轻代码维护”的情况之下&＃xff0c;要选择最优性能的解决方案而非可维护性更好的方案&＃xff08;比如用简单的循环语句代替 forEach&＃xff09;。

3.5.4 组件化开发

1). 页面上的每个独立的可视/可交互区域视为一个组件&＃xff1b;
2). 每个组件对应一个工程目录&＃xff0c;组件所需的各种资源都在该目录下就近维护&＃xff1b;
3). 由于组件具有独立性&＃xff0c;因此组件与组件之间可自由组合&＃xff1b;
4). 页面是组件的容器&＃xff0c;负责组合各组件形成功能完整的界面&＃xff1b;
5). 当不需要或替换组件时&＃xff0c;可以整个目录删除/替换。

3.5.7 技术框架/库

前端技术发展日新月异&＃xff0c;主流框架各具特色。如何对当前项目进行技术选型是一项复杂且没有定论的工作&＃xff0c;但选型时的一些基本遵循是有共识的。参考点有&＃xff1a;
1). 框架是否成熟
2). 架构和模式
3). 生态系统
4). 与项目契合度
5). 团队技术储备
目前一些代表性框架/库有&＃xff1a;React、Angular、Vue、jQuery、Bootstrap等&＃xff0c;如&＃xff1a;
React&＃xff1a;采用Virtual Dom&＃xff0c;并衍生有React Native支持原生应用&＃xff0c;采用单向数据流&＃xff0c;但底层采用的JSX有技术门槛&＃xff1b;
Angular&＃xff1a; 依赖注入&＃xff0c;双向数据绑定&＃xff0c;支持TypeScript&＃xff0c;面向对象等&＃xff0c;但脏检查在watcher增多时效率会有明显下降&＃xff1b;
Vue&＃xff1a;轻量级&＃xff0c;双向数据绑定&＃xff0c;平缓的学习曲线&＃xff0c;在中小型简单应用中有更大优势。

以上对当前主流框架的说明仅做技术选型时的一般参考&＃xff0c;要经达权变&＃xff0c;不可荆人涉澭。

第三章 工程规范

第四条 性能优化

开发一款完整的web应用时&＃xff0c;前端将面临诸多的工程问题&＃xff0c;如&＃xff1a;多功能、多系统、多人合作&＃xff0c;高性能的CDN部署、缓存控制、按需加载、首屏渲染、服务端推送等&＃xff0c;这些问题的基本要求就是组件化开发和资源管理。
依照不同的优化目标&＃xff0c;应该采用的方案至少有&＃xff1a;

在前端开发的工程管理领域有很多细节值得挖掘和探索&＃xff0c;性能优化的分析和研究对前端团队技术的积累发展也大有裨益&＃xff0c;项目开发中应对此有充分考量。

第五条 web安全

本章节的目的是让开发者对各种web安全威胁的常见攻击手段有基本的了解&＃xff0c;以便我们能够快速定位漏洞代码、解除安全隐患。
XSS&＃xff1a;攻击者利用应用程序的动态数据展示功能&＃xff0c;在html页面里嵌入恶意代码。当用户浏览该页面时嵌入的html恶意代码即被执行。危害主要有&＃xff1a;盗取用户COOKIE伪造身份、下载病毒木马、钓鱼、蠕虫攻击等。
FLASH&＃xff1a;利用flash在安全配置和文件编码上的问题&＃xff0c;绕过浏览器同源策略发起跨域请求&＃xff0c;如CSRF攻击、钓鱼。
注入攻击&＃xff1a;包括SQL注入、代码注入、XML注入等&＃xff0c;如SQL注入&＃xff0c;当程序将用户输入的内容拼接到SQL中一起提交给数据库执行时&＃xff0c;就会产生SQL注入威胁。解决方案是对用户输入进行转义。
文件操作&＃xff1a; 应用在处理用户上传的文件时&＃xff0c;没有判断文件的扩展名是否在白名单内&＃xff0c;导致攻击者可以上传任意文件甚至脚本木马到服务器上直接控制服务器。解决方案是在用户上传文件请求的代码中过滤文件扩展名&＃xff0c;并保证上传文件的目录必须是http请求无法直接访问到的。
访问控制&＃xff1a; 由于应用没有做权限控制或者权限控制过于简单&＃xff0c;攻击者可以通过猜测管理员页面URL进行访问&＃xff0c;实现权限提升攻击&＃xff0c;建议使用成熟的权限框架解决该问题。
Session管理&＃xff1a;为防止XSS漏洞导致用户COOKIE被盗&＃xff0c;应设置COOKIE为httponly、Secure&＃xff0c;并设置超时时间。
密码算法安全&＃xff1a; 项目中涉及到的敏感信息不可采用简单算法加密、否则当攻击者获取有足够样本时&＃xff0c;将可以反推出解密算法&＃xff0c;从而泄露重要信息。其他一些如base64、escape、urlencode等只是编码格式&＃xff0c;不可用作密码算法。必须采用符合业内安全强度标准的密码算法&＃xff0c;如SHA-256等。

第四章 附则

第六条

本规范作为web开发人员的一般参考&＃xff0c;自发布之日起执行。