系统分析与设计第六小组作业

Cecile_Corbel

已于 2024-03-30 01:10:58 修改

阅读量585

点赞数 12

文章标签：服务器数据库网络 git 墨刀需求分析

于 2024-03-28 11:13:55 首次发布

本文链接：https://blog.csdn.net/Cecile_Corbel/article/details/137104812

版权

系统分析与设计第六小组作业

第四周

hwk01:

按照如下模板，写下本小组开发产品的典型用户：

典型用户的模板：

名字（越自然越好）

年龄和收入（不同年龄和收入的用户有不同的需求）

代表的用户在市场上的比例和重要性比例大不等同于重要性高，如付费的用户比例较少，但是影响大，所以更重要

使用这个软件的典型场景

使用本产品的环境（在办公室/ 家里/ 沙发/ 床上/ 公共汽车/ 地铁……）

生活/ 工作情况

知识层次和能力（教育程度，对电脑、互联网的熟悉程度）

用户的动机、目的和困难（困难 = 需要解决的问题）

用户的偏好

典型用户：

名字: 张三
年龄22 收入<3k
市场占比70%，是主要的使用者
典型场景如，进入学校健身房前通过该软件查看当前健身房使用人数，进入健身房后通过该软件打卡确认会员身份
办公/健身房
学习与运动
大三学生
通过数字化管理平台代替传统管理方式提高健身房管理效率
便捷的应用，如支持移动端使用

hwk02:

按照如下模版找到本小组开发软件产品的最困难，最典型的场景；为了提高 10倍的“用户满意度和产品效率”，本小组应做出哪些改进措施？

•[处于典型场景下的客户]

•TA 在公司/家庭/学校/社区/…里面处于什么位置，负责什么?

•TA 目前用什么样的办法/工具

•[客户待完成的任务]

•任务的频繁程度

•任务的细节

•[ 客户动机 ]

•完成任务的动机是？完成之后是达到了什么状态

•[ 客户问题 ]

•最大的烦恼是什么？现在客户是怎么绕过这些问题的？

•对于 [ 待完成的任务 ]，如果你能改变一件事情，你想改变什么？

[处于典型场景下的客户] 客户：健身房员工位置：健身房前台负责：记录会员入场信息、管理健身房使用情况
[客户待完成的任务] 任务：记录会员入场信息频率：每天多次细节：手动记录会员姓名、会员卡号、入场时间
[客户动机] 动机：确保准确记录会员入场信息，维护健身房秩序达到状态：提高工作效率，提升服务质量
[客户问题] 烦恼：手动记录耗时且容易出错，效率低下绕过问题：尽量快速记录，尽量减少错误
如果能改变一件事情，客户想改变的是：希望能够自动记录会员入场信息，减少手动操作，提高工作效率和准确性。

为了提高10倍的用户满意度和产品效率，可以考虑以下改进措施：

引入自动识别技术，如人脸识别或RFID技术，实现会员入场信息自动记录。
开发移动应用，让员工可以随时随地记录会员信息，提高工作灵活性。
提供培训和技术支持，确保员工熟练掌握新系统，提高使用效率。
收集用户反馈，持续优化系统功能，提升用户体验和满意度。
定期检查系统运行情况，及时解决问题，确保产品效率和稳定性。

hwk03:**

用快速原型工具或笔和纸画出一个本小组开发软件产品的典型场景，描述典型用户如何解决问题

墨刀快速原型url：https://modao.cc/proto/VCyimS0js9lfrpAtfgXmKO/sharing?view_mode=read_only #健身房管理系统-分享

第五周

hwk01:

如果你的团队来了一个新队员，有一台全新的机器，你们是否有一个文档，只要设置了相应的权限，他就可以根据文档，从头开始搭建环境，并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试？（在这过程中，不需要和老队员做任何交流）

有的，我们团队中有远端仓库和本地仓库，仓库中有各个版本的项目工程，其中也包含readme文档用于快速部署启动项目

hwk02:

你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？

场景：程序员甲正在对几个文件进行修改，实现一个大的功能，这时候，程序员乙也要改其中一个文件，快速修复一个问题。怎么办？

一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？有几种设计，各有什么优缺点？

例如，签出文件后，此文件就加锁，别人无法签出；或者，所有人都可以自由签出文件

