团队作业（三）：确定分工

一、需求规格说明书的修改

二、代码规范和编码原则

(一)、代码规范

每个人对于什么是“好”的代码规范未必认同，这是我们很有必要给出一个基本准线————什么是好的代码规范和设计规范。

代码规范可以分成两个部分：
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）数据结构中有没有用不到的元素？
码云链接

三、团队项目的数据库设计

图3.1ER图设计

图3.2Powerdesigner数据库设计

四、项目的后端架构设计

我们的功能架构设计以电子邮箱的基本架构为模板，并基于电子公文传输系统的特性作适当延伸。

MVC角度体系结构

MVC结构由Model(模型)、View(视图)、Controller(控制器)组成。MVC将人机交互从核心功能分离出来，模型对于用户来说是透明的，用户只需要观察视图，用户和模型的交互通过控制其提供的安全方法。

模型（Model） 包含核心功能和数据和后台的业务逻辑，在模型这一层封装了访问数据的函数，例如公文信息、用户信息等。这一层对于用户来说是透明的，用户看不到后台对数据库的操作。
视图（View） 负责向用户显示信息，不同的角色可以看见的视图不同。用户在视图上与系统进行交互，一些用户的行为（例如发件、收件等）会触发模型的功能，从而向模型传递数据或者得到模型更新后的数据。
控制器（Controller） 与视图一一对应，每个视图都有一个相关的控制器，控制器组件接受事件，并将事件翻译成堆模型或者视图的请求。如果控制器的行为依赖于模型的状态，那么控制器也需要向模型登记请求变更通知。
例如，用户在视图中点击发件按钮，控制器接到此事件后，调用模型的发件方法，导入数据库中收发双方用户对应的信息，再显示到视图中去。

用户角度功能架构

用户管理

包括注册、登录、注销、更改密码等操作
文件处理

包括发件、收件、阅件、归档、删除等操作

需要提供对公文各项内容的分块处理，如标题、单位、时限、密级、时间等项需要提取出来，方便归纳整理。具体设计如下：

除此之外，在传输文件时需要进行加密传输处理，防止公文泄露。

五、确定团队分工

图5.1WBS图

任务	完成成员	协作成员	工作量
发文模块	宋非凡蒋嘉豪王浩博	李长兴、宋雷	1/3
收文模块	李长兴、宋雷	周凌霄、周昱涵	1/3
系统管理模块	周凌霄、周昱涵	宋非凡蒋嘉豪王浩博	1/3

图5.2燃尽图

六、分工和工作量比例

任务	完成成员	协作成员	工作量
需求规格说明书的修改	宋非凡		1/7
代码规范和编码原则	蒋嘉豪		1/7
团队项目的数据库设计	王浩博、周昱涵		2/7
项目的后端架构设计	宋雷、李长兴		2/7
确定团队分工	周凌霄	王浩博宋非凡蒋嘉豪周昱涵宋雷李长兴	1/7

七、参考资料

1.如何画数据库ER图
 2.怎样绘制ER图

电子公文传输系统 确定分工