一、 冲刺时间的计划安排
时间 | |
---|---|
6.25 | |
6.26 | |
6.27 | |
6.28 | |
6.29 | |
6.30 | |
7.1 |
二、 针对前几次作业不足
前几次软工作业大家虽然非常认真,但难免不主动,没有领导人分配任务大家的主动性就会明显下降,这是需要我们反思和警惕的。此外,由于大家男生偏多,女生较少,按理来说应该可以多多的交流来提升效率,但是大家并没有这个意识,可能都有点习惯待在寝室闭门造车,这是需要改进的地方。
三、需要改进的团队分工
新增交流员:负责组织大家对于项目的讨论和交流,加强大家的沟通。
新增协调员:负责询问组员任务完成情况,日常询问在于调动组员的积极性,让其产生责任感。
四、团队代码规范
1、命名风格
-
【强制】代码中的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束。
-
反例:name / name / $name / name / name$ / name
-
【强制】代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式。
-
说明:正确的英文拼写和语法可以让阅读者易于理解,避免歧义。注意,即使纯拼音命名方式也要避免采用。国际通用的名称,可视同英文。
-
反例:DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3
-
【强制】类名使用 UpperCamelCase 风格,但以下情形例外:DO / BO / DTO / VO / AO / PO / UID 等。
-
正例:MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
-
反例:macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
-
【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格,必须遵从驼峰形式。
-
正例: localValue / getHttpMessage() / inputUserId
-
【强制】常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。
-
正例:MAX_STOCK_COUNT
-
反例:MAX_COUNT
-
【强制】抽象类命名使用 Abstract 或 Base 开头;异常类命名使用 Exception 结尾;测试类 命名以它要测试的类的名称开始,以 Test 结尾。
-
【强制】包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式,但是类名如果有复数含义,类名可以使用复数形式。
-
正例:应用工具类包名为 com.alibaba.ai.core.util、类名为 MessageUtils(此规则参考 spring 的框架结构)
-
【强制】杜绝完全不规范的缩写,避免望文不知义。
-
反例:AbstractClass“缩写”命名成AbsClass;condition“缩写”命名成 condi,此类随 意缩写严重降低了代码的可阅读性。
-
【推荐】为了达到代码自解释的目标,任何自定义编程元素在命名时,使用尽量完整的单词组合来表达其意。
-
正例:在 JDK 中,表达原子更新的类名为:AtomicReferenceFieldUpdater。
-
反例:变量 int a 的随意命名方式。
2、代码格式
-
大括号的使用约定。如果是大括号内为空,则简洁地写成{}即可,不需要换行;如果是非空代码块则:
左大括号前不换行。
左大括号后换行。
右大括号前换行。
右大括号后还有 else 等代码则不换行;表示终止的右大括号后必须换行。
-
if/for/while/switch/do 等保留字与括号之间都必须加空格。
-
采用 4 个空格缩进,禁止使用 tab 字符。
-
类、类属性、类方法的注释必须使用 Javadoc 规范,使用/**内容*/格式,不得使用 // xxx 方式。
-
所有的抽象方法(包括接口中的方法)必须要用 Javadoc 注释、除了返回值、参数、异常说明外,还必须指出该方法做什么事情,实现什么功能。
3、注释规约
说明:对子类的实现要求,或者调用注意事项,请一并说明。
-
所有的类都必须添加创建者和创建日期。
-
方法内部单行注释,在被注释语句上方另起一行,使用//注释。方法内部多行注释 使用/* */注释,注意与代码对齐。
-
所有的枚举类型字段必须要有注释,说明每个数据项的用途。
-
与其“半吊子”英文来注释,不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
-
代码修改的同时,注释也要进行相应的修改,尤其是参数、返回值、异常、核心逻辑等的修改。
五、 构建之法阅读
13章 软件测试
14章 质量保障
15章 稳定和发布阶段
16章 IT行业的创新
17章 人,绩效和职业道德