[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	首页 - 2025年春季软件工程（罗杰、任健） - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[I.3] 个人作业：结课总结 - 作业 - 2025年春季软件工程（罗杰、任健） - 班级博客 - 博客园
我在这个课程的目标是	体验软件开发的整个流程，对软件工程有更深的了解
这个作业在哪个具体方面帮助我实现目标	通过回望软件工程这门课程的全部内容，对照我过去曾经的疑惑，对软件开发有了更深的体会。

以前提问的博客

软工个人作业1.1 - 六拾一61 - 博客园

解答以前的疑惑

问题一

我看了这段文字：

软件开发过程很大程度上是一个探索和实验的过程, 不同的 re-work 能帮助工程师深入了解项目的各个难点, 尽早交付原型, 找到最优解决方案，等等. 因此 re-work 是有价值的。

我的问题是re-work就一定能提高软件最终的质量吗？

根据我过往的实践经历，re-work其实有主动和被动之分，主动的re-work是在项目开发过程中受人启迪或根据问题的迭代发展来改变自己的程序架构，这种re-work虽然看似增长了软件开发的时间，但最后能得到一个功能更强、框架更清晰的软件项目。但也不能否认存在被动re-work，这种一般是遇到无法解决的问题，才不得不改变原有的软件架构，而这种改变往往不够彻底、也不够高明，有些甚至还是在原有的程序上打补丁。因此我觉得在软件开发过程中，对re-work要有辩证的看法。

问题一的回答

我认为大部分re-work是能提高软件质量的。在团队作业中，一是因为从alhpa到beta的功能迭代，二是因为队友的新增功能需要调用我们的模块，导致我们经常会面对re-work的情况。其中最多的就是修改方法参数，使其具备更广泛的应用，比如丢弃物品这一方法从丢弃单个物品，到丢弃多个物品，就需要新增物品数量这一形参。

这种re-work虽然是面向问题型的，更偏向被动re-work，但最后确实提高了软件质量。不仅体现在功能多样化上，更体现在代码接口的统一性上。因此，我认为大部分re-work是能提高软件最终质量的，但re-work也需要跟队友积极沟通，以免信息差带来的调用错误。

问题二

我看了这段文字：

个人的劳动成果有序地组织起来, 就是团队的流程。这里说的“有序”, 并不是“无争论”, 在大部分成功的软件团队模型中, 各个角色（开发, 测试, 项目管理等）考虑问题的出发点是有区别的, 不同意见的冲突在所难免, 一个好的团队流程能把冲突的积极方面 (各自尽力把自己的工作做好，说服别人) 释放出来, 而避免消极方面 (因为冲突而产生的消极，抵触情绪等)。

我的问题是能针对积极冲突提出一些具体的建议吗？

根据我过往的经验，小组内大家各有自己的想法，互相说服的过程中总有人的想法不被采纳，长此以往可能会有人丧失信心和积极性。因此我的困惑是，在这篇讲义中对“冲突”的积极和消极方面描述得太笼统、也太理想化了，可以针对冲突积极化提出一些具体的建议，以供我们小组合作时参考吗？

问题二的回答

在团队开发过程中，尤其是开发初期，我们团队也面临过分歧，具体表现在有些开发难度较高、且非软件核心的功能是否要阉割等问题上。

面对这些冲突，我们团队采取的策略是在小组会议上讨论。如遇重大决策问题，进行匿名投票表决，采纳票数高的作为主方案，选票第二的作为备胎方案，若实践过程中主方案确实存在缺陷，也可以及时换用备选方案。这样能在个人创意和团队决策之间寻找平衡点，充分照顾到各方角色的考量。

同时，我们团队内部成员关系融洽。每次提出自己意见前，我都会仔细倾听别人的方案，利用“先夸后问”发言法，先肯定对方的优点再表达顾虑。这很利于改善沟通氛围，自然也就不会有冲突产生的消极情绪。

我觉得解决冲突的关键在于把“谁对谁错”变成“怎样能更好”，这样才能把冲突变为提高软件质量的动能。

问题三

我看了这段文字：

单元测试必须覆盖所测单元的所有代码路径。

问：啊！这样岂不是要写很多啰里啰唆的测试方法？

答：对，因为程序中很多缺陷都是从这些啰里啰唆的错误处理中产生的。如果你的模块中某个错误处理路径很难到达，那你也许要想想是否可以把这个错误处理拿掉。

我的问题是所有软件工程的单元测试都要保证100%的覆盖率吗？

我联想到了老师课上的提问，对于一个用户极低概率会使用的功能，我们要将其实现吗？和这里的问题类似，如果一个错误处理路径很难到达，还是要坚持100%的测试覆盖率吗？对于此好像没有标准答案，我自己也不太能抉择是否要投入庞大的时间去维护测试的覆盖率，或许我在之后的软件开发过程中会有更深体会。

问题三的回答

对于这个问题，比起用户的使用频率，更重要的是以下几个问题：

首先要明确，这一用户极低概率会使用的功能，如果该模块出错会导致多少损失，会严重影响用户的软件体验吗？涉及软件的核心功能吗？

其次要明确，这个代码是否经常被改动？因为高频修改的代码需要更高的覆盖率。

最后要明确，这个功能依赖外部服务的复杂度。依赖越多越需要测试。

如果思考完以上问题，仍觉得该功能是极低概率使用、测试覆盖要求不高的，那么综合时间成本的考量，可以不测。但其实有时候删除反而会比不测好，如果真的几乎不可能发生，考虑直接移除该异常处理，更能减少维护负担。

我从中得到的经验是，不要过度纠结于覆盖率数字本身，测试的本质是"用可控的成本减少不可控的风险"。

问题四

我看了这段文字：

PM 太多了以后, 由于大部分决定都是经过平等而反复的讨论协商折中的到的, 一个后果是 “design by committee”, 一些产品不能很快跟上市场变化, 在需要个人特色的方面, 如设计/UI, “committee”设计出来的东西大多中规中矩, 但是很多方面了无新意。

在PM主导的产品中，“不犯大错”成了一个特点，微软的很多产品在长期的竞争中， 靠“不犯大错”，从第三版开始，赶上并超越对手。这也是一个了不起的能力。

我的问题是在PM主导下、全体组员的讨论下完成的软件工程“不犯大错”，但似乎也陷于中规中矩，那这样一个看似没有很大创新的产品是如何能在竞争中赶超对手的呢？

通过阅读该博客，我初步认识到了PM主导和“committee"平等商议、共同设计软件的重要性，但对PM制度产生的产品竞争力仍有困惑，对微软靠“不犯大错”赶超对手也有困惑。

问题四的回答

“不犯大错”看似保守，却能在长期竞争中胜出，对于这一奇怪的现象，我结合软件工程的结对作业和团队作业有了更深的体会。

在结对作业的蛇蛇大战中，我和结对伙伴一开始思考的策略看似普通、保守，但其实很有效。在完成基本功能后，我们尝试对边界特例做出特判，但其实性能的提高并不尽如人意。我们看似“惊艳”的想法，并没有对普适情况带来很大的效益提升。

在团队作业的迭代过程中， 我们也讨论过做出“特别的”、“酷炫的”功能来提高软件的独有竞争力，但这些功能经常会出现一些奇怪的bug，尤其是在用户公测阶段。

结合实践经验，我想，“不犯大错”能胜出是因为用户容忍“不够惊艳”，但绝不能原谅“根本性错误”。看似平庸的设计背后，其实过滤掉了风险，能减少后期维护成本。并且，针对某一群体、某一特殊情况做出的设计，也并不能使大众都满意。当一个软件的规模达到一定程度，稳定可预期更是比局部惊艳更重要。

问题五

我看了这段文字：

一些人对“测试”这一工作还有很多误, 解例如下面的似是而非的观点:

测试在项目的最后进行就可以了。

这是远远不够的。当你在项目后期发现了问题，问题的根源往往是项目早期的一些决定和设计，这时候，再要对其进行修改就比较困难了。这要求测试人员从项目开始就要积极介入，从源头防止问题的发生。有人会说，我是一个小小的测试人员，项目开始的时候我能做什么？这就是小小测试人员努力的方向。

我的问题是：测试人员确实需要很强的前瞻性，才能跟进整个软件开发流程不落队，那测试人员在软件开发的前期中期能做什么准备工作呢？

我查了资料，一般软件测试人员可以提前准备脚本及场景，比如测试组负责测试脚本的开发与场景策略的设计，包含“基准场景、单接口/单功能场景、混合场景、容量测试场景、稳定性场景”等。还可以提前准备基础数据和测试数据。但我仍有疑问，这种泛泛的准备工作最后能在软件测试中发挥作用的有多少，要如何避免测试人员只能参与到最后的测验环节、而在软件开发的前中期无法融入的局面？

问题五的回答

对于功能的测试，我们团队是采用谁开发谁测试的承包责任制。在测试周统一进行测试、公测环节用户进行测试的过程中，如果出现bug或可改进的点，也是由该模块负责人来测试或完善。

一般从单元测试等最小测试集就开始实践的功能，不会出现致命性bug，也有利于后期的改进和修复。

学到的知识点

需求阶段

了解用户需求的方式是多样的，问卷有时候只是比较浅层次的了解，可以通过深度访谈不同目标人群，进一步了解用户的痛点需求。

设计阶段

在最初设计的时候就可以预留一些扩展空间，不要把功能局限住。

实现阶段

涉及和别人模块对接，积极沟通是更有效的途径。因为为了性能优化和功能扩展，队友可能会使用复杂的逻辑，核心方法的代码很难理解，此时沟通的优势会显现出来。

测试阶段

在开发阶段就可以对测试阶段写个大纲，不然可能会因为功能庞大复杂，有些小功能忘记测试。比如我们就出现过一开始对作物生长是要求季节的，但由于后来季节和其他功能都没什么关系，就忘记测试不当的季节播种农作物的情况，直到公测阶段才发现并改善原有不太合适的逻辑。

发布阶段

对于游戏来说，经济系统失衡可能会导致玩家集体抗议。因此需要监控关键数据（如玩家金币增长率），动态调整游戏数值。

维护阶段

有些bug可以形成维护模板，反复修复类似bug的过程中可以形成一套行之有效的模板方案，提高整个团队的效率。

理解和心得

以前，我对开发软件的理解似乎就是做设计-敲代码-测试，这套工作模式可能在单人或小团队开发中还算适用，但一旦进入中大型团队，如何协作对接、如何版本管理、如何解决冲突等等问题都浮现出来。在个人项目、结对编程、团队项目这一系列的开发过程中，我越发意识到一套成熟的软件工程策略是多么重要，能帮助我们少走很多弯路，少做很多重复性工作。

真的很感谢软件工程课程组老师、助教老师的帮助和答疑，更要感谢我靠谱负责的结对搭子、队友们和我一起完成了结对项目、团队项目。在这个过程中，我也逐渐摸索出一套较为高效的软件开发流程，这对我未来的学习和工作都大有帮助。