[小组作业]学生信息管理系统（第四、五周）-CSDN博客

作业1

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

典型用户的模板：

1. 名字（越自然越好）

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

3. 代表的用户在市场上的比例和重要性

比例大不等同于重要性高，如付费的用户比例较少，但是影响大，所以更重要

4. 使用这个软件的典型场景

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

6. 生活/ 工作情况

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

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

9. 用户的偏好

学生用户

1. 用户名字：王虎

2. 年龄和收入：22岁，无固定收入（学生）

3. 代表的用户在市场上的比例和重要性：王虎在我们项目中主要代表了大量的大学生用户，他们在当前项目市场上占据重要比例，是主要用户人具有代表性也是我们项目开发所面对的销售群体，因为他们是学生信息管理系统的主要用户群体。

4. 使用这个学生信息管理系统软件的典型场景：王虎作为大学生，使用学生信息管理系统来查询课程安排、考试成绩、个人资料、和相关学校考证考研通知。是广大学生入学的最好助手等。

5. 使用本产品的环境：在校园的图书馆、宿舍或教室的电脑上使用，有时也会在智能手机上使用。主要的运用场景是在学生用户客户端、小程序等。

6. 生活/工作情况：王虎是一名大学生，主要的生活就是学习和参加校园活动、学校通知公告、就业考研通知帮扶。

7. 知识层次和能力：具有本科在读学历，对电脑和互联网比较熟悉，能够熟练操作常见的电子产品和软件。

8. 用户的动机、目的和困难：王虎的动机是更方便地获取和管理他们的个人信息和学习进度。他的目的是有效地管理自己的课程安排、考试成绩和个人信息。他面临的困难是需要组织的复杂而分散的信息。

9. 用户的偏好：王虎偏好使用界面友好、操作简单、能快速找到所需信息的学生信息管理系统。他重视系统的用户体验和个人信息的安全性。

教师用户

1. 名字：赵耀

2. 年龄和收入：30岁，月收入大约8000元

3. 代表的用户在市场上的比例和重要性：代表大学教师工薪阶层用户，在项目学生信息管理系统教育行业市场上占据较大比例，对于学生信息管理系统的使用需求也较重要。

4. 使用这个软件的典型场景：赵耀是一名大学老师，使用学生信息管理系统来记录学生基本信息、成绩、考勤等数据，便于教师对学生进行课后辅导和教学辅助。

5. 使用本产品的环境：在办公室或家里的电脑上使用。

6. 生活/工作情况：赵耀是一名全职的大学教师，在工作之余也会兼顾家庭生活而且学生信息管理系统。

7. 知识层次和能力：具有本科学历，对电脑和互联网比较熟悉，能够熟练操作常见的办公软件。

8. 用户的动机、目的和困难：赵耀的动机是提高教学工作效率，目的是更好地管理学生信息，困难是学生信息繁杂且易混淆。

9. 用户的偏好：喜欢简洁易用的界面，对系统稳定性和数据安全性有较高要求、希望项目开发能更加的人性化便于拉近师生关系，能对教师展开教育教学工作能起到辅助的作用。

作业2

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

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

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

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

•[客户待完成的任务]

•任务的频繁程度

•任务的细节

•[ 客户动机 ]

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

•[ 客户问题 ]

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

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

对于我们的项目来说，我们的项目主要用户分为：教师和学生

教师用户

对于教师用户，他们在学生信息管理系统中的典型场景可能与教务处工作人员有所不同。以下是针对教师用户的分析：

处于典型场景下的客户（教师）

客户位置与职责：例如作业1中的赵耀在教育体系中主要面对的工作是处于教学和评估学生学习成果的前线位置。他们负责授课、布置作业、批改作业、记录学生成绩以及与家长沟通学生的学习进展，以便对后续教学教育工作的展开也对学生全面发展。

目前使用的办法/工具：例如赵耀老师来说可能依赖于传统的纸质成绩册、电子邮件、学校提供的内部通讯平台以及可能存在的学生信息管理系统来管理学生信息和成绩，而我们现在的开发的项目便于教师对于教学工作的展开。

