第六组【团队作业】第五周作业

  1. 如果你的团队来了一个新队员,有一台全新的机器, 你们是否有一个文档,只要设置了相应的权限,他就可以根据文档,从头开始搭建环境,并成功地把最新、最稳定版本的软件编译出来,并运行必要的单元测试? (在这过程中,不需要和老队员做任何交流)
    答:是的,我们有一个文档,可以让新队员从头开始搭建环境,并成功地把最新、最稳定版本的软件编译出来,并运行必要的单元测试。该文档包含以下步骤:
    (1)安装操作系统和依赖项
    选择并安装支持目标软件的操作系统。
    安装必要的依赖项,例如编译器、库和开发工具。
    (2)克隆代码库
    使用 Git 或其他版本控制工具克隆目标软件的代码库。
    (3)配置编译环境
    按照代码库中的说明配置编译环境,例如设置环境变量和编译选项。
    (4)编译软件
    运行编译命令编译软件。
    (5)运行单元测试
    运行单元测试以验证软件是否正常工作。
    为了让新队员能够独立完成上述步骤,文档中还包含以下内容:
    详细的操作说明,截图和示例,常见问题的解答,此外,我们还提供了一个 虚拟机镜像,其中包含已安装的操作系统、依赖项和编译环境。新队员可以使用虚拟机镜像快速开始开发工作,而无需在自己的机器上进行任何配置。在文档中提供有关代码库和软件架构的概述,以便新队员能够更好地理解软件。使用截图和示例来解释复杂的概念和步骤。提供一个论坛或聊天室,让新队员可以向老队员提问。通过这些措施,我们可以确保新队员能够顺利完成环境搭建和软件编译工作,并尽快融入团队。

  2. 你的团队的源代码控制在哪里?用的是什么系统?如何处理文件的锁定问题?
    场景: 程序员甲正在对几个文件进行修改,实现一个大的功能, 这时候,程序员乙也要改其中一个文件,快速修复一个问题。怎么办?
    个代码文件被签出 (check out) 之后,另一个团队成员可以签出这个文件,并修改,然后签入么?
    有几种设计,各有什么优缺点?
    例如,签出文件后,此文件就加锁,别人无法签出;或者,所有人都可以自由签出文件

