前端小团队建设

一、命名规则(英文-直译)

1、文件命名

文件夹/文件的命名统一用小写
保证项目有良好的可移植性,可跨平台
相关参考

2、文件引用路径

因为文件命名统一小写,引用也需要注意大小写问题

3、js变量

3.1 变量

命名方式:小驼峰

命名规范:前缀名词

命名建议:语义化

案例

3.2 常量

命名方式:全部大写

命名规范:使用大写字母和下划线来组合命名,下划线用以分割单词

命名建议:语义化

案例

3.3 函数

命名方式:小驼峰式命名法。

命名规范:前缀应当为动词。

命名建议:语义化

可以参考如下的动作
动词 含义 返回值
can 判断是否可执行某个动作(权限) 函数返回一个布尔值。true:可执行;false:不可执行
has 判断是否含有某个值 函数返回一个布尔值。true:含有此值;false:不含有此值
is 判断是否为某个值 函数返回一个布尔值。true:为某个值;false:不为某个值
get 获取某个值 函数返回一个非布尔值
set 设置某个值 无返回值、返回是否设置成功或者返回链式对象
load 加载某些数据 无返回值或者返回是否加载完成的结果

3.4 类、构造函数

命名方式:大驼峰式命名法,首字母大写

命名规范:前缀为名称。

命名建议:语义化

案例

公共属性和方法:跟变量和函数的命名一样。

私有属性和方法:前缀为_(下划线),后面跟公共属性和方法一样的命名方式。

案例

3.5 css(class、id)命名规则BEM

(1)class命名使用BEM其实是块(block)、元素(element)、修饰符(modifier)的缩写,利用不同的区块,功能以及样式来给元素命名。这三个部分使用__与–连接(这里用两个而不是一个是为了留下用于块儿的命名)。
命名约定的模式如下:

(2)id一般参与样式,命名的话使用驼峰,如果是给js调用钩子就需要设置为js_xxxx的方式

二、注释

1.单行注释

2.多行注释

3.函数(方法)注释 参考jsdoc

注释名 语法 含义 示例
@param @param 参数名 {参数类型} 描述信息 描述参数的信息 @param name {String} 传入名称
@return @return {返回类型} 描述信息 描述返回值的信息 @return {Boolean} true:可执行;false:不可执行
@author @author 作者信息 [附属信息:如邮箱、日期] 描述此函数作者的信息 @author 张三 2015/07/21
@version @version XX.XX.XX 描述此函数的版本号 @version 1.0.3
@example @example 示例代码 演示函数的使用 @example setTitle(‘测试’)

三、组件

每个 Vue 组件的代码建议不要超出 200 行,如果超出建议拆分组件

组件一般情况下是可以拆成基础/ui部分和业务部分,基础组件一般是承载呈现,基础功能,不和业务耦合部分。
业务组件一般包含业务功能业务特殊数据等等

1 UI组件/基础组件

开发的时候注意可拓展性,支持数据传参进行渲染,支持插槽slot

设置有mixin,mixin中放了基础信息和方法

2 容器组件

和当前业务耦合性比较高,由多个基础组件组成,可承载当前页的业务接口请求和数据(vuex)

3 组件存放位置

(1)ui组件存放在src/components/
包含xxx.vuexxmixin.jsreadme.md

名词 含义 案例
@name 组件名称 筛选下拉框
@version 版本 v1.0.0
@updateTime 更新日期 2018.09.18
@describe 使用场景描述 某某场景下
@props 参数 [‘data’]
@author 作者 dd

如下图
引用组件的时候 直接引入 mixinElementFilter.js 即可。在引用组件的页面可以对mixin里面的方法进行重构
clipboard.png

(2)业务组件就放在业务模块部分即可

4 组件通讯

避免数据的分发源混乱,不建议使用eventBus控制数据,应使用props来和$emit来数据分发和传送

同级组件的通讯一般会有一个中间容器组件作为桥梁

容器组件作为数据的接受和分发点

5 组件的挂在和销毁

(1)通过v-if控制组件的挂在和销毁

(2)通过is控制组件的挂在和销毁

6 跨项目组件共用

公共组件存放位置中 定时抽取共用次数多的组件 将他放在npm.kuaizi.co中,供下载引用

四、codeReview

1 规则

所有影响到以往流程的功能需求更改发版前都需要codeReview

2 执行者

初级程序员可由中级程序员的执行codeReview
中级程序员可由高级程序员执行codeReview
以此类推

3 反馈

每次codereView都需要有反馈,要对本次codeReview负责

反馈内容基本如

五、git规范

1 分支

命名

斜杠 的方式 在source-tree中有归类的作用

2 提交模版 kz-commit

在完善中,会继承自动检测代码,可选输入发版提交版本基本信息等等

六、分享会

每两周至少执行一次,分享工作,生活各方面都可以

参考:

https://juejin.im/entry/599d4…

1 2 收藏 评论

可能感兴趣的话题



直接登录
跳到底部
返回顶部