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

一、修改完善上周提交的需求规格说明书

• 上次制定的需求规格说明书中指定的部分内容实现起来较为困难，经过修改完善，我们删除了部分模块。
• 修改产品功能和验收标准、细化界面描述、完善产品说明

 

二、讨论制定团队的编码规范

代码规范可以分为两个部分：

• 代码风格规范。主要是文字上的规定，看似表面文章，实际非常重要。
• 代码设计规范。牵涉到程序设计、模块之间的关系、设计模式等方方面面通用的原则。

在一个团队中，使用统一的代码规范非常重要。

代码风格规范

代码风格的原则是：简单，易读，无二义性。采取何种代码规范要看这种代码规范能否让程序员更好的理解和维护程序。

代码风格规范具体包括以下几点：

• 缩进。推荐使用四个空格进行缩进，最好在编辑器中将Tab键定义为四个空格，这样可以避免Tab键在不同情况下显示不同的问题，并使程序有良好的阅读体验。
• 行宽。最好对行宽作出限制，按照现代普遍使用的屏幕尺寸，可以考虑将行宽限制为100个字符。
• 括号。在复杂的表达式中，使用括号表示逻辑优先级。
• 断行与空白的｛｝行。推荐每个｛和｝都单独占一行。
• 分行。不要把多条语句放在一行上，更严格的说不要把多个变量定义在一行上。
• 命名。命名要注意几条关键原则，简单来说就是确保包含必要信息，避免过多的描述。
• 下划线。下划线用来分隔变量名字中的作用于标注和变量的语义。
• 大小写。通用的做法是，类型、类、函数名多有单词的第一个字母都大写，变量名第一个单词全部小写，其他单词首字母大写。
• 注释。复杂的注释放在函数头，不做不必要的注释，注释中应只使用ASCII字符。

代码设计规范

代码设计规范不只是程序书写格式的问题，而且牵涉到程序的设计、模块之间的关系、设计模式等方方面面。这里主要讨论通用的原则。

• 函数。关于函数，最重要的一条原则就是：只做一件事，并且要做好。
• goto。函数最好有单一的出口，为了达到这一目的，可以使用goto。
• 错误处理。首先要验证参数的正确性，当认为一件事肯定如何时，可以使用断言。
• 处理c++中的类。使用类来封装面向对象的概念和多态；避免传递类型实体的值，而用指针传递，也就是说简单的数据类型没有必要用类来实现；对于有显示构造和析构的类，不要创建全局的实体。
• 类还是结构体。如果只是数据的封装，用结构体即可。
• 按照这样的顺序来说明类中的成员：public、protected、private。
• 数据成员。数据类型的成员用m_name说明；不使用公共的数据成员，要用inline访问函数，这样可兼顾封装和效率。
• 虚函数。使用虚函数来实现多态；尽在很有必要时使用虚函数；如果一个类型要实现多态，在基类中的析构函数应该是虚函数。
• 构造函数。不要再构造函数中做复杂的操作，简单初始化数据称成员即可；构造函数不应返回错误，把可能出错的操作放到HrInit（）或FInite（）中。
• 析构函数。把所有的清理工作放在析构函数中；同时析构函数也不应出错。
• new和delete。实现自己的new/delete可以方便地加上自己的跟踪和管理机制；检查new的返回值；释放指针时不用检查NULL。
• 运算符。运算符不要做标准语义外的任何操作；运算符的实现应非常高效，如果操作复杂，定义一个单独的函数，如果拿不定主意，用成员函数而不要用运算符。
• 异常。异常不能跨过DLL或进程的边界来传递信息。
• 类型继承。仅在必要时使用类型继承；用const标注只读的参数；用const标注不改变数据的函数。

代码复审

代码复审的目的在于找出代码的编码错误、格式错误、逻辑错误、算法错误、潜在的错误和回归性错误、发现可能需要改进的地方、互相教育互相学习。

代码复审的核查表要包括概要部分、设计规范部分、代码规范部分、具体代码部分、效能、可读性、可测试性这几个条目。

结对编程

结对编程可以实现不间断的复审，能减少程序错误，提高程序质量，节省以后修改和测试的时间。在结对编程中要注意正确的给予反馈。

 

三、 完成团队项目的数据库设计，并在随笔中提供相应ER图

 

 

 

 

 

 

四、后端架构设计，要与需求规格说明书中的界面原型设计相对应

 

 

 

 

五、团队分工

 

 

 

 

 

项目名	具体分工	实现人
电子 公文 传输 系统	注册与登录	戴易刚
	加解密	姚渊升、陈维
	用户功能	刘卓
	客户端开发	李根
	文件操作	徐海岩
	服务器	王辰、罗福