团队作业（三）：确定分工
团队作业（三）：确定分工
一、需求规格说明书的修改
规格说明书
1.解决了图片不可见的问题。
2.验收验证标准并没有公文操作方面的介绍。
3.编辑文档格式方面：在一些开头加了空格，因为Markdown加空格有点麻烦。还有的地方没有换行（已经修改）。
二、代码规范和编码原则
代码风格规范
（1）缩进4个空格
（2）限定100字符行宽
（3）在复杂的条件表达式中，用括号表示逻辑优先级
（4）每个“{”和“}”都独占一行
（5）不把多个变量定义在一行
（6）命名
（7）下划线用来分割变量名字中的作用域标注和变量的语义
（8）用大小写区分由多个单词组成的变量名
（9）注释
代码设计规范
1、函数：只做一件事，做好一件事；
2、goto：可使用goto实现函数的单一出口（但也要尽量少使用）；
3、错误处理：在Debug版本中，所有参数都要验证其正确性，在正式版本中，对外部转递就俩的参数要验证其正确性；
4、运算符：一般情况下不需要自定义操作符，运算符不要做标准语义以外的任何动作。运算符的实现必须非常有效率，如有复杂的操作，应定义一个单独的函数；
代码复审
目的：
（1）找出代码错误
（2）发现逻辑错误，程序可以编译通过，但是代码的逻辑是错的
（3）发现算法错误
（4）发现潜在的错误和回归性错误——当前的修改导致以前修复的缺陷又重新出现
（5）发现可能需要改进的地方
（6）教育开发人员，传授经验
核查表：
（1）概要
（2）设计规范
（3）代码规范
（4）具体代码
（5）效能
（6）可读性
（7）可测性
三、团队项目的数据库设计
ER图：
四、项目的后端架构设计
MVC角度体系结构
MVC结构由Model(模型)、View(视图)、Controller(控制器)组成。MVC将人机交互从核心功能分离出来，模型对于用户来说是透明的，用户只需要观察视图，用户和模型的交互通过控制其提供的安全方法。
模型（Model） 包含核心功能和数据和后台的业务逻辑，在模型这一层封装了访问数据的函数，例如公文信息、用户信息等。这一层对于用户来说是透明的，用户看不到后台对数据库的操作。
视图（View） 负责向用户显示信息，不同的角色可以看见的视图不同。用户在视图上与系统进行交互，一些用户的行为（例如发件、收件等）会触发模型的功能，从而向模型传递数据或者得到模型更新后的数据。
控制器（Controller） 与视图一一对应，每个视图都有一个相关的控制器，控制器组件接受事件，并将事件翻译成堆模型或者视图的请求。如果控制器的行为依赖于模型的状态，那么控制器也需要向模型登记请求变更通知。
例如，用户在视图中点击发件按钮，控制器接到此事件后，调用模型的发件方法，导入数据库中收发双方用户对应的信息，再显示到视图中去。
用户角度
数据存储
-
数据分类
-
缓存策略
-
数据压缩
-
数据转码
-
安全问题
保证我们应用程序的安全是非常重要的。我们整体架构都要有安全上的考虑。我在这里只谈架构为满足安全要求做出的改变，我们不谈实施过程的改变。
这里是一些必须添加到架构里的：
- 我们所有的用户数据必须加密。MongoDB和Neo4j已经支持存储加密。在这基础上，我们可以决定加密哪些用户关键信息。所有与数据库相关的传输调用必须启用加密。
- 安全套接字层：所有代理服务器的访问都应该使用SSLed。代理服务器可以充当SSL终止点。
- 我们所有的API端点应该运行在非默认端口，并且必须实现OAuth。
- 所有的DB读取都应该通过Rest endpoints。
- 有关密码的配置必须特殊处理。密码必须hashed，文件应该被限制只能在应用启动时读取。这允许我们通过文件系统权限来控制应用程序身份实例。只有应用程序用户可以读，但不能写，其他用户不可以读取。所有类似的配置都要用keydb打包并需要密码。
组件
以下是我们架构用到的组件:
- 负载均衡器：这层是用来转发所有对代理服务器的请求，基于定制的策略。这一层也将有助于我们通过基于容量重定向的方式来保障可用性。
- 代理服务器：所有即将到来的调用都必须以这里为入口。这也是我们SSL的终止点。它缓存所有基于策略定义的HTTP请求。FE层：该层运行一个node服务器。
- 数据输入引擎：这个组件涉及所有内容的输入，它做了一系列的工作:非规范化模型，转码，缓存等。将来如果可以的话，所有内容的处理，都可以在这里完成。
- Rest服务：这层负责与所有DB交互，并返回数据。它的访问是受OAuth保护的。这可以用Tomcat容器以及edge缓存来实现。
- 事件处理：这层处理所有的事件，主要负责分发的功能。它读取ActiveMQ并使用通知引擎生成通知
人机交互
组件
服务器责负载均衡
分发流量到服务
五、确定团队分工
组员：卢翰祺、彭信民、张宇鹏、陈冠昊、骆毅，各20%
