终章——软工提问回顾

问题	内容
这个作业属于哪个课程	2021春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里	提问回顾与个人总结
我在这个课程的目标是	提高个人开发水平以及团队合作意识
这个作业在哪个具体方面帮助我实现目标	回顾开学初自己的疑惑并总结课程收获

一、提问回顾

在学期初阅读《构建之法》时，我写了一篇读书小结，其中提到了几个问题，经过一个学期的学习，我对于结对编程和团队开发都有了更深入的理解和体会，这里对于当初的问题尝试做出解答：

1、结对编程是否有大规模应用的可能？

在结对编程中，任何一段代码都至少被两双眼睛看过，被两个脑袋思考过。代码被不断地复审，这样可以避免牛仔式的编程。（《构建之法》4.5.2）

本学期的结对编程相信每一位同学都有很深的感悟，我个人当然也不例外，详见个人结对总结。虽然个人感觉结对编程的效果比自己实际预想的好一些，但是还是在与队友磨合的过程中花费了很长时间，最后由于作业要求修改得较多和心态的原因，作业完成得也不是很满意。在这篇博客下方的评论中有提到 "结对编程的应用性" ，有说到 "结对编程是一种很好的合作方式，比如新手程序员工作中遇到问题，通过和资深程序员结对，就可以通过结对解决问题，这样不仅能解决问题，还能学习到解决问题的方法。"但事实上这种结对方式在公司应该是很难遇见的吧。指导和相互交流当然是必不可少的，但是这种 "一对一" 过于极端式的指导在以讲求效益的公司里应该是不存在的。

所以，我现在的回答是：在现有情况下没有大规模应用的可能。除非在一些意外情况，比如需要临时紧急开发出一款软件或者一套系统等，有可能两人一起负责一个模块。正如评论中所说：结对编程只是一种手段。我并不否认结对编程的好处和有效性，但是我们同样需要联系实际，为了达到目标而是用结对编程这种手段的代价有点过高，大规模应用有待商榷。

2、单元测试是否一定要程序员自己编写？

单元测试必须由最熟悉代码的人（程序的作者）来写。（《构建之法》2.1.2）

3、测试人员的要求

阿超：开发人员的代码没写好，可以依赖于测试人员来发现问题。但是如果测试人员的代码没写好，我们依赖谁来测试和改错呢？这就要求我们测试人员的代码质量特别高，因为测试人员是最后一道防线，如果我们的代码和测试工作有漏洞，那么Bug就会跑到用户那里去。（《构建之法》13.3.1）

二三两个问题都是关于测试的，这里一并回答吧。

• 就第二个问题来说，同样如上述结对编程中所言，测试也是一种手段，无论是熟悉代码的还是不熟悉代码的，只要能达到让软件更加高质高量的目的都是没有问题的。但就我个人在结对编程中的实践来说，我还是更倾向于个人写个人的单元测试。实际上做单元测试时并没有出现思维惯性的问题，相反如果写他人模块的单元测试，我阅读他人代码逻辑并考虑边界条件的时间比个人写单元测试的时间要长很多，效率也比较低下，我和队友也尝试过为对方写单元测试，但是结果不太理想，最终还是决定自己为自己的模块写单元测试。当然如果在自己时间比较紧张或者想要再多增强自己程序的鲁棒性的情况下，让他人为自己写一些测试数据也未尝不可。
• 就第三个问题来说，个人觉得测试人员还是需要有一些开发经验的。“连开发语言都没有接触过的队员”最好还是先学习开发语言，当然也可以学写测试，但是最好还是不要直接接触工程开发的任何环节，否则很容易出现纰漏。测试可以说是开发后期最重要的一环，是检验软件产品是否合格的重要依据，硬性标准可以参照某些大厂关于测试人员的招聘公告。总而言之，测试很重要，测试人员的要求也需要严把关。

4、最成功的创新是在拿手领域之外发现的？

我们不就是为了成为某个领域的专家，才来上学，拿学位，希望拿到学位之后成为专家，然后再开始这个领域的创新？但是统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外发现的。（《构建之法》16.1.5）

