首次发表在个人博客
总结一下个人在开发及review同事代码的过程中遇到的因为一些项目规范带来的问题及认为比较好的解决方法; 由于个人经验和认知水平有限,下面仅代表我的个人观念,欢迎各位大佬多给我提建议;
以本人最近写的一个项目(技术栈为Meteor + React + MongoDB)为例
readme的使用
因为一个项目往往需要很多人一起协助开发,还有可能会不断有新手接手项目,所以readme里面一定要仅可能多的信息
- 项目启动命令
- 代码规范
- Commit Message 编写规范
- 命名: class命名,变量命名,函数命名,组件命名等
- 组件
- 目录结构
- 常遇到的问题及解决方案
也可以加一些项目中遇到的设计到的文档链接
代码规范
eslint
使用eslint来约束团队统一的代码规则
eslint规则在.eslintrc.js中定义,觉得不合理的可以跟团队成员商量禁掉某条规则,或者有好的建议的也可以添加; 主要注意一下几条:
- 代码缩进用4空格
- 语句必须默认后加分号
- 使用单引号
- 提交代码前将console.log语句删掉或注释掉(不然影响其他开发人员调试)
- 禁止使用var,使用es6的let,const声明变量
还有一些情况是不需要检测的,例如第3方的库, 框架、组件、ui库等等,可以将这些文件放在.eslintignore文件中,可以忽略eslint的检测
在文件顶部加上下面这行,可以禁掉整个文件的eslint规则
/* eslint-disable */
pre-commit 的使用
使用方法 1.在命令行安装
npm i --save-dev pre-commit
2.在package.json中配置
{
"scripts": {
"eslint": "eslint ./ --ext js,vue --ignore-pattern .eslintignore --cache --fix",
"lint-message": "echo '开始 eslint 检查, 存在 error 则会拒绝提交'"
},
"pre-commit": [
"lint-message",
"eslint" // 进行eslint检查并自动修复一些简单的格式错误
],
}
代码提交之前会强制code-review,不符合规范的不允许提交代码
如果项目实在没时间去改的话，可以git commit -m 'XXX' --no-verify 或 git commit -n 'xxx'强制提交
小技巧-vscode可以配置保存自动修复eslint错误
vscode安装eslint插件,在配置中配置如下
{
"eslint.autoFixOnSave": true,
"eslint.enable": true,
"eslint.options": {
"extensions": [".js", ".vue", ".jsx"]
},
"eslint.validate": [
{
"language": "vue",
"autoFix": true
},
{
"language": "javascript",
"autoFix": true
},
{
"language": "javascriptreact",
"autoFix": true
}
],
}
Commit Message 编写规范
编写Commit Message需要遵循一定的范式，内容应该清晰明了，指明本次提交的目的，便于日后追踪问题。
feat: 新功能
fix: 修补bug
docs: 文档
style: 格式(不影响代码运行的变动)
refactor: 重构
test: 添加测试
chore: 构建过程或辅助工具的变动
命名
命名的语义化真的特别特别重要,哪怕不知道要命名的这个词的英文是什么,也要去查一下;千万不要以a,b,c等没有任何语义的词去命名;之前我也总是注意不到这一点,但是最近在看同事的代码还有重构自己之前写的部分代码,命名压根看不明白这个变量的意思,总之,看这样的代码怎一个痛苦了得
常见class命名关键词： 布局类：header, footer, container, main, content, aside, page, section 包裹类：wrap, inner 区块类：region, block, box 结构类：hd, bd, ft, top, bottom, left, right, middle, col, row, grid, span 列表类：list, item, field 主次类：primary, secondary, sub, minor 大小类：s, m, l, xl, large, small 状态类：active, current, checked, hover, fail, success, warn, error, on, off 导航类：nav, prev, next, breadcrumb, forward, back, indicator, paging, first, last 交互类：tips, alert, modal, pop, panel, tabs, accordion, slide, scroll, overlay, 星级类：rate, star 分割类：group, seperate, divider 等分类：full, half, third, quarter 表格类：table, tr, td, cell, row 图片类：img, thumbnail, original, album, gallery 语言类：cn, en 论坛类：forum, bbs, topic, post 方向类：up, down, left, right 其他语义类：btn, close, ok, cancel, switch; link, title, info, intro, more, icon; form, label, search, contact, phone, date, email, user; view, loading...
变量命名: 名字要能准确的描述出该变量所代表的事物
比如表示user的id就叫userId,而不要只叫user
函数命名建议：可使用常见动词约定
动词 含义
get 获取某个值
set 设置某个值
is 判断是否为某个值
has 判断是否有某个值
以下规则是此项目中使用的,主要看团队代码习惯:
- 组件名和组件所在文件名使用大驼峰式
- css类名使用小写单词并用横线(-)分割
- dom节点以$开头
组件
- 每个组件占一个文件
- 组件不包含状态则应写为 stateless 组件
- 非 stateless 组件使用 pure-render-decorator 优化
目录结构
├── client
│ ├── main.html 客户端页面模板
│ └── main.js 客户端入口
├── imports
│ ├── client
│ │ ├── App.jsx 顶层组件
│ │ ├── components 公共组件
│ │ ├── routers 前端路由
│ │ ├── styles 样式
│ │ └── views 视图
│ │ ├── header 公共头
│ │ ├── login 登录注册
│ ├── schema 模型
│ └── util 工具函数
├── packages 自定义 meteor 包
├── public 客户端资源
└── server
├── main.js 服务端入口
└── user 用户接口
issues的使用
项目中总会遇到很多奇奇怪怪的问题,当时印象深刻,过了一段时间,就忘了具体的问题及解决办法,虽然每次可以通过查commit为fix的记录,但是这样查找起来很麻烦,我们项目是用gitlab来托管,可以合理的理由issues,每次遇到很棘手的问题的时候,可以提一个issues,等后期把这个问题解决了再把这个issues给关闭,并写上问题原因及解决办法分析
下面补充的是项目中针对Meteor后端开发的一些规范
数据库
Collection 定义
所有 Collection 定义放在 imports/schema 目录, 每个 Collection 务必定义 Schema 来约束字段
Schema 定义
Schema 定义使用 SimpleSchema, 数据插入数据库前必须通过 schema 校验, 调用校验语句为 表名.schema.validate(要插入的数据);
过滤 Collection 字段
默认情况下, 数据查询语句会返回所有字段, 比如 Memete.users.find({}) 会将用户的密码和 token 一并返回, 这样是不安全不正确的, find / findOne 的第二个参数是查询选项, fields 字段可以控制返回字段, 例如:
Meteor.users.find(
{ },
{
fields: {
username: 1,
profile: 1,
},
},
);
该查询会返回 _id, username, profile 字段, 其中 _id 是默认返回的
自己定义populate方法(取出关联数据)
在做邀请新的好友入群的时候,添加新的好友,利用reywood:publish-composite并不会自动更新数据,所以以后直接自己在客户端定义方法 这样做的好处是解决了取关联数据不会自动更新的bug,但是有点麻烦的是每次需要关联数据的时候必须在客户端调用一次方法,正在考虑有没有更好的解决方法
import { Meteor } from 'meteor/meteor';
const PopulateUtil = {
group(group) {
if (group) {
group.members = Meteor.users.find({ _id: { $in: group.members } }).fetch();
group.admin = Meteor.users.findOne({ _id: group.admin });
}
},
groups(groups) {
groups.forEach(group => PopulateUtil.group(group));
},
};
export default PopulateUtil;
因为这次项目需要自己设计数据库,还有自己定义后端方法,之前没有任何经验,做到现在也总结出一点心得:
- 数据库设计一定要根据具体的业务逻辑(开始设计之前一定要和产品沟通清楚产品逻辑)
- 能在后端取到的数据,在接口定义的时候不要让前端去传
最后感觉后端的逻辑真的很复杂,需要各种判断,各种情况都得想到
推荐看一下这本代码大全(第二版),等看完这本书再好好的完善一下这篇文章