答:(1)源代码控制系统
我们的团队使用 Git 进行源代码控制。Git 是一个分布式版本控制系统,具有以下优点:
版本控制:可以跟踪代码的每一次修改,并轻松回滚到之前的版本。
分布式:每个团队成员都有自己的代码副本,可以离线工作。
协作:团队成员可以通过分支和合并来协作开发。
(2)文件锁定问题
在 Git 中,文件锁定是一个常见的问题。当一个程序员正在修改一个文件时,其他程序员可能也需要修改同一个文件。这可能会导致冲突,例如代码覆盖或数据丢失。
(3)处理文件锁定问题
可以通过以下几种方式解决
签出文件:在 Git 中,签出文件是获取文件修改权限的一种方式。当一个程序员签出文件时,其他程序员将无法签出同一个文件。这可以防止冲突,但也会降低并行开发效率。
分支和合并:团队成员可以创建自己的分支来进行修改,并在完成后合并到主分支。这可以提高并行开发效率,但需要团队成员之间进行良好的沟通和协调。
使用锁文件:一些代码编辑器和 IDE 支持使用锁文件来防止冲突。当一个程序员打开一个文件时,锁文件会被创建。其他程序员在打开同一个文件时会看到警告,并可以选择放弃或等待。
(4)不同设计方案的优缺点
方案 优点 缺点
签出文件 防止冲突 降低并行开发效率
分支和合并 提高并行开发效率 需要团队成员之间进行良好的沟通和协调
使用锁文件 提高并行开发效率 可能存在兼容性问题

  1. 如何看到这个文件和之前版本的差异? 如何看到代码修改和工作项 (work item),缺陷修复 (bug fix) 的关系。
    场景: 程序员甲看到某个文件被修改了,他怎么看到这个文件在最近的修改究竟改了哪些地方? (例子)
    场景: 程序员甲看到某个文件在最新版本被改动了100 多行, 那么和这100多行对应的其他修改在什么文件中呢? 这个修改是为了解决哪些问题而作的呢? 那些问题有工作项 (work item,issue),或者bug 来跟踪么?
    答:查看文件差异和代码修改与工作项的关系
    (1)查看文件差异
    在 Git 中,可以使用以下命令查看文件差异:
    git diff
    该命令将显示文件自上次提交以来的所有修改。
    此外,还可以使用 Git 的图形界面工具来查看文件差异,例如 GitKraken 或 SourceTree。
    (2)查看代码修改与工作项的关系
    使用 Git 提交信息
    在 Git 中,提交信息可以用来描述代码修改的原因和目的。
    使用工作项跟踪系统
    许多团队使用工作项跟踪系统来跟踪代码修改与工作项的关系。例如,可以使用 Jira 或 Asana 来创建工作项,并将其与代码提交关联起来。
    代码审查
    代码审查可以帮助团队成员了解代码修改的原因和目的。在代码审查过程中,团队成员可以查看代码修改并提出问题或建议。
    (3)场景示例
    场景 1:查看最近修改
    程序员甲可以使用 git diff 命令查看某个文件最近的修改。
    场景 1:查看相关修改
    程序员甲可以使用 Git 的图形界面工具来查看某个文件所有相关的修改。
    场景 2:查看工作项关联
    如果团队使用工作项跟踪系统,程序员甲可以使用工作项跟踪系统来查看某个代码修改关联的工作项。

  2. 如果某个文件在你签出之后已经被别人修改,并且签入了,那么你在签入你的修改的时候, 如何合并不同的修改(merge)? 你用了什么工具来帮助你?
    答:当签出的文件已经被其他人修改并签入后,在签入您的修改时,Git 会自动进行合并。合并过程如下:
    Git 会找到您和其他人修改的共同祖先版本。
    Git 会将您的修改和其他人修改应用于共同祖先版本。
    如果两个修改对同一行代码进行了修改,Git 会产生合并冲突。
    合并工具
    Git 提供了一些命令行工具来帮助您解决合并冲突,
    解决合并冲突
    要解决合并冲突,您需要手动编辑冲突的文件,并选择要保留的修改。

  3. 你有20个文件都是关于同一个功能的修改,你要如何保证这些文件都同时签入成功(修改的原子性),或者同时签入不成功?
    场景:程序员甲要签入 20 个文件,他一个一个地签入,在签入完5个.h文件之后, 他发现一些 .cpp 文件和最新的版本有冲突,他正在花时间琢磨如何合并... 这时候,程序员乙从客户端同步了所有最新代码,开始编译, 但是编译不成功 - 因为有不同步的.h文件和.cpp文件!这时候,别的程序员也来抱怨同样的问题,甲应该怎么办?
    答:解决方案
    (1)使用 Git 分支
    创建一个新的分支来进行修改。
    在新分支中,将所有相关文件修改并提交。
    使用 git merge 命令将新分支合并到主分支。
    (2)使用 Git 暂存区
    将所有相关文件添加到暂存区。
    使用 git commit 命令提交所有文件。
    (3)使用原子提交工具
    使用一些原子提交工具,例如 atomic-git 或 git-atomic。
    场景分析
    在程序员甲签入5个.h文件之后,发现.cpp文件和最新版本有冲突。此时,程序员甲应该:停止签入操作。解决.h文件.cpp文件的冲突。
    使用上述方法之一将所有文件原子性提交。

  4. 你的PC上有关于三个功能的修改,但是都没有完成,有很多文件处于半完工的状态,这时你要紧急修改一个新的 bug,如何把本地修改放一边,保证在干净的环境中修改这个 bug, 并成功地签入你的修改 --- changelist management。
    答:以下是在本地修改的情况下,在干净的环境中修改 bug 并成功签入修改的步骤:
    (1)建新分支
    首先,创建一个新的分支来进行 bug 修复。这样可以将 bug 修复与本地修改隔离,避免冲突。
    git checkout master
    git pull
    git checkout -b bugfix-new-bug
    (2)恢复干净环境
    接下来,将新分支重置为干净的状态,即撤销所有本地修改。
    git reset --hard HEAD
    (3)修改 bug
    现在,您可以开始修改 bug 了。请确保您的修改是完整且经过测试的。
    (4)提交修改
    完成修改后,将您的修改提交到新分支。
    git add .
    git commit -m "Fix new bug"
    (5)合并分支
    最后,将新分支合并到 master 分支。
    git checkout master
    git pull
    git merge bugfix-new-bug
    (6)推送修改
    将合并后的 master 分支推送到远程仓库。
    git push origin master

  5. 规范操作和自动化
    你的团队规定开发者签入的时候要做这些事情:

  • 运行单元测试,相关的代码质量测试。
  • 代码复审 (要有别的员工的名字)
  • 和这次签入相关的issue 编号, 任务/task, 缺陷/bug 编号,等等, 以备查询。
    请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么? (高级功能, 代码提交之后, 相关bug 的状态会改动为 “fixed”, 并且有链接指向这次签入。),举个例子。
    答:是的,我的团队有这样的自动化工具,可以帮助开发者方便地一次性填入所有信息然后提交。该工具名为“代码提交助手”,它可以与团队使用的代码管理工具(例如 Git)进行集成。
    使用代码提交助手,开发者可以:
    在提交代码之前,运行单元测试和相关的代码质量测试。选择一位或多位团队成员进行代码复审。关联本次提交相关的 issue 编号、任务/task、缺陷/bug 编号等信息。
    代码提交助手还支持以下高级功能:
    代码提交之后,相关 bug 的状态会自动改为“已修复”,并附上指向本次提交的链接。可以根据提交信息自动生成更新日志。
    可以自动发送通知邮件给相关人员,例如代码作者、代码评审者、项目经理等。
    以下是使用代码提交助手的示例:
    假设开发者小明完成了修复一个 bug 的任务,他需要提交代码。小明可以使用代码提交助手来完成以下操作:
    在代码提交助手界面中,选择要提交的文件。选择“运行测试”按钮,运行单元测试和相关的代码质量测试。选择“代码评审”按钮,选择小王和小红进行代码评审。在“关联信息”框中,输入本次提交相关的 issue 编号、任务/task 编号等信息。点击“提交”按钮,提交代码。代码提交之后,相关 bug 的状态会自动改为“已修复”,并附上指向本次提交的链接。小王和小红会收到来自代码提交助手的通知邮件,提醒他们进行代码评审。
    代码提交助手可以帮助团队提高代码提交的效率和规范性,并简化代码管理流程。
  1. 如何给你的源代码建立分支?
    场景:你们需要做一个演示,所以在演示版本的分支中对各处的代码做了一个临时的修改, 同时,主要的分支还保持原来的计划开发。 你们怎么做到的? 在演示之后,演示版本的有些修改应该合并到主分支中,有些则不用,你们是怎么做到的?
    场景: 你们的软件发布了,有很多用户,一天,一个用户报告了一个问题,但是他们是用某个老版本,而且没有条件更新到最新版本。 这时候,你如何在本地构建一个老版本的软件,并试图重现那个问题?
    答:场景1:
    创建一个新的分支用于演示:
    git checkout -b demo
    在演示分支上进行修改和测试。
    当演示完成后,可以将演示分支合并到主分支中:
    git checkout master
    git merge demo
    选择性地合并修改:
    对于需要保留的修改,可以使用 git merge --no-ff 命令进行合并,这样会创建一个新的合并提交,记录合并的历史。
    对于不需要保留的修改,可以使用 git rebase 命令将演示分支的修改重新应用到主分支上,这样会使主分支的提交历史更加简洁。
    场景2:
    切换到相应的版本分支:
    git checkout
    构建软件:
    ./gradlew build
    运行软件并尝试重现问题。

  2. 一个源文件,如何知道它的每一行都是什么时候签入的,为了什么目的签入的 (解决了哪个任务,或者哪个bug)?
    场景:一个重要的软件历经几年,几个团队的开发和维护,忽然出现在某个条件下崩溃的事故, 程序员甲经过各种debug手段,发现问题是在某一个文件中有一行代码似乎显然出了问题, 但是这个模块被很多其他模块调用, 这行代码是什么时候,为了什么目的,经过谁签入的呢? 如果贸然修改, 会不会导致其他问题呢?怎么办?
    答:通过以下方法查询
    (1)代码版本控制系统 (VCS) 查询:
    使用 Git、SVN 等 VCS 查询代码历史记录。
    通过 git log 或 svn log 命令,以行号或代码片段为搜索条件,查询该行代码的提交记录。
    提交记录包含时间、作者、提交信息等,可了解代码签入时间、目的和作者。
    (2)代码注释:
    查看代码行附近是否有注释,记录修改时间、目的和作者信息。
    规范的代码提交应该包含注释,解释代码修改原因。
    (3)开发人员沟通:
    联系代码所属模块的开发人员,了解代码修改历史和目的。
    团队成员间沟通可获取更详细的上下文信息,辅助判断代码修改风险。
    (4)其他辅助手段:
    代码分析工具: 利用 SonarQube 等工具分析代码缺陷,辅助判断代码修改是否合理。
    测试用例: 运行相关测试用例,验证代码修改是否引入新的问题。
    风险评估:评估修改代码可能带来的影响,包括对其他模块的调用关系、代码稳定性等。谨慎修改代码,必要时进行测试验证,降低风险。

  3. 如何给一个系统的所有源文件都打上标签,这样别人可以同步所有有这个标签的文件版本?
    代码每天都在变, 有时质量变好,有时变差,我们需要一个 Last Known Good (最后稳定的好版本) 版本, 这样新员工就可以同步这个版本, 我们如果需要发布,也是从这个版本开始。 那么如何标记这个 Last Known Good 版本呢?
    答:给系统的所有源文件打标签,可以按照以下步骤进行:
    (1)确定要打标签的版本。 可以根据代码质量、发布时间等因素来确定。
    (2)使用版本控制系统来标记该版本。 在 Git 中,可以使用 git tag 命令来打标签。
    (3)将标签推送到版本控制系统的远程仓库。 这样其他人就可以看到和同步这个版本。
    具体来说,给所有源文件打标签 的步骤如下:
    (1)在版本控制系统中,找到要打标签的提交。
    (2)使用 git tag 命令来打标签。例如,要给版本 v1.0.0 打标签,可以使用以下命令:
    git tag v1.0.0
    (3)将标签推送到版本控制系统的远程仓库。例如,要将标签推送到 GitHub 仓库,可以使用以下命令:
    git push origin v1.0.0
    共享标签
    一旦给所有源文件打上标签,确保将这些标签推送到版本控制系统的远程仓库中,这样其他人也可以看到和同步这些标签。
    标记 Last Known Good 版本
    要标记一个 Last Known Good (最后稳定的好版本)版本,可以通过版本控制系统来实现。以下是一种常见的做法:
    (1)在版本控制系统中,找到要标记的提交。
    (2)使用 git tag 命令来打标签。例如,要给版本 v1.0.0 打标签,可以使用以下命令:
    git tag LastKnownGood v1.0.0
    (3)将标签推送到版本控制系统的远程仓库。例如,要将标签推送到 GitHub 仓库,可以使用以下命令:
    git push origin LastKnownGood
    新员工同步 Last Known Good 版本
    新员工可以通过以下步骤来同步 Last Known Good 版本:
    (1)克隆版本控制系统的远程仓库。
    (2)切换到 Last Known Good 版本。例如,在 Git 中,可以使用以下命令:
    git checkout LastKnownGood
    (3)更新代码。
    发布
    发布时,可以从 Last Known Good 版本开始,然后进行必要的修改。

  4. 你的项目的源代码和测试这些代码的单元测试,以及其他测试脚本都是放在一起的么? 修改源代码会确保相应的测试也更新么?你的团队是否能部署自动构建的任务?
    在签入之前,程序员能否自动在自己的机器上运行自动测试,以保证本地修改不会影响整个软件的质量?
    在程序员提交签入之后,服务器上是否有自动测试程序, 完成编译,测试,如果成功,就签入,否则,就取消签入?
    团队是否配置了服务器,它自动同步所有文件,自动构建,自动运行相关的单元测试,碰到错误能自动发邮件给团队
    答:(1)代码和测试
    源代码和测试代码应该放在一起,方便管理和维护。
    修改源代码时,应该确保相应的测试也更新,以保证代码质量。
    (2)自动化构建和测试
    团队应该部署自动构建的任务,以提高效率和减少人为错误。
    程序员在签入代码之前,应该在自己的机器上运行自动测试,以保证本地修改不会影响整个软件的质量。
    在程序员提交代码之后,服务器上应该有自动测试程序,完成编译、测试和签入。如果测试失败,则应该取消签入。
    (3)持续集成和持续部署
    团队应该配置服务器,自动同步所有文件、自动构建、自动运行相关的单元测试,并在遇到错误时自动发邮件给团队。

