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

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13465
我在这个课程的目标是	学习软件工程的基本方法，提高工程化能力
这个作业在哪个具体方面帮助我实现目标	总结反思，为以后的工程化开发积累经验教训

对曾经问题的解答

提问博客链接

问题1

问题描述：

诚然，由程序的作者来编写单元测试是非常有必要的，但为什么不能由其它人员也负责编写一定数量的单元测试？

在具体项目实践中，我作为前端和算法开发人员，就出现过“开发人员测试许久都未出现bug，外部人员稍加测试便发现了bug”的情况。

因此，我仍然坚持我在提问题博客中的看法。我认为让部分只对项目代码有初步了解的“外部人员”编写一定数目的单元测试是非常有必要的。

问题2

问题描述：

在软件工程的实战中，如何把握与团队与顾客交流的程度？或者说，是否在某些条件下（比如商业利润过于庞大的情况下），可以拒绝与用户合作？

在我自己经过一个学期的思考后，我认为这个问题主要取决于我们软件的目标是什么。如果我们将用户使用舒适性、用户口碑放在首位的话，那必然要积极与用户进行合作；如果是将商业利润放在首位的话，也许就可以适当用用户体验去交换一些商业利润。

问题3

问题描述：

我认为，对产品的全部投资集中在”最基本功能“也是一个可行的道路，也有可能带来成功。

在经过一个学期的思考后，我仍然坚持我最初的看法。一个软件，只要它能够做好它最基本的功能，就是一个好软件。浏览器可以只是浏览器，而不必是网盘启动器、AI搜索启动器；购物软件可以只是购物软件，而不是理财软件、借贷软件；视频门户软件可以只是视频门户软件，而不必是购物软件、社交软件……

问题4

问题描述：

作为一名PM（Program Manager），却不具备使开发人员按照规格说明书（spec）进行开发的强制力，这是否会造成效率低下？

在经过具体的项目实践后，我仍然坚持我最初的想法：项目PM必须要具备使开发人员按照规矩进行开发的强制力，这是项目能够平稳正常进行下去的关键因素之一。

我在项目开发过程中，PM就缺乏使成员执行任务的强制力，导致部分组员在整个项目开发过程中都非常懈怠，严重影响了项目进展以及最终成果。

问题5

问题描述：

教材第十五章“软件测试”描述了许多Bug以及其可能的修复优先级低的问题，但我在实际软件使用过程中仍然有一些bug体验显然不属于教材描述的范围内，我想知道这些bug直到现在仍然不修复的原因。

这个问题我至今仍然想不明白。我至今仍然对“微信”这个软件这许多匪夷所思的使用体验上的bug抱有极大的意见，我认为这个破软件完全是迎合中老年人不愿意记账号，中老年人又反过来要求年轻人迎合他们使用微信的需求，才流行起来的。就聊天体验而言微信被QQ甩了好几条街。

请问你们在项目的需求/设计/实现/测试/发布/维护阶段中都学到了什么“知识点”

需求阶段

在做需求阶段的调研时，不仅仅要考虑“用户需要什么”，我们还要考虑“以我们的能力能做什么”。我们组最开始打算制作一款多人联机卡牌游戏。但我们在经过实际的调研之后，认为这个任务所需的任务量超过了我们组成员的实际能力（事实上，我十分庆幸当初进行了换题，要不然凭我们组实际开发中的情况，我完全不认为软件可以正常发布）

我们不能仅凭一腔热血，就选择在两周的开发时间内显然无法发布“最小可用集”的任务。

设计阶段

在进行设计规划的时候，不能盲目地“画大饼”，不然可能无法在规定时间内完成任务。即使完成，也不能保持一个合理的质量。

在我们组的具体实践中，我们在最开始盲目地提出了许多不切实际的需求。但在实际的执行中，我们组内分工严重不合理，外加有部分组员比较懈怠，导致实际项目进行与预期进展严重不符，最后只能开发人员集体熬夜，最后做出了的成品的效果也不甚理想。

实践阶段

在实践过程中，不能仅仅只干自己的活，还要时时刻刻了解其它组员干的活——毕竟在开会中别的组员可能说谎。如果只是埋头干自己的活，而不去push别人的话，就可能会因为部分人的懈怠导致整个项目的进展滞后。

