项目名：电子公文传输系统
成员：王浩博 宋非凡 蒋嘉豪 周昱涵 宋雷 李长兴 周凌霄
日期：2020年10月27日
团队作业（三）：确定分工
一、需求规格说明书的修改
二、代码规范和编码原则
(一)、代码规范
每个人对于什么是“好”的代码规范未必认同，这是我们很有必要给出一个基本准线————什么是好的代码规范和设计规范。
代码规范可以分成两个部分：
1、代码风格规范，主要是文字上的规定；
2、代码设计规范，牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。
(二)、代码风格规范
代码风格的原则是：简明、易读、无二义性。
1、缩进：将Tab键扩展定义为4个空格。不直接使用tab键的原因是它在不同的情况下会显示不同的长度。4个空格可读性高；
2、行宽：行宽必须限制，建议100字符；
3、括号：在复杂的条件表达式中，用括号清楚地表示逻辑优先级；
4、断行与空白的{}行：
if(condition) DoSomthing();
else DoSomethingElse();
这样调试起来很不方便，而且在多层嵌套时不容易理清结构和对应关系，建议如下：
if(condition)
{
DoSomthing();
}
else
{
DoSomethingElse();
}
5、分行：不要把多中不同的操作放在同一行（书中建议“不要把多个变量定义在一行”，可能会使代码不够简洁）；
6、命名：“匈牙利命名法”；
7、下划线：分隔变量名字中的作用域标注的变量的语义；
8、大小写：全部大写、小写会导致不易读，所有的类型/类/函数名用 _Pascal_ 形式（每个单词首字母大写），所有变量都用 _Camel_ （第一个单词小写，后面用 _Pascal_ ）；
9、注释：解释程序做什么，为什么这样做。复杂的注释放在函数头，解释参数，要不断更新（书中建议使用ASCII码以增强可移植性，但实际操作复杂，我们不做这方面的要求）；
(三)、代码设计规范
1、函数：只做一件事，做好一件事；
2、goto：可使用goto实现函数的单一出口（但也要尽量少使用）；
3、错误处理：在Debug版本中，所有参数都要验证其正确性，在正式版本中，对外部转递就俩的参数要验证其正确性；
4、运算符：一般情况下不需要自定义操作符，运算符不要做标准语义以外的任何动作。运算符的实现必须非常有效率，如有复杂的操作，应定义一个单独的函数；
(四)、代码复审
看代码是否在“代码规范”的框架内正确地解决了问题
1、目的：找出代码的错误————编写错误、不符合团队代码规范的地方、逻辑错误、算法错误、潜在错误、可能要改进的地方；
2、why：即使代码是完美的，复审也有教育和传播知识的作用。越到后期，修复代码的代价会越大，我们要早发现早修复。
3、具体代码部分的复审：
（1）有没有对错误进行处理？调用外部函数是是否检查了返回值或处理了异常？
（2）参数传递有无错误？
（3）边界条件是如何处理的？（switch中default的处理、有没有可能出现死循环）
（4）有没有使用断言（Assert）来保证我们认为不变的条件真的得到满足？
（5）对资源的利用，是在哪里申请，哪里释放的？是否存在泄漏？有无优化空间？
（6）数据结构中有没有用不到的元素？
码云链接
三、团队项目的数据库设计
四、项目的后端架构设计
我们的功能架构设计以电子邮箱的基本架构为模板，并基于电子公文传输系统的特性作适当延伸。
MVC角度体系结构
MVC结构由Model(模型)、View(视图)、Controller(控制器)组成。MVC将人机交互从核心功能分离出来，模型对于用户来说是透明的，用户只需要观察视图，用户和模型的交互通过控制其提供的安全方法。
- 模型（Model） 包含核心功能和数据和后台的业务逻辑，在模型这一层封装了访问数据的函数，例如公文信息、用户信息等。这一层对于用户来说是透明的，用户看不到后台对数据库的操作。
- 视图（View） 负责向用户显示信息，不同的角色可以看见的视图不同。用户在视图上与系统进行交互，一些用户的行为（例如发件、收件等）会触发模型的功能，从而向模型传递数据或者得到模型更新后的数据。
- 控制器（Controller） 与视图一一对应，每个视图都有一个相关的控制器，控制器组件接受事件，并将事件翻译成堆模型或者视图的请求。如果控制器的行为依赖于模型的状态，那么控制器也需要向模型登记请求变更通知。
例如，用户在视图中点击发件按钮，控制器接到此事件后，调用模型的发件方法，导入数据库中收发双方用户对应的信息，再显示到视图中去。
用户角度功能架构
-
用户管理
包括注册、登录、注销、更改密码等操作
-
文件处理
包括发件、收件、阅件、归档、删除等操作
需要提供对公文各项内容的分块处理，如标题、单位、时限、密级、时间等项需要提取出来，方便归纳整理。具体设计如下：
除此之外，在传输文件时需要进行加密传输处理，防止公文泄露。
五、确定团队分工
| 任务 | 完成成员 | 协作成员 | 工作量 |
|---|---|---|---|
| 发文模块 | 宋非凡 蒋嘉豪 王浩博 | 李长兴、宋雷 | 1/3 |
| 收文模块 | 李长兴、宋雷 | 周凌霄、周昱涵 | 1/3 |
| 系统管理模块 | 周凌霄、周昱涵 | 宋非凡 蒋嘉豪 王浩博 | 1/3 |
六、分工和工作量比例
| 任务 | 完成成员 | 协作成员 | 工作量 |
|---|---|---|---|
| 需求规格说明书的修改 | 宋非凡 | 1/7 | |
| 代码规范和编码原则 | 蒋嘉豪 | 1/7 | |
| 团队项目的数据库设计 | 王浩博、周昱涵 | 2/7 | |
| 项目的后端架构设计 | 宋雷、李长兴 | 2/7 | |
| 确定团队分工 | 周凌霄 | 王浩博 宋非凡 蒋嘉豪 周昱涵 宋雷 李长兴 | 1/7 |