前端小团队应该怎么建设
一、命名规则(英文-直译)
1、文件命名
文件夹/文件的命名统一用小写
保证项目有良好的可移植性,可跨平台
2、文件引用路径
因为文件命名统一小写,引用也需要注意大小写问题
3、js变量
3.1 变量
命名方式:小驼峰
命名规范:前缀名词
命名建议:语义化
案例
3.2 常量
1 // 友好 2 let maxCount = 10; 3 let tableTitle = 'LoginTable'; 4 // 不友好 5 let setCount = 10; 6 let getTitle = 'LoginTable';
命名方式:全部大写 命名规范:使用大写字母和下划线来组合命名,下划线用以分割单词 命名建议:语义化 案例
1 const MAX_COUNT = 10; 2 const URL = 'http://www.foreverz.com';
3.3 函数
命名方式:小驼峰式命名法。
命名规范:前缀应当为动词。
命名建议:语义化
可以参考如下的动作
动词含义返回值can判断是否可执行某个动作(权限)函数返回一个布尔值。true:可执行;false:不可执行has判断是否含有某个值函数返回一个布尔值。true:含有此值;false:不含有此值is判断是否为某个值函数返回一个布尔值。true:为某个值;false:不为某个值get获取某个值函数返回一个非布尔值set设置某个值无返回值、返回是否设置成功或者返回链式对象load加载某些数据无返回值或者返回是否加载完成的结果
1 // 是否可阅读 2 function canRead(): boolean { 3 return true; 4 } 5 // 获取名称 6 function getName(): string { 7 return this.name; 8 }
3.4 类、构造函数
命名方式:大驼峰式命名法,首字母大写
命名规范:前缀为名称。
命名建议:语义化
案例
1 class Person { 2 public name: string; 3 constructor(name) { 4 this.name = name; 5 } 6 } 7 const person = new Person('mevyn');
公共属性和方法:
跟变量和函数的命名一样。
私有属性和方法:
前缀为_(下划线),后面跟公共属性和方法一样的命名方式。
案例
1 class Person { 2 private _name: string; 3 constructor() { } 4 // 公共方法 5 getName() { 6 return this._name; 7 } 8 // 公共方法 9 setName(name) { 10 this._name = name; 11 } 12 } 13 const person = new Person(); 14 person.setName('mervyn'); 15 person.getName(); // ->mervyn
3.5 css(class、id)命名规则BEM
我们还是使用大团队比较常用的BEM模式
(1)class
命名使用BEM其实是块(block
)、元素(element
)、修饰符(modifier
)的缩写,利用不同的区块,功能以及样式来给元素命名。这三个部分使用__与–连接(这里用两个而不是一个是为了留下用于块儿的命名)。
命名约定的模式如下:
1 .block{} 2 .block__element{} 3 .block--modifier{}
block 代表了更高级别的抽象或组件
block__element 代表 block 的后代,用于形成一个完整的 block 的整体
block--modifier代表 block 的不同状态或不同版本
(2)id
一般参与样式,命名的话使用驼峰,如果是给js调用钩子就需要设置为js_xxxx
的方式
二、注释
1.单行注释
// 这个函数的执行条件,执行结果大概说明 dosomthing()
2.多行注释
/* * xxxx 描述较多的时候可以使用多行注释 * xxxx */ dosomthing();
3.函数(方法)注释
注释名语法含义示例@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.vue
和 xxmixin.js
和 readme.md
xxx.vue 表示ui部分
xxmixin.js 表示js部分
readme.md 中描述组件的基本信息
名词含义案例@name组件名称筛选下拉框@version版本v1.0.0@updateTime更新日期2018.09.18@describe使用场景描述某某场景下@props参数[‘data’]@author作者dd
引用组件的时候 直接引入 mixinElementFilter.js 即可。在引用组件的页面可以对mixin里面的方法进行重构
(2)业务组件就放在业务模块部分即可
4 组件通讯
避免数据的分发源混乱,不建议使用eventBus
控制数据,应使用props
来和$emit
来数据分发和传送
同级组件的通讯一般会有一个中间容器组件作为桥梁
容器组件作为数据的接受和分发点
5 组件的挂在和销毁
(1)通过v-if控制组件的挂在和销毁
<testcomponent v-if='componentActive'> </testcomponent>
(2)通过is控制组件的挂在和销毁
<component is='componentName'> </component>
6 跨项目组件共用
公共组件存放位置中 定时抽取共用次数多的组件 将他放在npm.kuaizi.co中,供下载引用
四、codeReview
1 规则
所有影响到以往流程的功能需求更改发版前都需要codeReview
2 执行者
初级程序员可由中级程序员的执行codeReview
中级程序员可由高级程序员执行codeReview
以此类推
3 反馈
每次codereView都需要有反馈,要对本次codeReview负责
反馈内容基本如
功能:本次主要是修改了什么功能或者bug
模块:本次发版影响的模块
代码问题:codereview过程中发现的代码问题,比如代码性能,写法,代码风格等等
业务问题:比如发现了某某影响到其他模块的逻辑问题,如果没有发现就写。无
五、git规范
1 分支
命名
master: master 分支就叫master 分支,线上环境正在使用的,每一次更新master都需要打tag
test: test分支就供测试环境使用的分支
develop: develop 分支就叫develop 分支
feature: feature 分支 咱们暂时可以按 feature/name/version 这种命名规范来,后面有更好的命名规范咱们再改。version 表示
当前迭代的版本号,name 表示当前迭代的名称
hotfix: hotfix 分支的命名我们暂时可以按 hotfix/name/version 这种来进行命名,verison表示这次修复的版本的版本号,name表示本次热修复的内容标题
斜杠 的方式 在source-tree中有归类的作用