[I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	2025春季软件工程(罗杰、任健)
这个作业的要求在哪里	[I.1]个人作业：阅读和提问
我在这个课程的目标是	在 PSP 和 TSP 中磨炼自身
这个作业在哪个具体方面帮助我实现目标	《构建之法：现代软件工程》给予我现代软件工程的世界观和方法论，即理论方面的指导

问题一：如何处理文件的锁定问题？

P252

程序员果冻正在对几个文件进行修改，实现一个大的功能，这时候，程序员小飞也要改其中一个文件，快速修复一个问题。一个代码文件被签出(checkout)之后，另一个团队成员可以签出这个文件，并修改，然后签入么?

查阅资料可知，对于文件的锁定问题，有以下三种常见设计方案：

1. 文件加锁（悲观锁）

• 设计：当一个开发者签出（checkout）一个文件时，系统自动锁定该文件，其他人无法签出或修改，直到锁被释放。
• 优点：
  • 避免冲突，确保同一时间只有一个开发者修改文件。
  • 适合二进制文件或不易合并的文件（如图片、设计文件）。
• 缺点：
  • 降低开发效率，其他开发者可能被阻塞。
  • 需要额外的锁管理机制，增加了复杂性。

2. 自由签出（乐观锁）

• 设计：所有开发者都可以自由签出和修改文件，系统在签入（commit）时检测冲突并提示解决。
• 优点：
  • 提高开发效率，允许多人并行修改文件。
  • 适合文本文件（如代码），易于合并。
• 缺点：
  • 可能产生冲突，需要开发者手动解决。
  • 对二进制文件的合并支持较差。

3. 分支策略

• 设计：每个开发者在自己的分支上工作，完成后再合并到主分支。
• 优点：
  • 完全隔离开发环境，减少冲突。
  • 适合大规模团队和复杂项目。
• 缺点：
  • 需要良好的分支管理策略。
  • 合并时可能产生冲突，需要解决。

根据我的经验，采用分支策略+自由签出比较好，因为团队分工明确后，各分支合并时不会有较大冲突，而且合并的是代码文本文件，也适合自由签出的策略。

问题二：如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候，如何合并不同的修改（merge）？如果的确有不能简单解决的冲突怎么办？

P253

果冻刚刚完成修改几个重要的函数，但是发现别人也修改了类似的地方，有些修改是在同一行，怎么保证签入的代码能完整体现果冻的思路，同时也不会导致影响别人先前改动的思路？

合并没冲突的修改简单，使用版本控制系统Git的命令 git pull --rebase ，把自己的改动重新应用到最新的代码上，使提交历史更清晰（而不是用 git pull）。对于不能在冲突可视化后手动修改代码来体现两人共同思路的冲突，查阅资料，知道需要使用 git log 和 git blame 查找是谁修改了冲突部分，接着讨论解决方案。

问题三：如何在有很多本地修改的电脑上快速获得一个干净的代码环境？

P253

果冻的电脑上有关于两个功能的修改，但是都没有完成，有很多文件处于半完工的状态，这时他要紧急修改一个新的bug，修改的地方也在这些文件中，他只有这一台PC。如何把本地修改放一边，保证在干净的环境中修改这个bug，编译，并成功地签入你的修改？

没遇到过这种情况，于是查询资料，知道可以使用 git stash 将所有未提交的修改（包括暂存区和工作区的修改）保存到一个栈中，工作区恢复到上一次提交的状态，然后新建分支，在新分支中提交修复，接着回到原来分支，使用 git stash pop 来恢复暂存的修改。当然，此时代码可能是有bug的，修复即可。

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

P254

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

这也是一个不懂的知识，从 https://blog.csdn.net/weixin_67727883/article/details/139315400 中可以了解 Git 中 Branch(分支) 和 Tag(标签) 的区别。另外查阅资料，这个问题可以按照如下步骤解决：

步骤 1：创建附注标签

在 Git 中，使用以下命令创建附注标签：

git tag -a v1.0.0-lkg -m "Last Known Good version for internal testing"

• v1.0.0-lkg 是标签名称，推荐使用语义化版本号（如 v1.0.0）加上 -lkg 后缀。
• -m 参数用于添加标签的描述信息。

步骤 2：推送标签到远程仓库

默认情况下，git push 不会推送标签，需要显式推送：

git push origin v1.0.0-lkg

或者推送所有标签：

git push origin --tags

步骤 3：同步到 LKG 版本

新员工或其他团队成员可以通过以下命令同步到 LKG 版本：

git fetch --tags
git checkout v1.0.0-lkg

以上步骤可以通过脚本来自动化，减少手动操作。

问题五：“大马哈鱼洄游模型”是什么？对我们认识软件设计和认识有何作用？

P256

问：
在项目开始之前，有很多队员还没有接触过编程语言（例如 C#），导致 PM 在分配任务时很难用时间来衡量，就拿写一个Web Service这一模块来说，一个熟练的程序员可能只需要两个小时，而对于初学者来说，就得先花两天来理解 Web Service 的实现机制和原理。在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。这时应该怎么办？

阿超：
一个商业项目，请不要让连开发语言都没有接触过的队员进行开发工作。并不是非得“写”程序才是对项目有贡献，有时不写也有很好的贡献。如果他们有热情，就从测试开始学习吧。请参看前面提到的“大马哈鱼洄游模型”。

查阅资料，知道大马哈鱼洄游模型（Salmon Migration Model）是一个描述大马哈鱼（Salmon）在其生命周期中从淡水到海水再返回淡水的洄游行为的生态模型。大马哈鱼以其独特的洄游行为闻名，这种模型通常用于研究其生命周期、种群动态、栖息地需求以及环境变化对其生存的影响。但是，这与软件工程又有什么关系呢？

问题六：对话框用 OK/Cancel 的按钮选择好呢？还是在按钮上标明动作如[退出]/[保存]？

P275

产品设计开发一个很有趣的环节，就是钻研细节的界面设计。例如，网页、PC软件和手机软件有许多地方都会出现下面的两个按钮，[确定]|[取消] 或者 OK | Cancel。同学们估计对此已经非常习惯了，但是这两个小小的按钮也大有文章：[确定]按钮是放在左边还是右边？哪一个按钮是处于预先选择的状态（按回车键的时候就自动选择）？哪一种设计更符合人类习惯？你觉得这个问题重要么？你怎么设计统一的规范？

这个问题可以换种说法：对话框按钮是否选择动词形式？由 https://ux.stackexchange.com/questions/9946/should-i-use-yes-no-or-ok-cancel-on-my-message-box 上的讨论，发现需要根据实际情况合理使用这两种形式。一般来说可以使用动词，防止让用户产生误解，比如询问“Are you sure you want to cancel? If you cancel now you will not receive this file.”时，OK | Cancel 形式的按钮可能会产生误会。而且，当用户误读了对话框中的消息，使用明确的动词形式能减少混淆。当然，对于动词形式选项过长或消息是简单的一般疑问句时，不需要使用动词形式。其实，OK/Cancel 就像是旧时代的遗留物，当时屏幕的分辨率很低，按钮必须简洁才能适应。

问题七：为什么“治理者”更受关注，而“预防者”往往被忽略？这样是对的吗？

P345

二柱：这个跟王屋河的防洪是一个道理，上游搞得好，不发洪水没人知道，下游要决堤了，一堆人上去堵，死伤几个，就出名了。我们最善于搞末端治理。 在软件开发上，如果项目早期就发现并解决了问题，除了“家里人”，没人知道；项目中期发现问题并解决，项目的许多相关人员都知道了；项目后期出了问题，我们要加班，重写代码，hack原来的设计，开一些后门来解决问题（下一些副作用很大的猛药），总算把项目给救活了，这时候全公司的人都知道了。

阿超：我记得小学六年级学过“曲突徙薪”的故事，也讲了类似的道理。我们往往奖励末端治理的英雄，但是最初提建议的人未必得到奖励，移山公司会不会也是这样？

这个现象和IT界流传的一个笑话很像：公司中有两个人，A 代码写得好没有bug，整天零食、聊天、满屋跑；B 代码bug多，每天忙到子午时，辛苦上班态度好。最后老板当然就把A裁了，总结——职场仿佛演戏，全靠个人演技。这个笑话可能不太契合，但我认为这个现象是不对的。查阅资料，原因包括以下几点：一是末端治理成果是显性的，预防工作是隐性的；二是认知偏差，人们倾向于将成功归因于“解决问题的人”，而非“避免问题的人”；三是幸存者偏差，未被预防的问题一旦爆发，会引发强烈关注，而成功预防的问题则无声无息，导致预防者的努力被历史遗忘。那如何解决呢？我认为现代的软件工程流程考虑了这个问题，通过代码复审、工作记录等环节使得预防工作显性化、具体化了。