提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2021春季计算机学院软件工程(罗杰任健)
这个作业的要求在哪里	提问回顾与个人总结
与本作业对应的博客	软工第二次阅读作业
我在这个课程的目标是	提高软件开发能力
这个作业在哪个具体方面帮助我实现目标	总结

阅读提问

阅读提问博客链接：传送门

问题一：单元测试中作者自己测试最好吗，单元测试使用随机数真的没有意义吗？

不过真实情况下无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，所以往往软件测试的目的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。而大量使用专业软件测试人员会大量增加成本，所以如何有一个低成本的方法呢？我觉得就是随机数。

作者因为下次运行无法重复错误就否定随机数在单元测试中的作用。但是我觉得随机数测试程序所产生的错误数据完全可以记录下来增加到单元测试数据库中，从而保证可以复现与回归测试。

当然也有一种可能性是随机数的成本还是略高？单元测试的目的是快速的对一个基本的功能单元进行快速的基本测试。并不要求尽量找出所有bug，只需要保证基本的简单的功能正常执行即可，所以可能单元测试的目标就是简单测试所有路径，在单元测试的上层有更复杂的，集成度更高的集成测试，这一部分是需要重点测试的。

在之前提出问题的时候，我好像没用弄清楚对单元测试的真正意义，单元测试为什么要追求覆盖率？因为单元测试是在贯穿整个开发过程中，保证整个迭代过程顺利进行的一种测试，其目的并不是要追求完全覆盖所有情况，测出程序种的所有bug，所以单元测试的指标仅仅只是语句的覆盖率。基于这个前提，那么给当时的问题一个回答，首先，单元测试中使用随机数，确实没有太大意义，因为你只是需要一些能保证覆盖率的测试样例，并不是高强度高压力的测试，并且随机数由于其随机性，其实覆盖某种特殊情况的概率并不是很高，并且写随机数成本还是有的，但是最后对于没覆盖的分支还是需要一个个去手动设计样例覆盖，在之前的项目中发现，这样的效率其实不如列各种情况表，逐个覆盖。最后，单元测试确实是作者自己测试最好，以保证覆盖率为前提的情况下，当然还是最熟悉代码的作者亲自编写比较好，其他人不一定能准确判断出某没被覆盖的分支，何种情况下也会被触发，之前的项目中有过测试，自己对自己的程序写单元测试的效率明显高于对别人的大致复杂的程序构造单元测试。

问题二：结对编程是否太理想化了

结对编程看上去是个很美好的东西，两个人一起，角色不断互换，一起思考，一起解决问题。但是在实际的操作中，每个人都有自己独特的节奏，独特的风格，例如有人倾向于提前设计好整体架构乃至所有细节，而另一个人更倾向于直接去莽，在写代码的过程中不断改进，这样一起工作的话是不是会出很多问题？面对同一个问题，两人可能会有不同的解决的方式，而这两种方式并无优劣之分，只是各有特点，此时会不会因为风格差异问题导致合作出现问题？还有在"领航员"复审代码的时候，"驾驶员"会不会要不断的被打断工作节奏，不断的解释等等。

感觉确实结对编程阻碍很大，在之前的项目中，我自己就感觉到，我自己写代码很快，但让我去跟上别人的思路，我有时确实难以做到，所以说，可能结对编程对人的某些特性要求较高，所以适用的概率大概率不高。

问题三：对于“小强”的处理

个人觉得是不是对于每个bug，都应该在出现的时候分析一下，如果这个bug的修复不需要变动整个架构，是小问题，就可以记录下来之后修改，优先完成项目，如果是大问题就需要立即修改？而不是仅仅靠数目就去修bug？

很遗憾，整个课程中都没有遇到相关的真实的情况使得我对这个问题有什么新的看法,我们的整个开发过程还是比较简短，这些问题都无法暴露出来。

问题四：复审相关问题

我觉得复审者还是需要尽量调查完全之后再提出一些问题，否则是不是很容易打扰到开发者？一些小问题可能只要再浏览一遍代码就可以很容易的明白，如果因为这些小事就频繁打扰开发者，会不会影响开发者的工作效率？

经历过团队项目之后，我对这个问题有了新的看法，首先，复审者并不是一个专门的复审者，实际上大家都会兼任这个职位，所以每个人的精力都是有限的，如果让复审者完全弄清楚另一个写的可能跟自己关系不是特别大的代码的成本是很高的，所以即使复审者问出一些只要再调查调查就能弄清楚的问题，代码的作者也是只需要花费很少的成本就能解决的，毕竟代码都是他自己写的。所以基于成本考虑，复审者有权提出很多看似吹毛求疵的问题，复审者不必亲自调查每一件事，开发者有义务给出详尽的回答。关于所谓频繁打扰的问题，并不存在的，问题可以全都写在merge req下面，开发者空闲时去一一解答即可，开发者大多数情况下不太需要立即做出回应，只要其有那个精力去看看merge req，就不算被打断工作。

问题五：创新相关

小公司确实能将创新带到市场，但我觉得创新的主体更可能是大公司，并且小公司很难通过创新去挑战成熟企业的霸主地位。大公司体量大家业也大，我觉得比较容易分出一小部分资源做出创新的尝试。并且新的市场如果有小的公司先去试水，发现效果不错，大公司也很容易通过其庞大的资源以及市场碾压小公司，从而将小公司的创新变成自己的“创新”。

事实上大公司并不是一定能碾压先行创新的小公司的，先行者的地位以及收割的首批忠实用户并不是那么容易被兼并的，大公司只要任由做出创新的小公司发展，后期大公司同样进入这一领域，实际上的竞争力并不明显高于小公司。

二、是否产生了新的问题？如果有，请提出

无

三、在实践中学习知识点

需求

NABCD，看似挺无聊，实际上这是贯穿产品设计修改始终的指导思想，提前设计好整个产品的脉络与思路，会对之后关于产品的相关功能的调整带来非常积极的效果，至少使得不会盲目。

设计

功能规格说明书相当于全组对所有功能的理解，用于保证所有同学在单独开发的时候不会出现功能理解方面的问题。

实现

实现过程中时刻查看文档的更新，对自己负责部分的内容有修改立即update，必要时发广播，信息不同步会带来非常严重的后果。

测试

单元测试随着开发的过程中编写，如果全都拖到最后编写，看似总时间一样，但其实效率天差地别。

发布

及早发布，以及平台十分重要。

维护

设计有效的信息反馈和回馈渠道非常重要。

理解与心得

本学期我们花费了大量的时间与精力投入到软工项目中，也是收获颇丰。之前我们对写软件这件事情基本没当作一项真正的工程来看待，在实践中，我们一些不成熟的想法也会被我们一一尝试与印证，收获了大量的经验。

十分感谢我在团队项目中的队友们，大家通力协作，才将这一项目顺利完成，虽然最后的排名并不是很高，但最终的用户量我们已经相当满意。