相对于之前我提到的 "拿手领域" 的定义，在回答这个问题前我又产生了一个新思路。如果这里的创新者的样本数据是足够大且真实可靠的，可以看到超过半数的创新者都认为自己最成功的创新是在拿手领域之外，这其实有很多地方不太合理，比如什么才能算得上创新者呢？发明家？教授？每年有大量研究人员在自己行业领域做出了大大小小的成就，这能算创新吗？这个问题当初关注的点以及咬文嚼字现在看来可能并没有太大意义，作者可能只是希望多关注自身领域之外的其他知识，说不定会有意想不到的收获。

但是现实中其实没有这么多意外，在自己的领域勤勤恳恳几十年说不定都没有做出巨大的创新成果，又何况是一个从未涉足的领域呢？所以我的回答是：会有这样的可能性，但是并不常见。

5、关于用户体验的惯性

用户在网上提交信息，通常会看到两个相邻的按钮，【提交】【取消】，这样简单的设计仍有很多可以改进的地方，例如有下面的建议。（《构建之法》12.1.5）

这其实是一个用户体验和开发者导向的问题。就像我们在卸载软件的时候经常会有弹窗，最显眼的那个永远是 我再想想 ，而 继续卸载 则被放到了一个不显眼的位置，有的时候可能还被默认保存一些记录，需要手动取消勾选。

作为开发者当然是希望使用自己软件的用户越多越好，但是在这样一些边界区域（比如卸载弹窗或者关闭按钮等），倒不至于上升到行业规范，个人感觉对于一些无关紧要的部分比如按钮的位置啥的，衡量好用户体验和所带来的商业效益就行。但是比如我们经常遇到不授权获取通讯录以及一些个人隐私信息就不允许使用软件的设置就需要进行整治。用户数据的安全性永远是放在首位的，用户体验则要根据开发实力和公司自己的理念做相对应的调整。

6、创新者困境

如果公司不断满足已有用户需求，则产品在趋于饱和的市场缓慢发展，在产品的生命周期结束后，不免会被新的颠覆性创新淘汰；如果公司主动寻找颠覆性创新，则遭到公司内部流程、价值观和文化的排斥（《构建之法》16.1.7）

这个问题的回答我还是比较同意当初自己的答案的。

成功的企业之所以成功就是因为当年的颠覆性创新，当市场成熟后，成功的公司一定会主动寻找新的创新点，而不是坐以待毙。更何况成熟的公司已经具有雄厚的资金和人脉，在创新产品后有更便捷的推广渠道，也能承受相关的一些风险。而一些小公司虽然可能带有颠覆性创新，但是在产品推广的第一步可能就困难重重，可能会遭受行业垄断等种种压力，一旦某个环节出现差错可能整个公司都灰飞烟灭。我们现在看到一些成功的小公司都是在层层筛选下运气和机遇都恰到好处的公司，那些创业失败的案例我们又能接触到多少呢？所以大企业的创新可能性是远远高于小企业的。

7、关于极限编程

所谓极限编程，就是把一些认为重要和有效的做法发挥到极致。（《构建之法》6.4.1）

本学期关于极限编程有两种实践方式：结对编程和团队开发。

• 在结对编程阶段我们体验了频繁修改需求的 “极限编程”，虽然编程体验不是太友好，但是也感受到了之后顾客需求变动的常态性。虽然没有从测试开始写程序，但是最后的测试也是基本覆盖了全部功能，也在测试中发现了不少问题，这也进一步体现了测试的重要性。关于代码复审我在之前的结对总结中也有类似的感悟，这里就不再赘述。
• 在团队开发阶段，由于我们对于测试的疏忽，并没有使用测试驱动开发的模式，导致最后测试没能发挥应有的作用，这也是我们在团队开发中得到的深刻教训，TDD模式的确可以帮助提高产品质量，并且需要从开发开始就严格落实。关于团队开发中提高用户体验是最重要的目标我也深有感触，在我们组的团队博客中可以看到对于比赛系统大家进行了深入的讨论和频繁的改动，即使开发进度很赶还是希望能带给用户最好的使用体验。

总之，通过这两种实践方式本人对于极限编程有了更加深入的认识和体会，相信这些经历和体验也会给我之后的学习和工作带来深远的影响。

新的问题

在团队开发过程中会出现有些同学时间过紧无法腾出时间开发的情况，虽然理想状态下是大家每天保持联系，即使再忙也适当分配一些任务，保持工程在不断推进，但是事实上却很难做到。那么如何才能让每个队员都有很高的积极性参与开发或者愿意牺牲自己的时间投身团队工作呢？