在我们组的具体实践中，有位同学花了整整三周完成了一个完全不能使用的登录功能——在这三周内，他一直在努力宣扬登录有多么多么难做，他的行为严重拖延了项目进度。在后续debug过程中，我发现了他的登录无法使用，便将他的登录功能完全重写了，而这次那个所谓“多么多么难”的登录其实只需要至多四个小时。

测试阶段

在测试过程中，我们不能总是寄希望于测试人员发现bug——尽管他们确实能发现部分bug，但是由于他们不了解代码运行的内在逻辑，所以找出bug的效率并不理想。测试bug的主要责任应该主要落在开发人员的头上。

在我们组的具体实践中，在Alpha阶段我作为开发人员，我只做了简单的功能测试，然后就将测试bug的任务甩给了测试人员。测试人员并未发现Bug，这使得我一度为自己“写出了完美的代码”而沾沾自喜。

然而当项目进入Beta阶段后，我才发现我在Alpha遗留下的bug有多么多，而那些bug实际上只需要我稍微填写几个单元测试就能发现。这些bug使得我们在Beta阶段伊始浪费了比较多的时间。

发布阶段

在发布过程中，要积极倾听用户反馈，修改掉那些影响用户体验的bug。

在我们组的具体实践中，我们将小程序发布给身边的亲朋好友进行测试后，他们反馈了一些UI跳转逻辑上的Bug。作为熟悉小程序整体功能的开发人员，我们很难认识到这些Bug，但这些bug对于不太了解小程序的用户而言却是比较明显的。

维护阶段

在维护过程中，除了程序本身的bug、使用体验，还要综合考虑其它因素。

在我们组的具体实践中，我们组在维护阶段出现了多次服务器的崩溃（因为我们组使用的服务器比较廉价），但我们过于注重程序上的bug，而常常忽视服务器上的问题。这给用户带来了比较严重的负面体验。后续，我们设置了服务器崩溃自动重启以及重启自动执行后端脚本解决了这个问题。

结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得

纵观整个软工项目流程，我最大的体会就是“选择大于努力”。我不得不承认，软工这门课程最开始的团队选择将直接决定最终的成品效果。

对于个人项目，这点尚不明显。

在结对编程中，我和舍友ykq组成结对——我们彼此对对方的作业态度和团队责任都知根知底。我们一起花了一个下午，一个上午以及一个晚上完成了结对作业。在这个过程中我们合理安排作业中担任“领航员”和“驾驶员”的时间比例，最终在规定时间内顺利完成了作业。在这个过程中，我们我们彼此之间有过关于贪吃蛇策略的争论，但最终我们对此次结对作业的体验均给出了正面评价——因为我们两人都全程对结对项目抱有较高的热情。尽管过程可能比较劳累，但最终看到自己的蛇在擂台上“游龙”，便觉得一切都值得了。

但在团队项目中，我丝毫感受不到结对项目中的热情——我感受到的只有折磨。为了这个破团队项目，我熬了一天夜，失眠了至少三天，个人投入了至少五十小时，甚至部分放弃了计算机网络考试的复习，最终得到的，只有一个中规中矩的成果。我在团队项目中我丝毫感受不到“团队感”。我感受到的，只有我在Alpha阶段结束后受不了庞大工作量，请求其它活早已干完的组员支援时那冰冷的沉默；只有一次又一次哀求其它组员“高抬贵手”推进软工项目，却最终失败的焦躁；只有那次次软工开会，都顶多只有四个人按时到场的无奈。

看到我的舍友ykq他们组比较严格按照软工课程要求的流程进行开发，组内每个人各司其职的团队氛围，我是羡慕非凡。我常常会想，如果我当时选择的是别的团队，遇到了一群对软件开发富有热情的队友，我的软工体验是否会截然不同。

此外，通过四个月的软工体验，我还明白了沟通的重要性。有的时候一味的埋头苦干，而不去和队友进行沟通，可能会导致做无用功。与上下游做充分的交流，才能事半功倍，产出高质量的程序。

最后，我要感谢我的队友zyj和lx，感谢他们陪我走完了整个软工项目，感谢他们不厌其烦地和我一起修复软件的bug。如果没有他们，这个软工项目不可能完成。