代码可读性总结
代码可读性我个人认为是不是写这个项目的人，能够在接触这个代码并参照文档的情况下能够快速看懂项目并且快速上手，进行功能迭代和继续开发维护。
代码具备清楚的注释和清晰的逻辑，不同功能之间代码分离，耦合度低。
代码规范化
html
- 良好的结构。表现为没有css的情况下网站野能够正确的显示出基本要展现的内容
- 使用语义化的标签
- 合适缩进。标签开头和结束位置对齐
css
- 使用css module方案避免过长的类名、不使用css module方案的话约定同一种命名方式如REM（.slider-left-list、.slider-right-xxx这样）
- 使用css预处理器。把一些多处公用到的颜色值、某些固定风格的UI写成变量的形式，便于修改和迭代
- 样式值尽量使用缩写形式
- 处理跨浏览器的兼容性的css 使用统一前缀说明
- css选择器尽量短
- 对于同一个选择器的样式顺寻，按照元素布局、尺寸、元素内部样式顺序编写。例如
.element { position: fixed; top: 20; width: 200px; border: 1px solid red; background-color: blue; font-size: 20px; }- 少用!important
- 在没有外部css库的情况下，z-index 的值尽量只使用-1、1、2
- 全局公用样式、模块特有样式（模块内的皮肤、特有情况的样式也分离）分离
javascript
-
命名规范
- 驼峰式命名
- 变量名 名词（一般变量单数，数组或者Map等使用复数形式）
- 常量名 全大写，单词之间用_分隔 如：
SYNC_RENDER，常量值使用Symbol('常量名')的形式生成。 - 模块内的私有变量使用_前缀或者$前缀
- 函数名 动词前缀+功能
- 类名大写开头+驼峰
-
注释
-
函数。写参数的类型、含义;返回值的类型含义;定义类的方法并写方法否公用，类的定义表明继承信息或者有用的信息也写上去。例如
/** * 功能：更新组件的状态.... * @public * @param {object || function} state 更新的state状态 * @param {function} callback 回调函数 * @return {String} status 返回值 */ function setState(state,callback){ const status = state.success; .... return status; } 变量。对于从变量名上看不出来的或者功能有些复杂的变量，进行说明
- css 对不同大模块的css样式进行不同文件的划分。在每个小功能的顶部说明该样式对应功能的作用
-
-
代码逻辑
- 表达式尽量使用三元运算符代替if（if语句块加大括号）。2个判断条件以上的使用switch（switch必须包含default）
- 非ESModule的全局环境下，必要时使用立即执行函数避免过多全局变量的引入
- 函数返回undefined使用void运算符
- 尽量使用模板字符串
- 对于一些复杂的计算逻辑，结果使用一个临时变量存下，并说明干什么用
- 多使用箭头函数单语句隐式返回的写法
- 对于一套逻辑需要复用多次的，抽象成一个函数
- 使用typescript方案
react
- 组件名使用首字母大写的驼峰式
- 一般使用的目录结构（组件名和文件名相同）
- /src
- components/
- containers/
- actions/
- reducer reducer处理
- store/ store配置
- index.js 入口文件
- 组件进行划分
- container组件 能感知redux存在的
- component组件
- 纯展示型 内部无状态，状态只依赖于父组件的传入。使用纯函数写法 const Show = () => <div>hello wolrd</div>
- 有内部state的component组件
- 组件内部的方法使用 method = ()=>{ // dosome}的形式声明
- reducer 根据不同模块拆分成一些子的reducer
- jsx的属性值不直接使用函数表达式
- 写法要清真，配合babel下尽量使用ES6+语法，多用数组的map、reduce写得函数式点
nodejs
- node>8版本异步操作使用async/await语法
- node>6 node使用util.promisify对callback型api进行封装使用Promise写法
- pm2对日志进行输出记录找bug
代码格式统一
项目中代码规范的统一。配合自动化工具检测和格式化
- 约定统一缩进
- 约定统一一些地方的空格
- 约定单双引号统一
standard进行代码格式化和规范统一。
git
master 线上分支
dev 开发分支
feature/xxx xxx功能分支
hotfix/xxx 线上出bug紧急修复分支
1、开发功能是在feature/xxx 分支上进行，开发完成后，rebase自己开发过程中一些无用的commit并修改一些commit信息，使条理清晰可读性较好。每次commit工具进行precommit检测。开发过程中公用模块需要自己加的东西并其他人开发模块用到的，在群里通知其它开发者自己加了，和在代码中注释好如何用
2、提PR合并到dev，其它开发者review后合并到dev。该feature就弃用，然后下次开发功能从dev下checkout -b 新分支开发
3、线上有bug，checkout -b到hotfix/xxx，修复bug，提PR到dev，其他开发者review合并到dev
4、发布新版本，打tag，dev合到master分支