客户待完成的任务

任务频繁程度：例如赵耀老师可以需要频繁地更新和访问学生的成绩和表现，尤其是在每个学期的考试、作业提交和反馈周期，如此我们项目能够很好的帮助到教师群体，免去教师群体不必要的工作。能够把中心放在以学生为中心。

任务细节：赵耀老师在工作要面对的教学展开主要注意的细节：包括记录和更新学生的成绩、准备成绩报告、与学生和家长沟通学生的学习进展，以及管理课堂和学生出勤。

客户动机

完成任务的动机：赵耀老师希望提高工作效率，解放繁琐的登记等输入工作。以便能够能有更多的时间来关系学生的身心健康。希望项目能够确保学生成绩的准确性和及时性，以便更好地支持学生的学习和发展。

客户问题

最大的烦恼：赵耀老师面临的挑战可能包括手动记录和更新成绩的繁琐性，难以及时与家长沟通学生的表现，以及难以跟踪和分析学生的学习进展。

绕过问题的方式：赵耀老师可能会使用非正式的笔记和个人电子表格来记录学生信息，或者依赖于口头沟通来更新家长关于学生表现的信息。

改进措施

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

简化成绩录入：提供一个简单直观的界面，让赵耀老师能够快速录入和更新学生的成绩和反馈。

自动化成绩分析：开发工具自动分析学生的成绩和表现，生成可视化的报告，帮助赵耀老师识别学生的学习趋势和需要改进的领域，以以便促进学生个性发展。

家长沟通平台：集成一个安全的在线平台，使教师群体能够方便地与家长分享学生的成绩和进展，同时保持学生的隐私保护学生身心健康。

移动设备兼容性：确保系统可以在移动设备上使用，这样教师即使在校外也能随时更新和管理学生信息，便于老师对于学生信息的及时更新。

出勤管理：提供一个出勤跟踪系统，使教师能够轻松记录和管理学生的出勤情况。

即时反馈和通知：实现一个即时反馈系统，当学生成绩或出勤有重大变化时，系统能够自动通知教师和家长。

用户培训和支持：为教师提供全面的培训，确保他们能够充分利用系统的功能，并提供持续的技术支持。

作业3

用快速原型工具或笔和纸

画出一个本小组开发软件产品的典型场景，描述典型用户如何解决问题

场景=用户故事

原型设计的工具：

https://www.zhihu.com/question/19572438 Axure

https://zhuanlan.zhihu.com/p/34082256 墨刀

用户典型场景描述：

场景：学生成绩查询

场景描述：纸质成绩单需要人工整理、打印和分发，查询效率低下，尤其是在成绩公布的高峰期，也往往容易因为疏忽而丢失。

小明是一名即将毕业的学生，需要查阅大学四年的所有成绩来准备毕业材料。按照传统的纸质化方式，他需要前往教务处或学院办公室，逐一查找和复印成绩单。然而，由于临近毕业季，成绩公布和查询的人数众多，需要花费大量时间排队等待。

解决办法：

登录系统

查询成绩

查看成绩详情

作业4

问题0

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

一个成熟的团队应该具备一份涵盖从环境搭建到软件编译、单元测试执行的全过程，并且该文档应设置适当的权限，这样的好处是新队员能够方便地访问和使用，它详细记录了从环境配置到软件编译、单元测试的每一步操作。这样的文档可以极大地减少新队员在入门阶段的困惑和沟通成本，使他们能够更快地融入团队并开始工作。

文档可能包含以下内容：

