一、对上次需求规格说明书的修改与完善
- 1）加设了一个控制端与服务器，让之后的编程更具体可观
- 2）简化了流程，把一些注册表权限表等功能需求放在了数据库里，让整个设计图更加客观。
- 3）在需求描述中给出的权限表与注册表中并没有给出一个对具体用户反馈方式。
- 4）在第二次作业的需求描述中对所实现功能划分太细，导致流程显示有点乱。
二、代码规范和编码原则
(一)、代码规范
每个人对于什么是“好”的代码规范未必认同，这是我们很有必要给出一个基本准线————什么是好的代码规范和设计规范。
代码规范可以分成两个部分：
- 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）数据结构中有没有用不到的元素？
三、团队项目的数据库设计
四、项目的后端构架设计
用户角度功能构架
- 用户管理：包括注册、登录等方面
- 文件处理：包括收发件等方面
五、确定团队分工
| 任务 | 完成成员 | 协作成员 | 工作量 |
|---|---|---|---|
| 网页界面 | 唐嘉浩 | 尹子扬 | 1/3 |
| 用户主页界面 | 李积渊 | 尹子扬、杨坤 | 1/3 |
| 系统管理模块 | 白皓宇 | 杨坤 | 1/3 |
六、分工和工作量比例
| 任务 | 完成成员 | 协作成员 | 工作量 |
|---|---|---|---|
| 需求规格说明书的修改 | 尹子扬 | 1/5 | |
| 代码规范和编码原则 | 尹子扬 | 1/5 | |
| 团队项目的数据库设计 | 白皓宇 | 1/5 | |
| 项目的后端构架设计 | 李积渊 | 1/5 | |
| 确定团队分工 | 杨坤 白皓宇 | 唐嘉浩、尹子扬、李积渊 | 1/5 |