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

一、任务目录

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

2.确定团队的编码规范

3.使用Powerdesigner绘制ER图

4.进行项目的后端架构设计

4.绘制团队wbs图

5.任务分配，确定团队分工

6.资料收集整合，博客撰写

二、问题解决

（一）修改完善需求规格说明书

• 项目背景：做了进一步修改，查阅了现有的已经投入使用的电子公文系统，例如国企单位用OA系统搭建电子化公文管理平台、蓝凌、泛微等等平台，研究现在背景下我们要如取其精华、去其糟粕，并且我们细致了解了一篇公文从起草到撰写到审核到发送接受的完整过程，更加清晰了如何实现此系统的功能分析

• 用户场景：我们将普通用户、管理员的功能重新进行了规范，制定了新的类图，我们原来的想法是有一个针对所有公文的管理员来管理所有公文的日志情况，但后来我们仔细研讨后，发现这是不可行的，尤其站在用人单位中，不可能有这样一个可以看到所有公文内容和日志的人，这样的话机密性就无法保证。所以我们修改后，谁上传、发送文件，谁就是该文件的管理员，管理员可以查看这个文件的日志内容，可以决定文件的权限

• 界面原型：根据我们对用户不同功能的新想法，修改了界面原型，分为公文检索、公文上传、公文接收、个人中心四个部分。可以实现其对应的功能，用户发送和接受的所有公文形成用户自己的数据库，用户可以在公文检索功能中快速检索自己想要查看的公文。公文上传可以看到该公文是否通过审核，是否成功发送，追踪状态。公文接收分为已读和未读，帮助用户快速找到未读的文件
  

（二）讨论制定团队的代码规范和编码原则

代码规范

团队合作开发项目的代码规范对于保持代码的一致性和可读性非常重要。常见的代码规范的方法：

1. 代码规范：

   • 类名、方法名和变量名应该使用驼峰命名法。例如：myVariable, myMethod。
   • 常量应该使用大写字母和下划线分割。例如：MY_CONSTANT。
   • 使用统一的缩进风格，推荐使用四个空格或者一个制表符来缩进。

2. 注释：

   • 使用注释来解释代码的功能和意图，尤其是复杂的算法或逻辑段落。
   • 针对方法和函数，可以使用文档注释（如Java的Javadoc）来描述参数、返回值和方法用途等信息。

3. 文件结构：

   • 根据项目的架构和组织结构，将相关的文件放置在合适的目录中。
   • 使用合理的包结构来组织代码。

4. 格式化：

   • 使用一致的代码格式，例如在运算符周围添加空格，使用一致的大括号风格等。

5. 异常处理：

   • 使用适当的异常处理机制来处理潜在的错误情况。捕获异常时，应提供清晰的错误消息和适当的处理方法。

6. 版本控制：

   • 使用版本控制工具（如Gitee或Git）来管理代码的变更，确保团队成员可以安全地进行合作和版本控制。
   • 遵循合适的分支管理策略，例如使用主分支进行稳定版本的发布，使用开发分支进行日常开发等。

7. 单元测试：

   • 编写适当的单元测试用例来验证代码的正确性。
   • 在持续集成环境中自动执行这些测试用例，以确保代码的质量。

8. 代码审查：

   • 进行团队成员之间的代码审查，以确保代码的质量和一致性。

设计规范和原则

团队合作的代码设计规范和原则可以帮助确保代码的可维护性、可扩展性和可重用性。

1. SOLID 原则：

   • 单一职责原则 (Single Responsibility Principle)：一个类或模块应该有且只有一个责任。
   • 开闭原则 (Open-Closed Principle)：软件实体（类、模块、函数等）应该对扩展是开放的，对修改是封闭的。
   • 里氏替换原则 (Liskov Substitution Principle)：子类型必须能够替换掉它们的父类型。
   • 接口隔离原则 (Interface Segregation Principle)：不应该强迫客户依赖于它们不使用的接口。
   • 依赖倒置原则 (Dependency Inversion Principle)：高层模块不应该依赖于底层模块，它们都应该依赖于抽象。

2. 模块化和封装：

   • 将代码划分为独立的模块，每个模块尽可能独立、可重用和可测试。
   • 使用适当的访问修饰符（如private、protected和public）来保护模块内的数据和方法。
   • 避免过度暴露内部实现细节，提供清晰的外部接口。

3. 高内聚低耦合：

   • 高内聚 (High Cohesion)：模块内的元素应该紧密相关，实现单一的职责。
   • 低耦合 (Low Coupling)：模块之间的依赖应该尽可能松散，模块间的修改不应该互相影响。

4. 设计模式：

   • 使用常见的设计模式（如工厂模式、单例模式、观察者模式等）来解决常见的设计问题，并提高代码的可读性和可维护性。

5. 设计原则和约束条件：

   • 遵循一致性的命名和命名约定，提高代码的可读性。
   • 避免过度工程化，保持简洁性和实用性。
   • 考虑代码的性能和安全性，进行必要的优化和防御性编程。

6. 文档和注释：

   • 提供清晰的代码文档和注释，解释实现细节和设计决策，以便团队成员可以理解和维护代码。

代码复审

1. 形式：自我复审、同伴复审、团队复审
2. 整理记录：
   • 更正明显错误
   • 记录下现阶段无法修改的错误
   • 把所有的错误记录下来，形成类似“错题本”的记录表，防止以后再次犯同样的错误

（三）绘制ER图

（四）项目后端架构设计

（五）绘制团队WBS图，确定分工

WBS图

确定分工

燃尽图

三、组员分工及工作占比

组员学号	姓名	工作内容	工作量比例
20211301	郑润芃	修改完善需求规格说明书	20%
20211306	丁文博	确定团队分工	20%
20211316	郭佳昊	后端架构设计、撰写博客	20%
20211325	高进涛	绘制WBS图	20%
20211329	史雨洁	绘制ER图	20%