团队代码规范、冲刺任务与计划
这个作业属于哪个课程 | 2020春|S班 |
---|---|
作业要求 | 团队作业第五次 |
作业目标 | 代码规范、冲刺任务与计划 |
作业正文 | 点击 |
冲刺安排
冲刺时间为期10天,我们计划安排在4月27日到5月6日之间。在此之前做一些先期的准备与学习。
冲刺计划安排
日期 | 目标 |
---|---|
4月28日 | 开会,安排具体工作 |
4月29日 | 熟悉框架、UI库,编写大体架构,数据库建库建表 |
4月30日——1日 | UI设计出界面样本,明确具体功能实现,其他人进行自己模块的准备工作 |
5月2日——5日 | 前端后端进行对应的编程工作,同时对设计不足之处进行反馈和修改 |
5月6日 | 进行自己设计部分单元测试,找出bug并修改 |
5月7日 | 相互之间进行测试,防止固有思维产生的bug,并进行告知和修改 |
5月8日 | 前后端接口连接,同时进行测试,找出bug并修改 |
5月9日 | 进行答辩PPT准备 |
冲刺计划目标
实现项目系统设计中模块功能,完成宅单词,并进行Alpha阶段测试。
代码规范
(一) 命名风格
1.【强制】代码中的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结 束。
反例:name / name / $name / name / name$ / name
2.【强制】代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式。
说明:正确的英文拼写和语法可以让阅读者易于理解,避免歧义。注意,即使纯拼
音命名方式 也要避免采用。
反例:DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3
3.【强制】类名使用 UpperCamelCase 风格,但以下情形例外:DO / BO / DTO / VO / AO / PO / UID 等。
正例:MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例:macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
4.【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格,必 须遵从 驼峰形式。
正例: localValue / getHttpMessage() / inputUserId
5.【强制】常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名 字长。
正例:MAX_STOCK_COUNT 反例:MAX_COUNT
6.【强制】抽象类命名使用 Abstract 或 Base 开头;异常类命名使用 Exception 结尾; 测试类命名以它要测试的类的名称开始,以 Test 结尾。
7.【强制】类型与中括号紧挨相连来表示数组。
正例:定义整形数组 int[] arrayDemo; 在 main 参数中,使用 String[] args 来 定义
反例:在 main 参数中,使用 String args[]来定义。
8.【强制】包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词。包名统 一使用单数形式,但是类名如果有复数含义,类名可以使用复数形式。
正例:应用工具类包名为 com.alibaba.ai.util、类名为 MessageUtils(此规则 参考 spring 的框架结构)
9.【强制】杜绝完全不规范的缩写,避免望文不知义。
反例:AbstractClass“缩写”命名成 AbsClass;condition“缩写”命名成 condi, 此类随意缩写严重降低了代码的可阅读性。
10.【推荐】为了达到代码自解释的目标,任何自定义编程元素在命名时,使用尽量完整的 单词组合来表达其意。
正例:在 JDK 中,表达原子更新的类名为:AtomicReferenceFieldUpdater。
反例:变量 int a 的随意命名方式。
(二) 代码格式
1.【强制】大括号的使用约定。如果是大括号内为空,则简洁地写成{}即可, 不需要换行;如果是非空代码块则:
左大括号前不换行。
左大括号后换行。
右大括号前换行。
右大括号后还有 else 等代码则不换行;表示终止的右大括号后必须换行。
2.【强制】if/for/while/switch/do 等保留字与括号之间都必须加空格。
3.【强制】采用 4 个空格缩进,禁止使用 tab 字符。
说明:如果使用 tab 缩进,必须设置 1 个 tab 为 4 个空格。IDEA 设置 tab 为 4 个空格时, 请勿勾选 Use tab character;而在 eclipse 中,必须勾选 insert spaces for tabs
(三) 注释规约
1.【强制】类、类属性、类方法的注释必须使用 Javadoc 规范,使用/内容/格式,不得使用 // xxx 方式。
说明:在 IDE 编辑窗口中,Javadoc 方式会提示相关注释,生成 Javadoc 可以正确输出相应注释;在 IDE 中,工程调用方法时,不进入方法即可
悬浮提示方法、参数、返回值的意义,提高阅读效率。
2.【强制】所有的抽象方法(包括接口中的方法)必须要用 Javadoc 注释、除 了返回值、参数、异常说明外,还必须指出该方法做什么事情,实现什么功能。
说明:对子类的实现要求,或者调用注意事项,请一并说明。
3.【强制】所有的类都必须添加创建者和创建日期。
4.【强制】方法内部单行注释,在被注释语句上方另起一行,使用//注释。方法 内部多行注释 使用/* */注释,注意与代码对齐。
5.【强制】所有的枚举类型字段必须要有注释,说明每个数据项的用途。
6.【推荐】与其“半吊子”英文来注释,不如用中文注释把问题说清楚。专有名 词与关键字保持英文原文即可。
反例:“TCP连接超时”解释成“传输控制协议连接超时”,理解反而费 脑筋。
7.【推荐】代码修改的同时,注释也要进行相应的修改,尤其是参数、返回值、 异常、核心逻辑等的修改。
说明:代码与注释更新不同步,就像路网与导航软件更新不同步一样, 如果导航软件严重滞后,就失去了导航的意义。
8.【参考】谨慎注释掉代码。在上方详细说明,而不是简单地注释掉。如果无用, 则删除。
说明:代码被注释掉有两种可能性:(1)后续会恢复此段代码逻辑。(2) 永久不用。前者如果没有备注信息,难以知晓注释动机。后者建议直接 删掉(代码仓库保存了历史代码)。
(四) 安全规约
1.【强制】隶属于用户个人的页面或者功能必须进行权限控制校验。
说明:防止没有做水平权限校验就可随意访问、修改、删除别人的数据,比如查看他人的私信内容。