团队使用gitee作为远端仓库，使用git进行代码的版本控制，如果当前项目版本不是最新版本是提交不上去的，需要拉取最新修改的项目版本进行代码审查和合并后才能提交。
在软件开发中，对于一个代码文件被签出后的修改管理，有多种设计方式，每种方式都有其优缺点：
1. 文件加锁设计：签出文件后，该文件被加锁，其他团队成员无法签出该文件进行修改。
  - 优点：避免多人同时修改同一文件导致冲突和混乱，确保修改的一致性和完整性。
  - 缺点：可能会造成资源瓶颈，限制团队成员的并行工作能力，降低开发效率。
2. 并发修改设计：所有团队成员都可以自由签出文件进行修改，无需加锁。
  - 优点：提高团队成员的并行工作能力，加快开发速度，灵活性高。
  - 缺点：可能会导致文件冲突和合并困难，需要额外的合并工作，容易出现代码质量问题。
3. 基于权限的设计：根据团队成员的权限设置，部分人可以签出文件进行修改，其他人只能查看或审阅。
  - 优点：灵活控制团队成员的权限，保证核心代码的质量和安全性。
  - 缺点：可能需要额外的权限管理和配置，增加管理成本。
选择合适的设计取决于团队的具体情况和需求。通常情况下，文件加锁设计适合需要严格控制修改权限和避免冲突的场景；并发修改设计适合需要灵活性和快速开发的团队；基于权限的设计适合需要综合考虑权限管理和团队协作的情况。

hwk03:

如何看到这个文件和之前版本的差异？如何看到代码修改和工作项（work item），缺陷修复（bug fix) 的关系。

场景：程序员甲看到某个文件被修改了，他怎么看到这个文件在最近的修改究竟改了哪些地方？（例子）

场景：程序员甲看到某个文件在最新版本被改动了100 多行，那么和这100多行对应的其他修改在什么文件中呢？这个修改是为了解决哪些问题而作的呢？那些问题有工作项（work item，issue），或者bug 来跟踪么？

使用Git版本控制工具可以解决以上问题，方式如下：

查看文件和之前版本的差异：
程序员甲可以使用Git命令 git diff <file> 来查看指定文件的修改内容，也可以使用 git log -p <file> 查看文件的修改历史和具体变动。
查看代码修改和工作项（work item）、缺陷修复（bug fix）的关系：

程序员甲可以使用Git的版本控制功能来查看代码修改的历史，包括每次提交的详细信息和修改内容。
通过提交信息，可以了解每次修改是为了解决哪些问题或工作项。通常在提交信息中会包含关联的工作项编号或Bug编号，以便跟踪修改的目的。
使用Git的分支管理功能，可以清晰地查看不同分支上的修改内容，从而了解不同修改之间的关系。

举例：

如果程序员甲看到某个文件被修改，可以使用 git log -p <file> 查看该文件的修改历史和具体变动。
如果程序员甲发现某个文件在最新版本被改动了100多行，可以通过查看提交信息了解这些修改是为了解决哪些问题而作的，是否有关联的工作项或Bug。

通过Git的版本控制功能和提交信息，程序员可以清晰地了解代码修改的历史和目的，以及不同修改之间的关系，帮助团队成员更好地协作和跟踪工作进展。

hwk04：

如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候， 如何合并不同的修改（merge)? 你用了什么工具来帮助你？

我选择使用git:
当某个文件在你签出之后已经被别人修改并签入，而你也对同一文件做了修改并准备签入时，Git会进行自动合并（merge）操作来尝试将这两组修改整合到一起。合并过程中，可能会出现以下几种情况：

自动合并：如果你的修改和别人的修改在不同的地方，Git会尝试自动合并这两组修改，保留双方的修改并创建一个新的合并版本。
冲突解决：如果你的修改和别人的修改发生冲突（即两处修改在同一行或相邻行），Git会标记这些冲突并提示你手动解决。你需要手动编辑文件，选择保留哪一处修改或进行进一步调整。
合并提交：完成冲突解决后，你可以继续签入这个文件，Git会将你的修改和冲突解决的结果一起提交为一个新的合并提交。

在合并过程中，Git会尽可能智能地处理不同修改之间的关系，但在出现冲突时，需要开发人员手动介入解决。通过合并操作，Git可以确保团队成员之间的协作和代码修改得以有效整合，避免冲突和数据丢失。

hwk05：

你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？