环境搭建指南：详细列出安装和配置所需的所有软件、工具和依赖包的步骤。这包括操作系统要求、必要的软件包、配置文件的设置等。
代码获取与版本控制：说明如何从版本控制系统中获取最新代码，并解释代码仓库的基本结构。使用简单明了的语言和清晰的步骤描述，确保新队员能够轻松理解并按照文档操作
编译与构建过程：详细解释如何编译软件，包括必要的命令行参数、构建系统的使用以及任何特殊的构建步骤。
单元测试执行：提供执行单元测试的指导，包括所需的命令、测试框架的使用以及测试结果的分析。
常见问题与故障排除：列出在环境搭建、编译和测试过程中可能遇到的常见问题，以及相应的解决方案。
额外资源链接：提供其他相关文档、教程或在线帮助的链接，以便新队员进一步学习和探索
权限控制：通过适当的权限设置，确保只有授权人员能够访问和使用该文档，保护团队的知识产权和信息安全。
实时更新：随着软件版本更新、依赖关系变化或环境要求的调整，文档应及时更新，以确保其准确性和有效性。

问题1

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

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

一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？

有几种设计，各有什么优缺点？

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

在现代软件开发实践中过程，我们团队对于源代码控制通常是通过版本控制系统（Version Control System, VCS）来管理的。最常用的版本控制系统包括Git、Subversion（SVN）、Mercurial等。Git因其分布式特性、高效的性能和广泛的社区支持而成为最受欢迎的版本控制系统之一。

对于文件锁定问题和多用户同时修改同一文件的场景，不同的版本控制系统和工作流程有不同的处理方式。以下是几种常见的设计和它们的优缺点。

集中式版本控制系统（如SVN）

优点：操作简单便于操作，是指当一个文件被签出（checkout）后，系统会自动锁定该文件，防止其他用户同时签出和修改。

缺点：这种锁定机制可能会导致工作流程中断，如果甲需要长时间来完成功能，那么乙可能需要等待很长时间才能修复问题。此外，锁定机制可能会限制团队的并行工作能力。

分布式版本控制系统（如Git）

优点：提供了更高的灵活性便于团队控制。文件不会被锁定，多个开发者可以同时签出和修改同一个文件。通过分支（branch）和合并（merge）操作，团队成员可以独立工作，然后再将更改合并到主分支。

缺点：需要开发者具备一定的版本控制知识来正确处理分支和合并。合并冲突（merge conflict）可能会发生，需要手动解决。如果没有良好的沟通和协调，可能会导致代码集成时的问题。

分支策略

优点：通过使用特定的分支策略（如Git Flow或GitHub Flow），团队可以有效地管理功能开发和问题修复。这样可以确保主分支始终保持稳定，同时允许在功能分支上进行并行开发和问题修复。

缺点：需要团队成员遵循严格的分支策略，否则可能会导致混乱。

协作工具和工作流程

优点：使用如GitHub、GitLab、Bitbucket等平台，可以提供额外的协作功能，如Pull Request（PR）或Merge Request（MR），这些功能允许开发者在合并代码之前进行代码审查和讨论。

缺点：虽然这些工具提供了强大的协作功能，但它们并不能自动解决所有并发修改的问题。团队成员仍需要有效沟通以避免冲突。

问题2

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

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

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

在团队项目设计开发过程中我们要时刻对于版本有高度的重视，要查看文件和之前版本的差异，以及代码修改与工作项（work item）、缺陷修复（bug fix）的关系，通常需要依赖版本控制系统和一些辅助工具。以下是一些常见的方法和步骤：

查看文件差异（Diff）

1.使用版本控制系统的命令行工具：

对于版本控制系统来说，可以使用`git diff`命令。例如， git diff <commit_id1> <commit_id2> <file_path可以显示在两个提交（commit）之间，特定文件的更改内容。对于SVN，可以使用svn diff命令，它会显示两个版本之间文件的差异。

2.使用图形界面工具：

在使用图像界面供具中有许多版本控制系统的客户端软件，如GitHub Desktop、SourceTree、TortoiseSVN等，都提供了图形界面来查看文件差异。

关联代码修改与工作项/缺陷

1.使用问题跟踪系统：

集成问题跟踪系统（如JIRA、Bugzilla、Redmine等）可以帮助将代码更改与特定的工作项或缺陷修复关联起来。开发者在提交代码时，通常会在提交信息中引用或关联相关的工作项ID或缺陷ID。

