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

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

---

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

• 上次制定的需求规格说明书中指定的部分内容实现起来较为困难，经过修改完善，我们删除了部分模块。
• 明确了用户之间的区别，增加了管理员的责任。
• 具体见规格需求说明书

二、讨论制定团队的编码规范

1.编码规范：编码规范的目的是为了提高代码的可读性、可靠性和可维护性，让开发人员更容易阅读代码、维护代码，从而最大程度提高程序开发效率。
2.编码总原则：简明、易读、无二义性。

具体包括以下几点：

• 文件目录组织与命名：良好的目录命名有利于项目维护与迭代

  • src：指源代码，用于存放源代码，还可建立client和server目录分别存放客户端源代码和服务端源代码。
  • include：存放.h文件，即头文件
  • bin：存放项目调试之后的可运行文件
  • libs：存放动态库和静态库
  • db：database的简写，数据库
  • conf：config的简写，配置文件
  • logs：日志文件
  • Readme：阅读指南文件，包括如何使用这个程序等
  • makefile：描述了整个工程的编译、链接等功能，“自动化”
  • 延伸：
    images：图片资源
    media：媒体资源
    audio：音频资源
    video：视频资源

• 代码缩进：团队开发一定要统一代码缩进方式

  • 推荐使用四个空格进行缩进。由于不同的程序或系统环境显示TAB 符的长度不相同，建议避免TAB符与空格符缩进代码。推荐使用空格符缩颈，空格符在所有程序与环境长度一致，具有良好的兼容性。

• 命名风格：注意代码语义化，助于理解，避免过简或过繁

  • 常见命名风格：
    • 驼峰命名法：首字母小写，后续每个单词首字母大写，如myVariable、calculateSum。
    • 帕斯卡命名法：每个单词的首字母都大写，如MyClass。
    • 下划线命名法：单词之间用下划线分割，全小写。如my_variable。
    • 全大写命名法：单词之间用下划线分割，全大写。如MY_CONSTANT。

    建议在命名函数、变量使用下划线命名法，对于常量的命名使用全大写命名法。此外，代码命名还应具有描述性，能够清晰地表示变量或函数的用途和含义；命名应尽量简洁，避免冗长的名称，但也不能过于简单而失去含义；避免使用缩写，除非是广为人知的缩写，否则应尽量避免使用缩写；不要使用编程语言中的保留字作为标识符，以免引起冲突。

• 程序结构设计风格

  • 建议使用主程序 - 子程序风格。主程序-子程序风格是结构化程序设计的一种典型风格，从功能的观点设计系统，通过逐步分解和细化，形成整个系统的体系结构。主程序负责控制程序的流程和逻辑，而子程序负责执行具体的功能。主程序调用子程序来完成特定的任务，子程序返回结果给主程序，主程序再根据结果进行下一步的操作。

• 注释规范

  • 注释应该用清晰明了的语言，简洁地描述代码的功能、目的和逻辑。避免使用模糊或不明确的语句，确保注释能够准确地表达代码的意图。
  • 当代码发生变动时，注释也应该及时更新以保持与代码的一致性。
    注释应该着重解释代码的意图和思路，而不是简单地重复代码的内容。通过注释，其他开发人员可以更好地理解代码的设计思想和实现逻辑。

三、使用Powerdesigner绘制ER图

四、进行项目的后端架构设计。

五确定团队分工

• 请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：
• 利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。
• 在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
• 给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。
  
  

六、组员分工

姓名	工作
谷丰宇	修改完善上周提交的需求规格说明书，并在博客中描述，并归纳撰写博客
陈夏林	讨论制定团队的编码规范
熊悠越	通过Powerdesigner完成团队项目的数据库设计
罗杰逊	进行项目的后端架构设计
董准	确定团队分工