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

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

1、修改完善上周提交的需求规格说明书，并在博客中描述：上次的《需求规格说明书》初稿有哪些不足？修改需同时体现在Github的MarkDown文件与PDF中。（提示：功能考虑不全或需求文档描述缺少的地方。）

明确了每一个小词条所归属的大词条，防止出现勿看的情况；

增加了一个分割线在大词条之间，在小词条下的小点也同样进行了标注，使阅读更加简便；明确了用户之间的区别，增加了管理员的责任。

2、讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布在随笔上，并说说你们这么选择的理由。

代码风格规范：

1. 代码命名要具有描述性和清晰性，避免使用单字母变量名或缩写。
2. 使用驼峰命名法（camelCase）或下划线命名法（snake_case）命名变量、函数和类，保持一致性。
3. 避免使用魔术数（magic number），使用有意义的常量或枚举来代替。
4. 每行代码的行宽限定为80-100个字符，以保持整体的可读性。
5. 代码缩进使用四个空格而不是制表符，确保代码在不同编辑器和环境下的一致性。

6. 添加适当的空行和注释来分隔代码块，提高可读性。

7. 使用合适的代码注释，解释代码的目的、功能以及关键步骤。

8. 函数的长度应合理控制，避免过于庞大复杂的函数，保持单一职责原则。

9. 使用简洁的逻辑结构，避免嵌套过深的条件语句和循环。

10. 使用异常处理机制来处理可能出现的错误，确保代码的健壮性和可维护性。

代码设计规范

1. 函数应具备单一职责，每个函数只做一件事情，并且做好。
2. 避免使用全局变量，尽量使用局部变量来限制变量的作用范围。
3. 在设计类和函数时，要尽量遵循开放-封闭原则，即对扩展开放，对修改封闭。
4. 使用合适的设计模式和数据结构来解决具体的问题，提高代码的灵活性和可复用性。
5. 使用面向接口编程，降低代码的耦合度，增强代码的可扩展性。
6. 避免使用过多的全局状态，尽量使用参数传递和局部变量来进行数据传递。
7. 在处理异常时，遵循适当的异常处理策略，避免捕获所有异常或不处理异常的情况。
8. 在代码中添加适当的断言，以确保输入的合法性和代码的正确性。
9. 使用适当的数据结构和算法来提高代码的执行效率和性能。
10. 尽量避免使用硬编码的常量，将常量定义为合适的变量或配置项，方便修改和维护。
11. 在设计数据库结构时，遵循规范化原则，尽量避免冗余和重复数据。
12. 在多人协作开发时，使用版本控制系统来管理代码的修改和历史记录，确保团队的代码一致性。

代码复审

1. 检查代码是否符合编码规范和最佳实践，包括命名规范、缩进、注释等。
2. 查找潜在的错误和逻辑问题，例如边界条件、空指针引用等。
3. 检查代码中是否存在重复的逻辑或冗余的代码，尽量简化和优化代码。
4. 针对关键算法或复杂逻辑，逐步理解和验证代码的正确性，可使用调试、日志等工具辅助。
5. 检查代码是否能够满足需求，包括功能是否正确、是否缺少边界检查或异常处理等。
6. 通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。

 

 

4、进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。

 

5、确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：

 

 

 

1. 描述组员在上述任务中的分工和工作量比例。

许博文	主编写者，ER图	1/3
周翔	通过Powerdesigner完成团队项目的数据库设计，WBS图	1/3
旦增赤列	后端架构设计与需求规格说明书中的界面原型设计相对应	1/3