2.使用Pull Request/Merge Request：

在GitHub、GitLab、Bitbucket等平台上创建Pull Request（PR）或Merge Request（MR）时，可以在描述中提及相关的工作项或缺陷。这些平台通常允许在代码审查过程中讨论和跟踪这些关联。

3.代码注释和文档：

在团队中会频繁的进行代码修改和注释，修改代码时开发者应该在代码注释中说明所做的更改，以及这些更改是为了解决哪些问题。维护良好的文档可以帮助其他团队成员理解代码更改的背景和目的。

场景应用对于程序员甲的情况：

1.查看文件的修改差异：

使用git diff或相应的版本控制工具命令来查看文件在不同版本之间的具体更改。如果是在图形界面工具中，通常可以直接在文件历史或版本对比中查看差异。

2.查找与修改相关的其他文件：

如果在版本控制系统支持，可以使用更广泛的diff查询，比如查看一个时间段内的所有更改。查看提交信息，通常会包含修改的概述，有时也会提及其他被修改的文件。

3.了解修改的目的和关联的问题：

在查看提交信息，开发者应该在一定的基础下提供了足够的信息来描述更改的目的和背景。如果使用了问题跟踪系统，可以通过提交信息中提及的ID来查找相关的工作项或缺陷。如果团队使用了Pull Request/Merge Request，可以在PR/MR的描述和讨论中找到相关信息。

问题3

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

当你在签出（checkout）一个文件后，如果在团队中有其他人也对同一个文件进行了修改并签入（commit）了，你的本地副本就会变得过时或者可以说是被覆盖。在这种情况下，你需要合并这些不同的修改。以下是合并修改的一般步骤和使用的工具：

1.合并修改的步骤

1.1更新本地副本：

首先，你需要更新你的本地副本以包含最新的更改。对于Git，你可以使用git pull命令来拉取远程仓库的更新。这将合并远程仓库的更改到你的本地分支。

1.2解决合并冲突：

如果你的更改和其他人所做的更改有冲突，版本控制系统会提示你解决这些冲突。你需要手动编辑冲突的文件，找到一个解决方案，既能保留中团队中你的更改，也能保留其他人的更改。

1.3测试更改：

解决冲突后，你应该运行单元测试和集成测试来确保更改没有引入新的错误。

1.4签入你的更改：

一旦测试通过，你可以提交你的合并更改。在Git中，这通常是通过git add添加修改文件，然后使用git commit来提交更改。

2.使用的工具

2.1版本控制系统的命令行工具：

对于Git，命令行工具是最基本的合并工具。git status可以帮助你查看哪些文件有冲突，git merge可以用来合并分支。

2.2图形界面客户端：

客户端软件如GitHub Desktop、SourceTree、TortoiseGit等提供了图形界面来帮助用户更容易地处理合并操作和冲突解决。

2.3集成开发环境（IDE）：

许多IDE，如Visual Studio、IntelliJ IDEA、Eclipse等，都有内置的版本控制工具，可以帮助你在代码编辑器中直接查看差异和解决冲突。

2.4.代码审查工具：

工具如Gerrit、Phabricator或GitHub的Pull Request功能可以让你在合并到主分支之前进行代码审查，这有助于提前发现和解决潜在的合并问题。

2.5合并工具：

专门的合并工具，如KDiff3、Meld、WinMerge（Windows）等，可以用来比较文件差异，并帮助解决合并冲突。

在合并过程中，良好的沟通和团队协作是非常重要的。如果你不确定如何解决某个冲突，或者你的更改可能会影响其他人的工作，最好与团队成员讨论以找到一个共同的解决方案。记住，合并更改是一个协作过程，需要团队成员共同努力以维护代码的质量和稳定性。

问题4

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

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

为了保证多个文件修改的原子性，避免中间状态导致的问题，程序员甲可以采取以下策略：