二、在实践中学习

需求

• 使用NABCD分析法是十分有效的

• 一定要全方位了解用户需求，无论是功能还是外观都需要积极征求用户意见。虽然我们做的小程序看起来功能比较单一，只是一款针对特定科目的做题软件，但是实际上在Alpha阶段的用户反馈中我们收到了很多用户提出的宝贵意见，而且很多是比较共性的意见，所以这也体现了我们需求分析的不足。在开发前只有充分考虑用户意见才能真正开发出用户满意的产品。

设计

就像上面图中所说，如果计划没有变化快，就别做详细的设计，做频繁的增量开发、重构和频繁地发布。举例来说，由于本组没有特定的美工，所以都是前端同学先做出demo然后在此基础上进行调整，所以一开始也并没有做详细的界面设计，最终效果虽然比较简约但是还是比较符合用户预期的，同时对于项目进度的推进也是很有帮助。

实现

关于实现部分比较深的感悟就是像一些接口文档等对于开发比较重要的文档应该采取迭代而不是新开，同时大家也要养成勤看文档的习惯，避免出现接口以及功能等发生修改但一些同学还不知情的情况，这对于开发过程时极其不利的，也会对团队的心态造成一定影响。

测试

关于测试阶段，提前设置一套完整的测试计划是极其有必要的，除了单元测试、压力测试等比较常见的测试方式外，还应当对一些特殊行为进行测试。比如本次Beta阶段发布时出现了微信名中含有表情包就无法正常使用的情况，这在我们内部自测时没有发现是因为团队内部成员的微信名中都没有表情包，也说明了测试各种边界条件的重要性。

发布

首先在发布之前需要做充分的测试，让软件满足出口条件，当然这一部分在测试中其实应该已经做得比较完善了，其次比较重要的就是宣传工作，这里主要分为两个部分，分别是宣传对象和宣传形式，而我们团队作业的自身定位其实就已经决定了我们的宣传对象就是北航有这两门考试的同学，所以接下来就是宣传形式的确定，大家将宣传文案和收集反馈的渠道均发送到有备考需要的课程群以及书院群中，同时在自己的微信朋友圈也进行宣传，扩大影响力。

维护

在软件发布后要保持收集反馈渠道的畅通，如果想要长期维护软件当然需要定期查看反馈，对于一些功能定时做更新。也要多留意竞品的动态，考虑如何让自己的产品时刻拥有竞争力，当然人员、资金、设备等资源也是不可或缺的条件。

三、个人总结

本学期的软工课终于在最后一篇博客中落下帷幕了~

首先简要总结一下本学期的课程内容吧，首先是前期的几篇调研博客作业，让我对软件工程相关概念以及一些工程方法有了更深入的认识，对于例如用户体验等的理解在之后的团队作业中也起到了很大作用。之后是实践部分，包括结对编程和团队开发，不仅体会到了合作的重要性，更感受到了及时沟通交流以及互相帮助的意义所在。几万加的文字输出以及和队友们不断探讨软件功能和用户体验的过程虽然有时会让人感到比较痛苦，但是得到的收获却是巨大的。之前的课程基本上都是单打独斗，很少有与他人如此长时间近距离的合作，但是本课程却让我第一次有了工程的感受。开始备受争议的每日例会和会后总结却在后来成了大家相互联系的重要方式，更何况即使是这样频繁地沟通都会出现小差错，每周一次会议的后果也就可想而知了。结对中和队友的思维碰撞以及相互交流不仅提高了我阅读代码的能力，更提高了我对于代码规范性的认识，这和自己之前随心所欲写代码是完全不一样的体验，也相信我在之后真正的工程实践中会有更加深刻的认识。

大家都曾经是各门课程中的胜利者，在出现与课程相冲突的意见时也会理所当然认为自己是对的，但是后来实践证明，课程的安排大部分是很有效的，我们也的确从中收获了与其他课程不一样的东西。最后衷心感谢各位老师助教对于课程的倾情奉献，更感谢和我结对的小伙伴以及团队开发的队友们，也祝愿软件工程能够带给后来的同学们更好的课程体验~