场景：程序员甲要签入 20 个文件，他一个一个地签入，在签入完5 个 .h 文件之后，他发现一些 .cpp 文件和最新的版本有冲突，他正在花时间琢磨如何合并… 这时候，程序员乙从客户端同步了所有最新代码，开始编译，但是编译不成功 - 因为有不同步的 .h 文件和 .cpp 文件！这时候，别的程序员也来抱怨同样的问题，甲应该怎么办？

为了保证多个文件的修改具有原子性，即要么全部签入成功，要么全部签入不成功，可以采取以下措施：

使用提交钩子（pre-commit hook）：在Git中可以设置提交钩子，用于在提交前执行一些检查或操作。可以编写一个提交钩子，检查所有文件的状态，确保所有相关文件都已经准备好签入，避免部分文件签入导致不一致性。
使用分支策略：可以在本地创建一个临时分支，将所有修改的文件都提交到这个分支上，然后在确认所有文件都修改完毕后，再将这个分支合并到主分支，保证修改的原子性。

在上述场景中，程序员甲可以采取以下措施应对问题：

首先，程序员甲应该停止继续签入其他文件，以避免进一步的不一致性。
程序员甲应该尽快解决冲突，合并 .cpp 文件和最新版本的冲突，确保代码整体的一致性。
一旦冲突解决完毕，程序员甲应该尽快提交所有修改的文件，确保所有相关文件同时签入成功。
程序员甲应该及时通知团队其他成员发生了冲突，并说明解决方案，以便其他成员也可以及时处理不一致性问题。

通过及时解决冲突、有效沟通和合作，可以避免不同步的文件导致的编译失败和不一致性问题，确保团队的协作和代码质量。

hwk06:

你的PC 上有关于三个功能的修改，但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改。

暂存本地修改： 使用Git的 git stash 命令将当前的修改暂存起来，这样可以将未完成的工作放一边，让工作区变得干净。
创建新分支： 使用 git checkout -b new_bug_fix 命令创建一个新的分支用于修复新bug，确保在一个独立的环境中进行修改，不影响未完成的工作。
修复新bug： 在新创建的分支上进行新bug的修复工作，确保专注于解决当前问题，不受其他未完成修改的影响。
测试和验证： 在修复完新bug后，进行测试验证确保修复有效，并且没有引入其他问题。
签入修改： 使用 git add . 和 git commit -m “Fix bug” 命令将修改提交到新创建的分支。
合并分支： 如果新bug修复通过测试，可以将新bug修复的分支合并回主分支，使用 git merge new_bug_fix 命令。

通过以上步骤，可以有效地将未完成的工作暂存起来，专注于解决新bug，并确保在干净的环境中进行修改和签入，最终保证新bug修复的成功并整洁地管理未完成的工作。

hwk07:

规范操作和自动化

你的团队规定开发者签入的时候要做这些事情：

运行单元测试，相关的代码质量测试。

代码复审（要有别的员工的名字）

和这次签入相关的issue 编号，任务/task，缺陷/bug 编号，等等，以备查询。

请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么？（高级功能，代码提交之后，相关bug 的状态会改动为 “fixed”，并且有链接指向这次签入。），举个例子。

为了让开发者方便地一次性填入所有信息然后提交代码，团队可以使用Git的高级功能，如Git Hooks和自定义脚本来实现。以下是一个示例流程：

设置提交模板（Commit Template）：
团队可以创建一个提交模板文件，包含需要填写的信息，如单元测试运行结果、代码复审人员、相关issue编号等。这个模板文件可以放在版本库中，并通过Git配置指定为提交模板。
自定义提交脚本：
团队可以编写一个自定义的提交脚本，用于在提交代码时触发，该脚本可以根据提交模板中的要求，引导开发者填写相关信息。
自动化处理相关bug状态和链接：
在提交脚本中，可以添加逻辑来自动更新相关bug的状态为“fixed”，并生成链接指向这次签入。这可以通过调用Bug跟踪系统的API来实现。

举例：
假设开发者要提交一个修复Bug的代码，在提交代码前，运行自定义的提交脚本。该脚本会弹出一个填写提交信息的界面，包括单元测试结果、代码复审人员、相关Bug编号等。开发者填写完整信息后，提交代码。

提交脚本会在提交代码后自动调用Bug跟踪系统的API，将相关Bug状态更新为“fixed”，并在Bug系统中生成链接指向这次签入。这样就实现了一次性填入所有信息并提交代码，同时自动处理相关Bug状态和链接的功能。这种流程可以提高团队的开发效率和代码管理规范性