使用版本控制系统（如Git）的分支功能：
- 甲可以在自己的本地工作副本中创建一个新的分支，在这个分支上进行所有20个文件的修改。
- 当所有修改都完成后，并且测试无误，甲可以将这个分支合并到主分支（如master或main）。
- 合并操作通常是原子性的，要么全部成功，要么全部失败。
暂存修改：
- 甲可以使用版本控制系统的暂存功能（如Git的git stash），先将已经完成的修改暂存起来。
- 然后拉取最新的代码，解决合并冲突。
- 解决完冲突后，应用之前暂存的修改，并继续完成剩余文件的修改。
- 最后，一次性提交所有修改。
使用补丁或变更集：
- 某些版本控制系统（如Perforce）支持变更集（changeset）的概念，允许将一系列相关的修改作为一个整体进行管理。
- 甲可以将这20个文件的修改作为一个变更集，然后一次性提交这个变更集。
沟通与协调：
- 在进行大型修改时，甲应该提前通知团队成员，避免其他人在此期间进行相关的修改。
- 使用版本控制系统的通知功能（如Git的pull request），让其他成员知道有大型修改正在进行，并请求他们在合并完成前不要进行相关的修改。
持续集成/持续部署（CI/CD）：
- 使用CI/CD系统可以自动检查代码合并后的状态，包括编译、测试等。
- 如果甲将修改提交到CI/CD系统，并且CI/CD检查失败，那么可以及时发现问题，并阻止不稳定的代码进入主分支。

对于当前的情况，甲应该：

立即停止当前的修改工作。
通知团队成员，说明目前的问题和可能的解决方案。
使用版本控制系统的回滚功能（如Git的git reset），将已经签入的5个.h文件回滚到之前的状态。
拉取最新的代码，解决与.cpp文件的冲突。
使用上述策略之一，确保剩余的修改能够一次性、原子性地签入。

最后，为了避免类似的问题再次发生，团队应该建立代码合并和签入的规范，确保在合并大型修改前进行充分的沟通和协调。

问题5

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

在处理这种情况时，确保本地修改不会干扰到新bug的修复，同时又能保持这些修改以便后续继续完成，是一个重要的版本控制技巧。以下是一个基于Git的通用流程，来管理修改，同时修复新bug。

1. 暂存当前修改

首先，需要将当前的修改保存起来，以便稍后可以继续。

可以使用git stash命令来暂存修改。这个命令会保存当前的工作进度和暂存的修改到一个临时的存储区。例如：

git stash save "修改内容"

2. 切换到干净的工作区

接下来，需要确保工作区是干净的，以便开始修复新bug。

可以创建一个新的分支来修复bug，或者切换到现有的主线分支，并确保工作区是干净的。例如：

git checkout main 用来修复bug的分支

git pull origin main 确保分支是最新的

3. 修复新bug

然后可以开始修复新bug，确保所有的修改都是针对这个bug的，并且不要引入其他不相关的更改。

4. 提交bug修复

一旦修复了bug并测试了修改，即可以提交你的更改。

可以使用git add和git commit命令来暂存并提交修改。例如：

git add . 具体文件

git commit -m "描述你的bug修复"

git push origin main 推送你的更改到远程仓库

5. 重新应用之前的修改

一旦bug修复完成并被合并到主线后，可以回到之前的工作，并重新应用之前暂存的修改。

使用git stash pop命令来重新应用修改。如果在此期间有冲突，需要手动解决这些冲突。

通过遵循上述流程，可以有效地管理changelist，确保本地修改不会干扰到新bug的修复，并成功地将修改签入版本控制系统。

问题6

规范操作和自动化

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

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

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

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

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

确实存在一些自动化工具可以帮助团队实现这些功能。

首先，关于运行单元测试和代码质量测试，可以使用持续集成/持续部署（CI/CD）工具，如Jenkins、GitLab CI/CD或Travis CI等。这些工具可以配置为在每次代码提交时自动运行测试，并报告结果。如果测试失败，CI/CD工具通常会阻止代码合并，从而确保新代码不会破坏现有功能。