11,分析比较各种软件构建环境:
就像一个厨师要分析各种厨房用具,挑选适合自己的工具组合, 一个软件团队也要挑选适合自己的源代码管理和其他配套工具,请选择至少三种,比较各自的优点缺点,成本:
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 https://gitee.com/education code.csdn.net
优点 开源免费, 开源免费 免费
社区活跃,资源丰富, 代码托管在国内,访问速度快 支持多种语言和项目类型
支持多种语言和项目类型, 支持多种语言和项目类型 提供代码仓库管理、代码评审、Issue 跟踪、Wiki 等功能
提供代码仓库管理、代码评审、Issue 跟踪、Wiki 等功能, 提供代码仓库管理、代码评审、Issue 跟踪、Wiki 等功能 支持私有仓库,可用于商业项目
支持私有仓库,可用于商业项目 支持私有仓库,可用于商业项目

缺点 免费版存储空间有限 社区活跃度相对较低 社区活跃度相对较低
代码审查功能较为简单 代码审查功能较为简单 代码审查功能较为简单
私有仓库价格较高 私有仓库价格较高 私有仓库价格较高

成本 免费版:0 美元/月 免费版:0 美元/月 免费版:0 美元
私有仓库:7 美元/月/用户起 私有仓库:39 元/月/用户起 私有仓库:29 元/月/用户起

