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

需求规格说明书不足与提升部分：

引言：原需求报告中的引言虽然强调了数字化和信息化时代的重要性，但在描述问题和解决方案时较为一般化，没有具体列举问题和解决方案的关键特点。在改进后的需求报告引言着重指出了传统公文处理方式的问题，如效率低下、资源浪费，以及现代公文工作的需求，如高效、安全。这种更具体的描述有助于读者更好地理解问题和解决方案的紧迫性。

用户场景：原需求报告中的用户场景部分列出了用户角色和需求，但在描述问题和解决方案时较为简略，没有详细说明主要问题或挑战，以及解决方案的具体行动。改进后的需求报告用户场景部分更详细地列举了问题和挑战，如纸质传输的问题和不一致的审批流程，以及解决方案的具体行动，如电子化传输和自定义工作流程。这种更详细的描述使读者更容易理解问题和解决方案的实质。

功能描述：原需求报告中的功能描述列举了系统功能，但表述相对简洁，缺少详细的功能描述和用词更加准确的要求。改进后的需求报告功能描述部分提供了更详尽的功能描述，包括用户管理、授权账密登录、公文在线编辑、公文上传等，每个功能都有更详细的说明。这种更详细的描述和用词更加准确的要求有助于开发团队更好地理解系统需求，并有利于开发过程中的沟通和验证。

改进后的说明书在描述上更加详细，更加细致的提出了存在的问题和相应的处理方案，将需求具体化，细致化。使读者的阅读更加一目了然。

代码规范和编码原则：

缩进： 使用4个空格作为首行缩进的标准。确保在整个项目中保持一致的缩进风格，以提高代码的一致性和可读性。

命名规范：使用有意义的变量名、函数名和常量名，以便清楚地表达其用途。对于常量，使用全大写字母，并使用下划线分隔单词（例如，MAX_VALUE）。采用一种一致的命名约定，例如驼峰式命名法（functionName）或下划线命名法（function_name），并在整个项目中保持一致。

注释：使用注释来解释代码的目的、特殊算法、复杂逻辑或关键决策。注释应该清晰、简洁，使用自然语言，避免冗长或无用的注释。在需要时添加函数级别的文档注释，描述函数的参数、返回值和行为。

函数长度：函数应该保持简洁和紧凑，通常不超过一屏的大小。如果函数太长，考虑拆分它们为更小的功能单元，以提高代码的模块化。

代码块的大括号： 始终使用大括号明确定义代码块的范围，即使它只包含一个语句。这有助于避免潜在的错误和提高代码的可读性。

空格的使用：在二元操作符（如赋值、加法、逻辑运算符等）周围使用空格，使代码更易读，例如，x = y + z。避免在括号内部使用不必要的空格，例如，if (condition)。

头文件保护宏： 使用预处理器指令确保头文件不会被重复包含，如下所示：

#ifndef HEADER_FILE_H

#define HEADER_FILE_H

#endif // HEADER_FILE_H

确保宏名是唯一的，以避免命名冲突。

错误处理：在可能失败的操作后，检查返回值或错误代码，并编写适当的错误处理代码。这可以包括错误消息记录、资源清理和程序退出。

代码风格一致性： 通过团队内部的协商确保代码风格的一致性。可以采用自定义的代码风格指南，也可以参考广泛接受的C语言编码标准，如Google C++ Style Guide或Linux Kernel Coding Style。

版本控制：使用版本控制系统（如Git）来管理项目，进行代码追踪、协作开发和版本管理。确保每个提交都有明确的提交消息，以便更容易理解和跟踪代码更改。

而确定代码规范和编码原则的原因则如下：我们团队在经过讨论之后，认识到：做一个程序，不是一个人可以完成的，团队里每一个人负责什么？需求设计谁写？谁测试？这些都涉及到团队里的每一个人，所以团队中如何分工，如何把各自负责的部分合成一个整体项目，这就考验了整个团队的团结分工性。而在读完第四章之后，我发现了在平常的编程里我的错误，在我的程序中，我的注释大多都是在变量名的后面，标注了该变量是什么。突然觉得这样的做法很蠢，一个变量，其实要是命名做的好，那么让人一目了然，就少了一些没必要的注释。团队中每个人也都发现了自己在编译中的坏习惯，这对接下来的合作无疑是致命的，所以我们统一了代码编写风格，确保每人都会写注释。同时确立了新的代码规范和编码原则。

er图和数据库设计：

 

确定团队分工：

张钰权：实现公文发送和公文接受功能

周绍坤：实现用户认证和用户管理功能

张爽：实现账户权限管理

王熠名：实现公文编辑功能

董子瑄：实现日志管理功能

组员这次任务中的分工 

张钰权：修改完善规格说明书，制作er图

周绍坤：确定代码规范和编码原则

张爽：确定功能，绘制wbs图

王熠名：协助确定功能，绘制wbs图

董子瑄：撰写博客，汇总团队结果