团队作业（三）
目录
任务清单
- 修改需求规格说明书（修改内容要体现在markdow文件中）；
- 讨论确定代码规范和编码原则，说明理由（发布随笔）
- 完成数据库设计，随笔提供ER图
- 进行后端架构设计，需要与上周的说明书中界面原型设计相对应
- 确定团队分工（1.alpha版本需要实现的功能；2在团队管理软件中确定子功能的工作量；3列出当前团队的TODOList和燃尽图）
一、修改需求规格说明书（修改内容要体现在markdow文件中）
- 仔细审查需求规格说明书：首先，仔细阅读和理解原始需求规格说明书。确保对项目的整体要求和目标有清晰的理解。
- 识别需要修改的部分：检查现有的需求规格说明书，并识别需要修改的部分。这可能包括添加新的需求、删除不再需要的需求或调整现有需求的描述。
- 收集反馈和建议：与项目干系人和利益相关者交流，了解他们对需求规格说明书的反馈和建议。这可以通过会议、访谈、问卷调查等方式进行。
- 更新需求规格说明书：根据收集的反馈和建议，对需求规格说明书进行更新。确保修改后的规格说明书能够清晰地描述项目的需求和目标。
- 审查和验证：邀请项目干系人和利益相关者对修改后的需求规格说明书进行审查和验证。确保他们对修改后的规格说明书有清晰的理解，并确认修改后的规格说明书符合他们的期望。
- 文档版本控制：确保对修改后的需求规格说明书进行版本控制，以便追踪和管理文档的变更。
- 与项目团队共享：及时将修改后的需求规格说明书与项目团队共享，并确保每个团队成员都对修改后的规格说明书有清晰的认识。
- 持续更新：需求规格说明书是一个动态的文档，随着项目的推进和变化，可能需要进一步修改和更新。因此，持续更新和维护需求规格说明书是很重要的。
链接: 需求规格说明书
二、讨论确定代码规范和编码原则
代码风格规范：
- 缩进：使用4个空格，避免直接使用Tab键，以提高可读性。
- 行宽：限制行宽不超过100字符，确保代码在各种显示设备上都能清晰可见。
- 括号：在复杂的条件表达式中，使用括号清晰地表示逻辑优先级。
- 断行与空白的{}行：每个开括号和闭括号独占一行，提高代码结构的清晰度。
- 分行：不将多个不同操作放在同一行，以保持代码简洁。
- 命名：使用匈牙利命名法，下划线用来分隔变量名字中的作用域标注的变量的语义。
- 大小写：类型、类、函数名使用 Pascal 形式（每个单词首字母大写），变量使用 Camel 形式（第一个单词小写，后续单词首字母大写）。
- 注释：用于解释程序的功能和为什么这样做，复杂注释放在函数头，需要不断更新。
代码设计规范：
- 函数：每个函数只做一件事，且要做好这一件事。
- goto：尽量减少使用goto，但可使用它实现函数的单一出口，有助于清晰的程序逻辑表达。
- 错误处理：在Debug版本中，验证所有参数的正确性，尤其是外部传递的参数。
- 运算符：避免自定义操作符，运算符不应做标准语义以外的动作。运算符的实现必须非常高效，如有复杂操作，应定义一个独立的函数。
编码原则：
- 单一职责原则：每个类或接口应该只负责一项职责，避免类过于庞大和复杂。
- 里氏替换原则：子类应能替换基类，确保子类完美替代基类，不破坏继承体系。
- 依赖倒置原则：高层模块不应依赖低层模块，而是依赖抽象。抽象不应依赖细节，细节应该依赖抽象。
- 接口隔离原则：设计接口时应精简、单一，避免污染接口。每个类应该依赖于其需要的接口，不应强制实现不必要的方法。
- 迪米特法则：降低类之间的耦合，使每个类尽量减少对其他类的了解，减少不必要的依赖。
- 开闭原则：对扩展开放，对修改关闭，允许通过扩展来实现变化，而不是修改已有代码来适应变化。
代码复审：
- 形式：自我复审、同伴复审、团队复审。
- 目的：找出代码错误、发现逻辑错误、算法错误、潜在错误和回归性错误、发现改进的地方、传授经验。
- 复审后整理记录，更正明显的错误，记录无法迅速更正的错误，建立“我常犯的错误”表，以便以后自我复审的第一步。
三、完成数据库设计
四、进行后端架构设计
五、确定团队分工
-
alpha版本需要实现的功能
![image]()
-
给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图
- 分工认领（按照目前的功能实现来分配，如果分配不均就进一步调整）：
1.实现身份认证、权限管理功能
2 实现公文发送功能
3.实现公文签收功能
4.实现用户管理、日志管理、文件管理功能
5.实现公文加密解密功能 - 燃尽图（待补充）
浙公网安备 33010602011771号