12.每个小组说明自己团队的开发环境和流程有什么需要改进的地方?
答:开发环境
(1)统一开发环境: 建议团队使用统一的开发环境,如虚拟机镜像或容器,以确保代码的一致性和可移植性。
(2)版本控制: 建议使用Git等版本控制工具,以便团队成员可以协作开发并跟踪代码变更。
(3)自动化测试: 建议使用自动化测试工具,如Jest或Mocha,以提高代码质量和测试效率。
(4)持续集成/持续部署: 建议使用CI/CD工具,如Jenkins或Travis CI,以自动化代码构建、测试和部署流程。
开发流程
(1)需求分析: 建议在开发开始前进行详细的需求分析,以明确系统的功能和目标。
(2)设计文档: 建议编写详细的设计文档,以规范系统的架构和设计。
(3)编码规范: 建议制定编码规范,以确保代码风格一致、易于阅读和维护。
(4)代码评审: 建议定期进行代码评审,以发现代码中的缺陷和潜在问题。
(5)测试: 建议在开发过程中进行单元测试、集成测试和系统测试,以确保系统的质量。
(6)发布和维护: 建议制定发布和维护计划,以确保系统的稳定性和安全性。

13考虑下面的软件需求:
•手机英语背单词软件,用户可以选择单词本的类型(四级,六级,GRE,等),每天背单词的进度。
•可以和好友分享自己背单词的进度。还可以挑战好友,挑选20个单词,送给好友,让好友选择正确的解释,并把成绩自动分享回来。
•假设有微博/微信/email 可以确定用户的身份
•假设有服务器可以返回 【中文 – 英语单词】的对应关系
用下面的工具进一步分析这些需求,做出草图
•思维导图
•E-R图
•Use Case
•Data Flow Diagram
•UML
(1)思维导图

(2)E-R图

(3)Use Case

(4)Data Flow Diagrm

(5)UML

posted @ 2024-04-05 23:03  庄东伟  阅读(23)  评论(0编辑  收藏  举报