作业格式

• 课程名称：软件工程1916|W（福州大学）
• 作业要求：项目Alpha冲刺（团队）
• 团队名称： 那周余嘉熊掌将得队
• 作业目标：代码规范、本次冲刺任务与计划
• 团队信息：

作业正文

1. 项目准备

• 项目选题报告

• 项目原型设计

• 项目需求分析

• 项目系统设计与数据库设计

2. 代码规范

前端

• 目录规范
  • build文件夹 —— 放置webpack配置文件
    • build.js文件 —— 生产环境构建
    • dev-server.js文件 —— npm run dev的启动文件 构建本地服务器
    • dev-client.js文件 —— 开发服务器的热重载
    • check-version.js文件 —— 检查node、npm版本
    • utils.js —— 构建工具相关
    • webpack.base.conf.js文件 —— webpack基础配置
    • webpack.dev.conf.js文件 —— webpack开发环境配置
    • webpack.prod.conf.js文件 —— webpack生产环境配置
    • vue-loader文件 —— css加载器配置
  • config文件夹 —— 放置Vue项目配置文件
    • index.js文件 —— 项目主要配置（包括监听端口，打包路径等）
    • dev.env.js —— 项目开发环境配置
    • prod.env.js —— 项目生产环境配置
  • node_modules文件夹 —— 放置依赖包
  • src文件夹 —— 项目核心文件
    • assets文件夹 —— 放置样式及静态图片等
    • components文件夹 —— 项目所有组件
    • views文件夹 —— 项目所有页面
    • script文件夹 —— 外部js文件
  • static文件夹 —— 第三方插件、静态资源等
  • app.Vue文件 —— 页面入口文件
  • main.js文件 —— 项目入口文件
  • index.js文件 —— 入口页面及路由配置
  • .babelrc文件 —— ES6语法编译配置
  • .editorconfig —— 定义代码格式
  • .gitignore —— git上传需要忽略的文件格式
  • .postcssrc —— postcss配置文件
  • package.json —— 项目基本信息、依赖信息等
• 命名风格
  • 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
  • 代码中的命名不允许使用拼音与英文混合的方式，更不允许直接使用中文的方式。
  • 类名尽量使用UpperCamelCase风格，方便阅读。
  • 方法名、参数名、成员变量、局部变量都尽量使用 lowerCamelCase 风格，尽量遵从驼峰形式。
  • 包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
  • 为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合或单词缩写来表达其意。
• 代码格式
  • if/for/while/switch/do 等保留字与括号之间都必须加空格。
  • 对于非空代码块的大括号使用中，表示终止的右大括号后必须换行；左大括号后换行；右大括号前换行。
  • 可使用tab缩进或4个空格缩进。
  • css样式部分使用sass语句，子元素样式都写在父元素样式里。
• 注释规约
  • 方法内部单行注释，在被注释语句上方另起一行，使用//注释。
  • 方法内部多行注释 使用/* */注释，注意与代码对齐。
  • 代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
  • 谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。

后端

• 命名风格
  • 大小写约定
    • 请将PascalCasing 用于包含多个单词的所有公共成员、类型和命名空间名称。
    • 请将camelCasing 用于参数名称。
  • 通用命名约定
    • 务必选择易读的标识符名称。
    • 务必使可读性优先于简洁性。
    • 不要使用下划线、连字符或任何其他非字母数字字符。
    • 避免使用与广泛应用的编程语言关键字冲突的标识符。
    • 不要在标识符名称中使用缩写形式或缩略形式。
    • 不要使用任何不常用的首字母缩写形式，即使是常用形式，也应只在必要时使用。
    • 务必使用在语义上有意义的名称而不是特定于语言的关键字作为类型名称。
  • 类、结构和接口得名称
    • 务必通过使用PascalCasing，用名词或名词短语命名类和结构。
    • 务必使用形容词短语命名接口，或偶尔用名词或名词短语命名接口。
    • 务必在接口名称前加上字母I作为前缀，以指示该类型是接口。
    • 务必确保在定义类和接口对时，类名称和接口名称的区别仅在于 "I" 前缀，其中类是接口的标准实现。
• 代码格式
  • 采用4个空格缩进，禁止使用tab字符。
  • 括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：左大括号前换行,左大括号后换行,右大括号前换行,右大括号后换行。
  • if/for/while/switch/do 等保留字与括号之间都必须加空格
  • 方法参数在定义和传入时，多个参数逗号后边必须加空格
• 注释规约
  • 用途使用<summary>注释
  • 参数使用<params>注释
  • 返回值使用<returns>注释
  • 方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐。

git协作规范

• master分支，即主分支。任何项目都必须有个这个分支。对项目进行tag或发布版本等操作，都必须在该分支上进行。

• develop分支，即开发分支，从master分支上检出。团队成员一般不会直接更改该分支，而是分别从该分支检出自己的feature分支，开发完成后将feature分支上的改动merge回develop分支。同时release分支由此分支检出。

• release分支，即发布分支，从develop分支上检出。该分支用作发版前的测试，可进行简单的bug修复。如果bug修复比较复杂，可merge回develop分支后由其他分支进行bug修复。此分支测试完成后，需要同时merge到master和develop分支上。

• feature分支，即功能分支，从develop分支上检出。团队成员中每个人都维护一个自己的feature分支，并进行开发工作，开发完成后将此分支merge回develop分支。此分支一般用来开发新功能或进行项目维护等。

• fix分支，即补丁分支，由develop分支检出，用作bug修复，bug修复完成需merge回develop分支，并将其删除。所以该分支属于临时性分支。

• hotfix分支，即热补丁分支。该分支由master分支检出，进行线上版本的bug修复，修复完成后merge回master分支，并merge到develop分支上，merge完成后也可以将其删除，也属于临时性分支。

  3. 冲刺任务与计划