团队作业（三）：确定分工
一、任务目录
1.修改完善上周提交的需求规格说明书
2.确定团队的编码规范
3.使用Powerdesigner绘制ER图，进行项目的后端架构设计
4.绘制团队wbs图，协助后端架构设计
5.任务分配，确定团队分工
6.资料收集整合，博客撰写
二、组员分工
结合个人意愿及特长，小组内部分工如下：
| 小组成员 | 任务分工 |
|---|---|
| 20201212杨铖宇 | 任务分配，确定团队分工 |
| 20201213郭幸坤 | 确定团队的编码规范 |
| 20201214罗云帆 | 绘制ER图，后端架构设计 |
| 20201220蔡笃俊 | 完善需求规格说明书 |
| 20201221曾思源 | 资料收集整合，博客撰写 |
| 20201229赵斌 | 绘制wbs图，协助后端架构设计 |
三、组员工作量比例
| 小组成员 | 工作量比例 |
|---|---|
| 20201212杨铖宇 | 1/6 |
| 20201213郭幸坤 | 1/6 |
| 20201214罗云帆 | 1/6 |
| 20201220蔡笃俊 | 1/6 |
| 20201221曾思源 | 1/6 |
| 20201229赵斌 | 1/6 |
Ⅰ 修改完善需求规格说明书
修改后的需求规格说明书：需求规格说明书
Ⅱ 讨论制定团队的代码规范和编码原则
代码规范和编码原则
(一)、代码规范
代码规范可以分成两个部分：
- 代码风格规范，主要是文字上的规定；
- 代码设计规范，牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。
(二)、代码风格规范
- 代码风格的原则是：简明、易读、无二义性。
- 缩进、括号和分行
- 缩进：将Tab键扩展定义为4个空格。不直接使用tab键的原因是它在不同的情况下会显示不同的长度。4个空格可读性高；
- 行宽：行宽必须限制，建议100字符；
- 括号：在复杂的条件表达式中，用括号清楚地表示逻辑优先级；
- 断行与空白的{}行：
- 分行：不要把多中不同的操作放在同一行（书中建议“不要把多个变量定义在一行”，可能会使代码不够简洁）；
- 命名：“匈牙利命名法”；
- 下划线：分隔变量名字中的作用域标注的变量的语义；
- 大小写：全部大写、小写会导致不易读，所有的类型/类/函数名用 Pascal 形式（每个单词首字母大写），所有变量都用 Camel （第一个单词小写，后面用 Pascal ）；
- 注释：解释程序做什么，为什么这样做。复杂的注释放在函数头，解释参数，要不断更新（书中建议使用ASCII码以增强可移植性，但实际操作复杂，我们不做这方面的要求）；
(三)、代码设计规范
- 函数：只做一件事，做好一件事；
- goto：可使用goto实现函数的单一出口（但也要尽量少使用），
助于程序逻辑的清晰体现 - 错误处理：
参数处理、断言。
在Debug版本中，所有参数都要验证其正确性，在正式版本中，对外部转递就俩的参数要验证其正确性；
4、运算符：一般情况下不需要自定义操作符，运算符不要做标准语义以外的任何动作。运算符的实现必须非常有效率，如有复杂的操作，应定义一个单独的函数；
3.1 单一职责原则 Single Responsibility Principle
- 一个类或者一个接口，最好只负责一项职责。
- 遵循单一职责原则。分别建立新的类来对应相应的职责；这样就能避免修改类时影响到其他的职责；
3.2 里氏替换原则 Liskov Substitution Principle
- 在使用基类的地方可以任意使用其子类，能保证子类完美替换基类；这一种精神其实是对继承机制约束规范的体现。在父类和子类的具体实现中，严格控制继承层次中的关系特征，以保证用子类替换基类时，程序行为不发生问题，且能正常进行下去。
- 对于继承来说，父类定义了一系列的规范和契约，虽然不强制所有的子类必须遵从，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破环。
3.3依赖倒置原则 Dependence Inversion Principle
- 高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象，其核心思想是依赖于抽象；
- 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来完成；这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原则操作；假如修改类A，会给程序带来不必要的风险。
- 在实际中，我们一般需要做到以下三点：
- 低层模块尽量都要有抽象类或者接口，或者两者都有；
- 变量的声明类型尽量是抽象类或者接口；
- 使用继承时遵循里氏替换原则；
- 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I来间接与类B和类C发生联系，则会降低修改类A的几率；
3.4接口隔离原则 Interface Segregation Principle
-
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上，否则将会造成接口污染；类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现它们不需要的方法；
-
原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少；就是说，我们要为每个类建立专用的接口，而不要试图去建立一个庞大的接口供所有依赖它的类去调用；
-
如何实施接口隔离，主要有两种方法：
- 委托分离，通过增加一个新的接口类型来委托客户的请求，隔离客户和接口的直接依赖，注意这同时也会增加系统的开销；
- 多重继承分离，通过接口的多重继承来实现客户的需求；
3.5迪米特法则
一个对象应该对其他对象保持最少的了解，其核心精神就是：不和陌生人说话，通俗之意就是一个对象对自己需要耦合关联调用的类应该知道的少；这会导致类之间的耦合度降低，每个类都尽量减少对其他类的依赖。
3.6合成复用原则
原则是尽量使用合成/聚合的方式，而不是使用继承；
3.7开闭原则
一个软件实体如类、模版和函数应该对扩展，对修改关闭；
解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是修改已有的代码来实现变化；
-
单一职责原则：实现类要职责单一；
-
里氏替换原则：不要破坏继承体系；
-
依赖倒置原则：面向接口编程；
-
接口隔离原则：设计接口的时候要精简单一；
-
迪米特法则：降低耦合；
-
开闭原则：总纲，对扩展开放，对修改关闭；
3.8命名规范
- 函数命名规范：使用驼峰法，其基本原则为：动作+(关联)+内容 例如：getUserName(获取用户名字)。
- 变量命名：采用匈牙利命名法，其基本原则是：变量名=属性+类型+对象描述。
- 命名大小写规范：所有函数名使用Pascal形式命名，即所有单词的第一个字母都大写。所有类型和变量名使用Camel方式命名，即第一个单词使用小写开头，后面都用大写字母开头。 ##注释要求
- 必须的注释：注释用于解释程序做什么（what）、为什么（why）和其他需要注意的地方。函数头写注释，标记本函数的作用。较难理解的部分必须写注释。
- 不需要注释：不刻意写注释，不需要解释就能读懂的部分不写注释。
(四)、代码复审
- 形式：自我复审、同伴复审、团队复审
- 目的：找出代码错误、发现逻辑错误、发现算法错误、发现潜在的错误和回归性错误、发现可能需要改进的地方、传授经验
- 代码复审后把记录整理出来：
- 更正明显的错误
- 记录无法很快更正的错误
- 把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步
Ⅲ 绘制ER图
Ⅳ 项目的后端架构设计
Ⅴ 确定团队分工
利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。
Ⅵ 小组成员学习心得
蔡笃俊：本次团队作业我负责的是完善需求规格说明书部分。这次作业我们团队进行了一次线下讨论，一起进行了项目的需求分析并确定了本次任务的分工。大家在一起各抒己见，分析我们的项目有什么需要改进的地方。最终我们经过一致肯定，提出了许多修改意见，我也得以顺利的进一步完善我们的需求规格说明书，在原有的基础上增加了用户登录权限选项功能，修改了一些有瑕疵的地方，让我感受到团队合作的力量所在。
郭幸坤：本次团队作业我负责的是制定团队的代码规范和编码原则。每一个优秀的程序员都应该遵循代码规范及编码原则，参考《构建之法》，我们总结出团队的代码规范和编码原则。主要从程序风格、变量命名、注释、函数、格式、对象与数据结构、错误处理等方面进行约束。通过学习和实践，我逐渐意识到代码规范的重要性，在开发上能够提供更好的设计质量，合作解决的能力更强；对开发人员带来更多信心，高质量产出可带来更高满足感；在项目管理上可以有效交流，相互学习和传递经验，取得更高投入产出比。
曾思源：本次团队作业我负责的是优化博客园界面以及撰写本次博客。经过杨铖宇同学的指导和帮助，我们的博客园界面焕然一新。内涵固然重要，而外在同样也具有很大作用，不能“金玉其内，败絮其外”。在编排的过程中，我同样对于小组成员之间的精密配合以及分工合作有了更加直观的认识，相信我们这样一支“专业团队”一定能做出满意的作品。
赵斌：本次团队作业我负责的是绘制WBS图以及后端架构设计。我们先集体讨论了所有主要项目工作，确定项目分解的方式，从需求分析书出发，确定了适当的WBS层次。这次作业让我认识到，对于一个宏大的目标，利用任务分解的原则有助于将主体目标逐步细化分解，一目了然，避免错过细节，以后要在实践中多运用这种方法。
杨铖宇：本次团队作业我负责的是任务分配及博客美化。我们针对每个人的特长与优势，进行了任务分工。团队管理中如何做好任务分配，平衡团队战斗能力？这个问题的本质，在于如何带动后进成员，而不是简单和被动的因材分工，因为成员如果没有进步，始终是治标不治本的。所以，面对每个人的任务，组内成员都及时提供帮助并指出不足，以更好完成任务内容。其次，我进行了博客的美化，将上学期web课程学习的内容应用到了博客园界面的美化上。
罗云帆：本次团队作业我负责的是er图以及数据库的设计部分。在这一部分当中我使用了powerdesigner软件绘制出了图片，并对其进行了破解与汉化。从需求分析出发，我们组不仅把数据按角色进行区分，也按照密级进行区分，从而确定每个用户可以进行的操作。这次的作业也让我学到了数据库设计所涉及到的各种属性，流程，实体数据处理等等。还有对于一个较为困难的目标，要学会团队合作与分而治之的思路，一步一步地解决问题往往胜过一口吃成个胖子。