对于代码复审，有些版本控制系统（如GitLab和Bitbucket）内置了代码复审功能。在这些系统中，开发者可以提交代码更改，并指定其他团队成员进行复审。复审者可以在代码更改上留下评论，并决定是否批准合并。此外，还有一些专门的代码复审工具，如Crucible和Review Board，可以与版本控制系统集成，提供更为丰富的代码复审功能。

关于与签入相关的issue、任务或缺陷编号，这通常可以通过集成问题跟踪系统（如JIRA、GitHub Issues或GitLab Issues）来实现。开发者在提交代码时，可以在提交信息中包含相关issue或任务的编号。这样，团队成员就可以方便地通过编号查询相关讨论和上下文。

至于高级功能，即在代码提交后自动更新相关bug的状态并添加链接，这可以通过将CI/CD工具与问题跟踪系统集成来实现。例如，当代码合并到主分支并通过所有测试时，CI/CD工具可以自动触发一个操作，更新相关bug的状态为“fixed”，并在bug详情中添加指向这次提交的链接。

一个具体的例子是，使用Jenkins作为CI/CD工具，结合GitLab作为版本控制和代码复审平台，以及JIRA作为问题跟踪系统。Jenkins可以配置为在每次GitLab上的代码提交时触发构建和测试。如果构建和测试通过，Jenkins可以调用JIRA的API来更新相关bug的状态，并添加指向GitLab提交的链接。这样，团队成员就可以通过JIRA直接查看修复bug的具体代码更改。

问题7

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

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

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

在源代码管理中，使用分支是一种常见的做法，用于并行处理不同版本的代码。根据提供的场景，下面是使用Git来建立和管理分支的步骤：

场景一：为演示建立分支

1. 创建演示分支：

在当前的主分支（比如main或master）上，创建一个新的分支来用于演示：git checkout -b demo

这条命令会创建一个名为demo的新分支，并立即切换到这个分支。

2. 在演示分支上进行修改：

在这个分支上，可以做临时修改，这些修改不会影响主分支。

3. 提交修改：

完成修改后，提交这些更改：

git add . 将所有更改添加到暂存区

git commit -m "Made temporary changes for the demo" 提交更改

4. 演示后合并或丢弃修改：

演示结束后，如果决定要将某些修改合并回主分支，可以使用git cherry-pick来选择性地合并提交，或者git merge来合并整个分支的更改。如果决定不保留这些修改，可以简单地丢弃这个分支。

场景二：处理老版本的用户报告问题

1. 找到老版本的提交：

首先，需要找到用户所使用的老版本对应的Git提交。通常可以通过查看发布历史或使用git tag来找到对应的标签。

2. 检出老版本的代码：

一旦找到对应的提交或标签，可以检出该版本的代码：

git checkout <tag-or-commit-hash>

这将在分离头指针的状态下检出代码，意味着你处于一个“只读”的分支上。如果想要在这个版本的基础上工作，可以创建一个新的分支：

git checkout -b issue-branch <tag-or-commit-hash>

3. 尝试重现问题：

在检出的老版本代码基础上，尝试重现用户报告的问题，可能需要设置特定的配置、运行特定的测试或模拟用户的使用场景。

4. 修复问题并合并回主分支：

如果找到了问题的原因并修复了它，可能需要将这个修复合并回主分支。通常涉及将修复提交cherry-pick到主分支，或者如果之前创建了一个分支来修复问题，可以将整个分支合并回主分支。

问题8

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

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

面对一个历经多年、多个团队开发和维护的重要软件出现崩溃事故，并且已经定位到问题出在某一文件的某一行代码时，可以采取以下步骤来解决问题：