hwk08:

如何给你的源代码建立分支？

场景：你们需要做一个演示，所以在演示版本的分支中对各处的代码做了一个临时的修改，同时，主要的分支还保持原来的计划开发。你们怎么做到的？在演示之后，演示版本的有些修改应该合并到主分支中，有些则不用，你们是怎么做到的？

场景：你们的软件发布了，有很多用户，一天，一个用户报告了一个问题，但是他们是用某个老版本，而且没有条件更新到最新版本。这时候，你如何在本地构建一个老版本的软件，并试图重现那个问题？

建立源代码分支：

使用Git命令 git checkout -b demo_branch 在本地创建一个名为demo_branch的新分支，用于演示版本的临时修改。
在demo_branch分支上对需要修改的代码进行相应调整，保持主分支的开发进度不受影响。

合并演示版本的修改到主分支：

在演示之后，使用 git checkout main_branch 切换回主分支。
使用 git merge demo_branch 将演示版本的修改合并到主分支中。
对于不需要合并的修改，可以使用 git cherry-pick 选择性地将某次提交合并到主分支。

构建老版本软件并重现问题：

使用Git的版本控制功能，通过 git log 查看历史提交记录，找到对应老版本的commit ID。
使用 git checkout 切换到指定老版本的代码状态。
根据老版本的代码状态，在本地构建软件，并尝试重现用户报告的问题。

通过以上步骤，团队可以在Git中轻松创建分支、管理临时修改、合并修改到主分支，并利用版本控制系统的功能快速构建老版本软件，方便重现和解决用户报告的问题。

hwk09:

一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的（解决了哪个任务，或者哪个bug）？

场景：一个重要的软件历经几年，几个团队的开发和维护，忽然出现在某个条件下崩溃的事故，程序员甲经过各种debug手段，发现问题是在某一个文件中有一行代码似乎显然出了问题，但是这个模块被很多其他模块调用，这行代码是什么时候，为了什么目的，经过谁签入的呢？如果贸然修改，会不会导致其他问题呢？怎么办？

查看文件历史记录：
在Git中，可以使用 git blame 命令来查看指定文件的每一行是谁在什么时候签入的。这会显示每一行代码的最后一次修改是由谁提交的，并且显示提交的哈希值。
查看提交信息：
通过查看提交信息，可以了解每次修改的目的是为了解决哪个任务或者哪个bug。可以使用 git show 命令查看具体的提交信息，包括提交者、提交时间、修改内容以及关联的任务或bug编号。
评估修改影响：
在确定了问题出现的具体代码行和相关的提交信息后，可以评估修改的影响范围。可以查看该行代码被其他模块调用的情况，以及修改可能导致的其他问题。
制定修改方案：
根据评估的结果，制定修改方案。可以考虑在一个独立的分支上进行修改，进行测试验证后再合并到主分支，以确保修改的安全性和有效性。
通过以上步骤，程序员甲可以准确了解问题代码行的历史记录和修改目的，避免贸然修改导致其他问题，保证修改的准确性和稳定性。同时，可以通过版本控制系统追溯代码修改的历史，帮助解决软件出现的问题并确保代码质量。

hwk10:

如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？

代码每天都在变，有时质量变好，有时变差，我们需要一个 Last Known Good （最后稳定的好版本）版本，这样新员工就可以同步这个版本，我们如果需要发布，也是从这个版本开始。那么如何标记这个 Last Known Good 版本呢？

要给一个系统的所有源文件打上标签，可以使用版本控制系统（如Git）的标签（tag）功能。以下是如何打上标签并标记一个"Last Known Good"版本的步骤：

给系统所有源文件打上标签：

在Git中，可以使用 git tag <tag_name> 命令为当前版本打上一个标签，例如 git tag v1.0 。
如果需要为特定的提交打上标签，可以使用 git tag <tag_name> <commit_id> 命令，指定特定的提交ID。

标记"Last Known Good"版本：

确定系统中一个稳定且质量良好的版本，可以是最新发布版本或经过严格测试的版本。
使用 git tag 命令为这个版本打上一个特殊标签，例如 git tag Last_Known_Good .
可以通过 git tag -l 命令查看所有标签，确保"Last Known Good"版本的标签已经成功打上。

发布和同步"Last Known Good"版本：

