很多情况下我们不愿意接手别人的代码不是因为逻辑复杂，有很大一部分原因是因为代码风格不一致，读别人的代码太费劲，千人尚有千面，何况代码呢。私以为变量命名和函数命名及调用不统一等个人风格严重是后来人维护和修改代码最大的阻力。
Later always means Never，好多脆弱的，可优化代码都想着以后有时间再改，但一旦放下可能就永远不会再回头优化
编码规范
-
编码规范为何很重要？
- 软件生命周期中80%的成本消耗在了维护上
- 几乎所有的软件维护者都不是它的最初作者。
- 编码规范提高了软件的可读性，它让工程师能够快速且充分地理解新的代码。
- 当你开始工作时，你不是在给你自己写代码，而是为后来人写代码。
-
编码规范(简)
- 统一编程风格 jsLint
- 代码缩进，空格或tab、运算符间距
- 语句结尾分号，分析器有自动分号插入（automatic semicolon Insertion）ASI机制，该机制会自动寻找代码中应当使用分号但实际没有分号的位置并插入分号，大多数场景下ASI都会正确插入，但他的分号插入规则非常复杂且很难记住，不推荐省略分号、
- 行的长度，行太长时应该换行
- 空行？适当的空行有助于提高代码的可读性、例如在局部变量和逻辑语句之间
- 变量和函数的命名：驼峰命名法，首单词应为动词（构造函数或对象除外），常量的命名应为所有字母大写，不同单词之间用下划线隔开，严格模式应仅限在函数内部使用，千万不要在全局使用use strict,最好不实用下划线，字符串应使用双引号，每个变量应该给原始值。避免使用undefined，判断使用typeof (typeof variable == "undefined")
避免使用eval,with语句，因为未来EcmaScript可能弃用。 - 注释，单行及多行，文档注释
- 语句和表达式，避免使用全局变量，全等比较,赋值时如果右侧是比较表达式，应用圆括号包裹，避免弱类型转换错误，或0==false.
- 抛出错误try-catch，系统错误或自定义错误
- 文件和目录结构保存一致。
- 数组清空，变量释放，初始化，避免重复引用
- 组件规范，不要只是拿来用，要知其所以然，组件的编写原则，保证组件的复用性。
- 善于利用工具。使用浏览器的开发者工具调试代码，vue devtools
前后端接口定义、联调等注意事项
现在WEB开发都是前后端分离模式，为了并行开发提高效率，提前定义好数据接口就很有必要。在以往实际开发工作中主要使用过三种接口定义方式，postman,swagger,mock。
- Postman 官网
- 之前写过的一篇 postman使用简介
Postman
- swagger 官网
- 网上搜索的一篇 Swagger介绍及使用
swagger
- Mock-js
- Mock.js新手教程
开发流程
- 由后端编写和维护接口文档，在 API或需求变化时更新接口文档
- 后端根据接口文档进行接口开发
- 前端根据接口文档进行页面开发 + Mock数据
- 开发完成后联调和提交测试
接口规范定义
规范的接口定义很重要，接口定义的好坏直接影响到前端的工作量和实现逻辑
规范原则
- 接口返回数据即显示：前端仅做渲染逻辑处理；
- 渲染逻辑如非实在无法实现应禁止跨多个接口调用，会导致好多隐藏问题；
- 前端关注交互、渲染逻辑，尽量避免业务逻辑处理的出现；
- 请求响应传输数据格式：JSON，JSON数据尽量简单轻量，尽量避免多级JSON的出现
- 接口定义好之后，前后端开发人员都应严格遵守，如遇需修改接口定义的应协商修改，保证信息同步，避免修改接口导致的边界问题。
请求格式
{
id: 1,
name: "XXX",
code: "XXX"
}
响应格式
{
code: 200,
data: {
message: "success",
list: [{
id: 1,
name: "XXX",
code: "XXX",
isSelect: 1
}, {
id: 1,
name: "XXX",
code: "XXX",
isSelect: 0
}]
}
}
网友评论