使用版本控制系统：
- 打开项目的版本控制系统界面，可以使用Git的命令行或图形界面工具
- 导航到包含问题代码的文件。
- 使用git blame查看文件每一行的最后修改信息或类似的命令来查看文件的每一行是由谁、在何时修改的。
- 检查相关的提交信息，它通常包含签入代码的目的和解决的任务或bug的信息。
查看提交历史：
- 通过版本控制系统的提交历史功能，可以浏览文件的所有变更记录。
- 查找与问题代码相关的提交，查看其提交信息和代码变更详情。
使用代码审查工具：
- 可以通过使用代码审查工具查找特定代码变更的审查记录。
- 审查记录中通常包含代码变更的原因、目的以及审查者的反馈，这有助于理解代码变更的上下文。
与团队成员沟通：
- 如果通过上述方法仍无法确定代码变更的目的，可以尝试与提交该变更的团队成员沟通。
- 他们可能能够提供关于代码变更的额外信息或上下文。
不要贸然修改代码

- 在修改代码之前，深入理解这一行代码的功能以及它在整个模块中的作用。
- 探究这行代码是如何与其他模块交互的，以及它的修改可能会影响到哪些其他部分的代码。
- 在修改代码之前，备份整个项目或至少备份有问题的文件，以便在修改出现问题时可以轻松恢复到原始状态。
- 在修改部署后，持续监控系统的稳定性和性能，确保修改没有导致新的问题。
- 准备一个回滚计划，以便在出现问题时可以迅速恢复到修改之前的状态。

如果贸然修改代码会增加引入新问题的风险，影响这个系统项目进展以及引发后面的一系列问题，这都是值得重视的。

问题9

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

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

标记这个 Last Known Good 版本，可以使用版本控制系统（如Git）的标签功能：

确定Last Known Good版本：
首先，通过测试、代码审查或其他质量检查手段确定一个质量稳定的提交。这个提交将作为Last Known Good版本。
创建标签：git tag LastKnownGood <commit-hash>
在Git中，使用git tag命令来创建一个标签。标签名可以命名为LastKnownGood
推送标签到远程仓库：git push origin LastKnownGood
其他人要能够看到这个标签并同步代码，将标签推送到远程仓库
同步带有标签的版本：
其他人可以通过克隆仓库或拉取更新来同步代码，并使用标签来检出特定版本的代码。例，要检出LastKnownGood标签对应的代码，可以运行git checkout LastKnownGood
更新Last Known Good标签：
随着时间的推移，你可能会找到一个新的、更稳定的版本，并希望更新LastKnownGood标签。为此，你需要先删除旧的标签（如果它已经推送到了远程仓库，你也需要在远程仓库中删除它），然后创建新的标签。

删除本地标签：git tag -d LastKnownGood

删除远程标签：git push origin :LastKnownGood

然后，确定新的稳定提交哈希值，并重复步骤2和3来创建和推送新的LastKnownGood标签。

文档化：
编写相应的文档，说明如何同步和使用LastKnownGood标签。
自动化：

可以编写一个脚本，在每次通过自动化测试或手动验证确定新的稳定版本时，自动更新LastKnownGood标签。

问题10

你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？

    在签入之前，程序员能否自动在自己的机器上运行自动测试，以保证本地修改不会影响整个软件的质量？

    在程序员提交签入之后，服务器上是否有自动测试程序，完成编译，测试，如果成功，就签入，否则，就取消签入？

    团队是否配置了服务器，它自动同步所有文件，自动构建，自动运行相关的单元测试，碰到错误能自动发邮件给团队

本软件开发团队会采取一系列自动化流程来确保代码质量和持续交付：

（1）源代码、测试和其他脚本的管理：源代码、单元测试和其他测试脚本会放在同一个代码仓库中，确保修改源代码时相应的测试也得到更新，有助于保持代码和测试的同步性。

（2）自动构建任务：本团队会配置自动构建任务，确保每次提交代码后都会自动进行构建和测试，有助于尽早发现潜在问题。

（3）本地自动测试：程序员可以在本地运行自动测试，以确保本地修改不会影响整个软件的质量。

（4）服务器自动测试：程序员提交代码后，服务器会自动进行编译、测试，如果成功则签入，否则取消签入，有助于代码质量和稳定性。