新员工或发布流程可以通过 git checkout Last_Known_Good 命令来同步"Last Known Good"版本的代码。
如果需要发布版本，可以基于"Last Known Good"版本进行进一步的开发和测试，确保发布版本的稳定性和质量。

通过标记"Last Known Good"版本，团队可以方便地定位和同步稳定的版本，新员工也可以快速获取到一个可靠的起点进行开发工作。这种标记方式有助于代码管理和发布流程的规范化和稳定性。

hwk11:

你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？
在签入之前，程序员能否自动在自己的机器上运行自动测试，以保证本地修改不会影响整个软件的质量？在程序员提交签入之后，服务器上是否有自动测试程序，完成编译，测试，如果成功，就签入，否则，就取消签入？
团队是否配置了服务器，它自动同步所有文件，自动构建，自动运行相关的单元测试，碰到错误能自动发邮件给团队

项目源码和测试代码是在同一个项目模块下，但是并不在一个目录，如源码在src/main下，测试代码在src/test下。由于项目使用spring-cloud框架，而spring提供了依赖注入，我们可以将源码的注入到测试代码中，这样我们在修改源码方法时，测试方法也会更新。我们团队不仅能部署单体服务，也能使用docker快速部署分布式的微服务。
可以的。不同环境下的修改互不影响，如测试环境下的修改并不影响生产环境。
可以使用maven预编译和测试，git在提交至团队仓库时也会进行代码检查，如果出现警告和错误会提醒程序员是否确认提交
没有。

hwk12:

就像一个厨师要分析各种厨房用具，挑选适合自己的工具组合，一个软件团队也要挑选适合自己的源代码管理和其他配套工具，请选择至少三种，比较各自的优点缺点，成本：

github

https://gitee.com/education

coding.net

code.csdn.net

gitcafe.com

www.visualstudio.com

code.taobao.org

Visual Studio Team Foundation Server

gitblit，在Windows系统下构建 git 服务，带网页端管理…

Visual Source Safe (VSS)

本团队自行搭建的系统

GitHub:
- 优点：流行度高，社区活跃，易于使用，具有强大的协作功能和集成工具。
- 缺点：对私有仓库收费，高级功能需要付费订阅。
- 成本：免费版提供公共仓库，私有仓库需要付费订阅。
Coding.net:
- 优点：支持私有仓库免费，提供持续集成等功能。
- 缺点：在国内外知名度较低，可能影响团队合作。
- 成本：提供免费基本功能，高级功能需要付费。
Visual Studio Team Foundation Server:
- 优点：与Visual Studio集成良好，提供全面的应用生命周期管理功能。
- 缺点：部署和维护较复杂，适合大型团队。
- 成本：需要购买许可证和进行定期更新。

hwk13:

每个小组说明自己团队的开发环境和流程有什么需要改进的地方？

改进方向：

沟通与协作工具：考虑尝试使用团队协作工具，如Slack、Microsoft Teams或Trello等，以便更好地沟通和协作。
持续集成与持续交付：引入持续集成/持续交付（CI/CD）工具，如Jenkins或GitLab CI等，以自动化构建、测试和部署流程，提高交付效率。
代码质量管理：考虑引入代码质量管理工具，如SonarQube，以帮助团队检查代码质量并改进代码规范。
版本控制与代码审查：加强团队对代码版本控制的使用，鼓励代码审查实践，以提高代码质量和团队协作。
自动化测试：推动更多的自动化测试，包括单元测试、集成测试和端到端测试，以提高代码质量和减少错误。
敏捷开发：考虑采用敏捷开发方法，如Scrum或Kanban，以更灵活、迭代的方式开展项目，更快地响应需求变化。
技术选型与架构设计：在项目初期更深入地评估技术选型和架构设计，确保选择最适合项目需求的技术和架构。
持续学习与知识分享：鼓励团队成员持续学习新技术和分享经验，以提升团队整体水平和创新能力。

通过适时地改进开发环境和流程，提高项目交付质量和效率。

hwk14:

•手机英语背单词软件，用户可以选择单词本的类型（四级，六级，GRE，等），每天背单词的进度。

•可以和好友分享自己背单词的进度。还可以挑战好友，挑选20个单词，送给好友，让好友选择正确的解释，并把成绩自动分享回来。

•假设有微博/微信/email 可以确定用户的身份

•假设有服务器可以返回【中文 – 英语单词】的对应关系

用下面的工具进一步分析这些需求，做出草图

•思维导图

•ER图

•Use Case

•Data Flow Diagram

•UML