团队作业（三）
1.修改完善上周提交的需求规格说明书，需求规格书
2.编码规范
团队的编码规范和编码原则
程序风格：
严格采用阶梯层次组织程序代码：每层次缩进为4格，括号位于下一行。要求相匹配的大括号在同一列，对继行则要求再缩进4格
提示信息字符串的位置：在程序中需要给出的提示字符串，为了支持多种语言的开发，除了一些给调试用的临时信息外，其他所有的提示信息必须定义在资源中。
对变量的定义，尽量位于函数的开始位置。
变量名的命名规则：
只能由字母、数字、下划线组成
第一个字符必须是英文字母
有效长度为255个字符
不可以包含标点符号和类型说明符%,&,!,# ,@,$
不可以是系统的关键词比如else
注释
注释要简单明了
边写代码边注释，修改代码同时修改相应的注释，以保证 注释与代码的一致性
在必要的地方注释，注释量要适中，注释的内容要清楚，明了，含义准确，防止注释二义性，保持注释与其描述的代码相邻，即注释的就近原则
对代码的注释应放在其上方相邻位置，不可放在下面
全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明
在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描述
输入，输出及返回值说明；调用关系及被调用关系说明等
可读性
避免使用不易理解的数字，用有意义的标识来替代
不要使用难懂的技巧性很高的语句
源程序中关系较为紧密的代码应尽可能相邻
函数
一个函数最好仅完成一件功能
为简单功能编写函数
函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出
避免设计多参数函数，不使用的参数从接口中去掉
用注释详细说明每个参数的作用、取值范围及参数间的关系
检查函数所有参数输入的有效性
函数名应准确描述函数的功能
函数的返回值要清楚、明了，让使用者不容易忽视错误情况
明确函数功能，精确（而不是近似）地实现函数设计
变量编辑
去掉没必要的公共变量
构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数只访问的公共变量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象
仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系
明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等
当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生
防止局部变量与公共变量同名
仔细设计结构中元素的布局与排列顺序，使结构容易理解、节省占用空间，并减 少引起误用现象
结构的设计要尽量考虑 向前兼容和以后的版本升级，并为某些未来可能的应用保留余地（如预留一些空间等）
留心具体语言及编译器处理不同数据类型的原则及有关细节
严禁使用未经初始化的变量，声明变量的同时对变量进行初始化
编程时，要注意数据类型的强制转换
代码编译
编写代码时要注意随时保存，并定期备份，防止由于断电、硬盘损坏等原因造成代码丢失
同一项目组内，最好使用相同的编辑器，并使用相同的设置选项
打开编译器的所有告警开关对程序进行编译
- 通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。
- MVC角度体系结构
MVC结构由Model(模型)、View(视图)、Controller(控制器)组成。MVC将人机交互从核心功能分离出来，模型对于用户来说是透明的，用户只需要观察视图，用户和模型的交互通过控制其提供的安全方法。
- 模型（Model）包含核心功能和数据和后台的业务逻辑，在模型这一层封装了访问数据的函数，例如公文信息、用户信息等。这一层对于用户来说是透明的，用户看不到后台对数据库的操作。
- 视图（View）负责向用户显示信息，不同的角色可以看见的视图不同。用户在视图上与系统进行交互，一些用户的行为（例如发件、收件等）会触发模型的功能，从而向模型传递数据或者得到模型更新后的数据。
- 控制器（Controller）与视图一一对应，每个视图都有一个相关的控制器，控制器组件接受事件，并将事件翻译成堆模型或者视图的请求。如果控制器的行为依赖于模型的状态，那么控制器也需要向模型登记请求变更通知。
- 例如，用户在视图中点击发件按钮，控制器接到此事件后，调用模型的发件方法，导入数据库中收发双方用户对应的信息，再显示到视图中去。
用户角度功能架构
- 用户管理
- 包括注册、登录、修改权限等操作
- 文件处理
- 包括发件、收件、阅件、归档、删除等操作
数据库设计
- 确定团队分工。
WBS图。