（5）自动同步、构建和通知：我们团队会配置服务器自动同步所有文件、自动构建、运行相关单元测试，并在出现错误时自动发邮件通知团队成员。

上面流程有助于团队在开发过程中保持代码质量、稳定性，并确保团队成员可以高效协作。

问题11

分析比较各种软件构建环境：

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

github

Gitee 高校版 - 助力计算机专业教学改革与「新工科」实践落地

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)

本团队自行搭建的系统

我们团队将选择Gitblit、Gitee、Visual Source Safe (VSS)等源代码管理和其他配套工具。

（1）Gitee

优点：

中国本土化支持：对中国用户友好，提供更快的访问速度和更好的技术支持。
免费私有仓库：提供免费的私有仓库，适合个人和小团队使用。
社区活跃：社区活跃度较高，可以找到技术讨论和资源分享。

缺点：

国际化程度较低：主要服务于中国用户，对国际用户支持不足。
生态系统相对薄弱：缺乏一些成熟的第三方集成工具和服务。

（2）Gitblit

优点：

简单轻量级：适合在Windows系统下快速搭建git服务，带网页端管理，简单易用。
自托管：可以完全控制代码库和访问权限。

缺点：

功能有限：相对于大型托管平台，功能可能较为有限。
社区支持相对较弱：由于其较小的用户群体，社区支持和资源可能不如大型平台丰富。

（3）Visual Source Safe (VSS)

优点：

易学易用：对于初学者来说，VSS相对容易上手。
成本较低：成本相对较低，适合预算有限的团队。

缺点：

安全性较低：VSS在安全性方面可能不如现代版本控制系统强大。
功能较弱：相对于其他现代工具，VSS的功能可能较为有限。

问题12

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

每个小组的开发环境和流程都可能有其独特之处，因此具体需要改进的地方也会因团队而异。不过，以下是一些常见的开发环境和流程中可以考虑改进的方面：

一、开发环境

版本控制工具：
- 检查是否使用了合适的版本控制系统（如Git），并确认其配置是否优化了团队协作效率。
- 评估代码分支策略是否清晰，合并流程是否顺畅。
集成开发环境（IDE）和工具链：
- 分析当前IDE或编辑器是否满足团队需求，是否存在性能瓶颈或配置问题。
- 检查代码构建、测试和部署工具是否自动化且高效。
代码质量和规范：
- 评估代码审查流程是否有效，是否有助于提升代码质量和减少缺陷。
- 检查是否有统一的代码风格规范，并确认团队成员是否遵守。

二、开发流程

需求管理和沟通：
- 分析需求收集、分析和验证的过程是否完善，是否确保了需求的准确性和完整性。
- 评估团队内部沟通是否顺畅，是否使用了合适的沟通工具和流程。
敏捷开发实践：
- 检查是否采用了敏捷开发方法（如Scrum或Kanban），并评估其实施效果。
- 分析迭代计划和交付物是否清晰，是否有助于团队高效协作。
测试策略和自动化：
- 评估测试用例的覆盖率和质量，检查是否有足够的自动化测试。
- 分析测试流程是否高效，是否能及时发现问题并修复。
持续集成和持续部署（CI/CD）：
- 检查是否使用了CI/CD流程，并评估其是否有助于加快代码合并和部署速度。
- 分析构建和部署过程中是否存在瓶颈或失败点。
反馈和回顾：
- 定期回顾开发流程，收集团队成员的反馈和建议，以便持续改进。
- 分析项目延期或失败的原因，并采取措施避免类似问题再次发生。

每个小组可以根据自身实际情况，对照上述方面进行检查和评估，找出需要改进的地方并制定具体的改进计划。同时，保持开放和积极的态度，不断学习和探索新的开发方法和工具，以提升团队的开发效率和产品质量。

作业13：考虑下面的软件需求：

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

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

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

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

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

•思维导图

•ER图

•Use Case

•Data Flow Diagram

•UML