团队作业(三):确定分工

团队作业(三):确定分工

1、修改完善上周提交的需求规格说明书,并在博客中描述:上次的《需求规格说明书》初稿有哪些不足?修改需同时体现在Github的MarkDown文件与PDF中。(提示:功能考虑不全或需求文档描述缺少的地方。)

明确了每一个小词条所归属的大词条,防止出现勿看的情况;
增加了一个分割线在大词条之间,在小词条下的小点也同样进行了标注,使阅读更加简便;
明确了用户之间的区别,增加了管理员的责任。

《需求规格说明书》修订版

2、讨论制定团队的编码规范,讨论之前和讨论之后,队员阅读《构建之法》第四章内容,并讨论总结。将代码规范和编码原则发布在随笔上,并说说你们这么选择的理由。

在编写代码常常存在这样的问题:
代码冗余
可阅读查性差
逻辑复杂,不利于维护
出了后bug无法快速定位问题
对于这类由于编写代码不规范导致的问题,制定代码规范能够有效减少问题的发生。本小组经过讨论,制定本小组的代码编写规范

(1)命名风格

1.代码中的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束
2.代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式
3.类名、参数名、方法名、成员变量、局部变量都统一使用UpperCamelCase风格,必须遵从驼峰形式
4.常量命名全部大写,单词用下划线隔开
5.抽象类命名使用Abstract开头;异常类命名使用Exception结尾;测试类命名以它要测试的类的名称开始,以Test结尾
6.包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词
常量定义
7.不允许任何未经定义的常量直接出现在代码中
8.不可以是系统的关键词,比如else

(2)函数设计

1.函数的规模尽量限制在200行以内。
2.一个函数最好仅完成一件功能。
3.为简单功能编写函数。
4.尽量不要编写依赖于其他函数内部实现的函数。
5.避免设计多参数函数,不使用的参数从接口中去掉。
6.用注释详细说明每个参数的作用、取值范围及参数间的关系。
7.检查函数所有参数输入的有效性。
8.检查函数所有非参数输入的有效性,如数据文件、公共变量等。
9.函数名应尽量准确描述函数的功能,实在不行可在旁注释进行解释。
10.函数的返回值要清楚、明了,让使用者不容易忽视错误情况。
11.减少函数本身或函数间的递归调用。

(3)代码注释

1.注释要简单明了,确保阅读代码者能基本知道代码的功能或含义。
2.边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性。
3.在必要的地方注释,注释量要适中。注释的内容要清楚、明了,含义准确,防止注释二义性。
4.保持注释与其描述的代码相邻,即注释的就近原则。
5.对数据结构的注释应放在其上方相邻位置,不可放在下面;对结构中的每个域的注释应放在此域的右方;同一结构中不同域的注释要对齐。
6.全局变量要有较详细的注释,包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。
7.在每个函数或过程的前面要有必要的注释信息,包括:函数或过程名称;功能描 述;输入、输出及返回值说明;调用关系及被调用关系说明等。

(4)变量设置

1.设置公共变量确保有意义,不设置多余的公共变量,减少代码量。   
2.构造仅有一个模块或函数可以修改、创建,而其余有关模块或函数只访问的公共变量,防止多个不同模块或函数都可以修改、创建同一公共变量的现象。  
3.仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。  
4.明确公共变量与操作此公共变量的函数或过程的关系,如访问、修改及创建等。   
5.当向公共变量传递数据时,要十分小心,防止赋与不合理的值或越界等现象发生。  
防止局部变量与公共变量同名。   

(5)代码管理

1.编写代码时要注意随时保存,每次关闭前进行保存,并定期备份,防止由于断电、硬盘损坏等原因造成代码丢失。
2.当代码出现问题,其他组员帮助检查。
3.同一项目组内,最好使用相同的软件编辑器,并使用相同的设置选项。
4.打开编译器的所有告警开关对程序进行编译。
5.使用工具软件、代码托管网站对代码进行维护。


3、通过Powerdesigner完成团队项目的数据库设计,并在随笔中提供相应ER图。


4、进行项目的后端架构设计,要与需求规格说明书中的界面原型设计相对应。


5、确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)",提供下述内容:

(1)利用象限法确定各个核心需求的优先级,依据需求优先级确定团队Alpha 版本需要实现的功能,在博客中叙述并给出相应的WBS图。

(2)在团队管理软件中(比如Github的Issue,Leangoo等)将各个叶子结点的功能加入,并确定每个子功能的工作量,在博客中给出分配后的截图。值得注意的是,与学习技术相关的任务也需要考虑在工作量中,开发需要检验产出,学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。

(3)给出团队各个成员(用学号代替姓名)认领的工作,列出当前团队的TODOList,并在最后给出燃尽图。

6、描述组员在上述任务中的分工和工作量比例。

(1)修改完善上周提交的需求规格说明书(10'):唐子越
(2)制定团队的编码规则(10'):戴君熹
(3)通过Powerdesigner完成团队项目的数据库设计,并在随笔中提供相应ER图(10'):董佳帅
(4)进行项目的后端架构设计(10'):王竞锐
(5)确定团队分工(15'):刘嘉祺
博客撰写:戴君熹

posted @ 2021-10-31 21:27  djx20191313  阅读(126)  评论(0编辑  收藏  举报