提问回顾与个人总结

请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。

问题1 为什么不能让别人代替你做单元测试？

问：如果我很忙，能不能让别人代劳做单元测试？
答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。在一 些极限编程的方法中，是可以考虑让别人来做单元测试的，但是，程序的作者还是要对单元测试负责。最好是在设计的时候就写好单元测试，这样单元测试就能 体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义。单元测试过后，机器状态保持不变。这样就可以不断地运行单元测试， 如果单元测试创建了临时的文件或目录，应该在Teardown阶段删掉。如果单元测试在数据库中创建或修改了记录，那么也许要删除或恢复这些记录，或者每一个单元测试使用一个新的数据库，这样可以保证单元测试不受以前单元测试实例的干扰。单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。快，才能保证效率。因为一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中可以分类，如数据库层次、网络通信层次、客户逻辑层次和用户界面层次，可以分类运行测试，比如只修改了“用户界面”的代码，则只需运行“用户界面”的单元测试。单元测试应该产生可重复、一致的结果。如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。

上面是书中2.1节的问题和解答，在提这个问题的时候，我似乎对书中的解答有一些误解，书中并没有说单元测试必须要由程序的作者来完成，而是程序的作者最好对单元测试负责，而且最好在设计的时候就写好单元测试。我当时仅仅是提出其他人做测试可以从一些意想不到的角度发现bug，但经过仔细思考，程序的作者应该更了解代码的功能，因此能测试的更加全面，而且基于对自己代码的了解，工作效率也会比其他人高很多，当然，后续与专门的测试人员相结合能够进一步保证代码的正确性。

问题2 关于软件工程师的职业等级

在3.2节职业成长部分给软件工程师划分了等级

我对公司里面如何考察一个软件工程师的能力存在疑问，能否真正的体现出一个软件工程师的水平，这样的衡量方法真的有效吗？

事实上在当时助教提问时我就给出了相应的答案，我觉得软件工程师的能力很难量化度量，一个码了10w行代码的软件工程师未必比一个码了8w行代码的软件工程师强，对于其他方面，如算法能力，工程能力，也不能一票说明一个软件工程师的能力。但是我认为码了10w行代码的人平均水平要高于码了8w行代码的人，同样地，做了10个项目的人平均水平要强于做了8个项目的人。因此，可以综合这些个人能力的体现来区分较为初级的软件工程师。对于高级的软件工程师，假设两个人一个码了100w行一个码了80w行，可能代码量的增益已经不是很大，转而要多考虑领导力，团队协作能力以及在团队中担当的角色等在团队工作中发挥重要作用的能力。根据综合水平来度量软件工程师的水平。

但这个问题依然是一个非常难的问题，需要结合实际情况来做出判断。

问题3 团队工作为何是从一窝蜂模式开始？如何避免主治医师模式的形成？

读到5.2节时，书中以足球队举例说明，团队从一开始的无序到相对有序，然后类比到软件团队模式，指出软件团队一开始也是混沌的一窝蜂模式，这里我产生了疑问，若经过前期细致的分工能否避免一窝蜂的开始，若能避免，书中所举例子还恰当吗？
体育团队从一窝蜂抢球演变到有明确的分工、阵型、战术的团队，需要时间。类似地，软件团队的模式，最初是混沌的一窝蜂形式：一群人开始写代码，希望能写出好软件。随着团队的成熟和环境的变化，团队模式会演变成下面几种模式之一。

实践出真知，事实上，在我团队工作的过程中，并没有从一窝蜂开始，在第一次开会之后每个人就确定下了分工，经过设计阶段的构思在后续过程中开展的很顺利，每个人有明确的分工，也自然而然的避免了主治医师模式的形成。

问题4 牺牲质量去换取用户体验，用户会不会接受？

读到12.1节的时候，我看到书中举了这样一个例子

GE公司的总裁杰克·韦尔奇讲过这个故事：20世纪90年代，韦尔奇注意到核磁共 振机的通道特别狭窄，在长达几十分钟的检查过程中，病人常常有得了幽闭恐惧症的感觉。韦尔奇做过类似的检查，深有体会。他问专家，能不能把通道做得宽 一些？专家说那样会降低扫描成像的质量。他又问，对于那些不需要太高精度的检查，能否牺牲一些成像质量，换取用户的良好体验呢？专家说，他们会考虑 的……然后就没有下文了。不久，竞争对手推出了宽通道的扫描设备，并夺取了大量的市场份额。GE被动迎战，花了两年时间才赶上对方。

我当时提出的问题是“这个例子一方面是说明了用户体验的重要性，但同时似乎肯定了用户体验>质量，但质量的下降有时也会导致用户体验的下降，我认为应该在两者之间找一个平衡点，兼顾质量和用户体验，而不是片面的追求用户体验来获得利益。”现在我对这个问题也有了肯定的答案，GE的对手就是找到了这样一个平衡点，在一些不太需要高精度的检测上推出了高精度产品，这在软件开发的过程中体现了这样一个道理————“杀鸡焉用牛刀”，我们要合理地评估用户的需求，做出切合用户需求的产品，在这个例子里，用户除了成像的质量，还需要体检过程中的良好体验，只有精确把握用户的需求才能打造出成功的产品。

是否原来的问题还不明白？如果有，请分析。

技术的创新是关键？

读到16章创新部分，有以小节讲技术的创新是关键，我觉得不见得，虽然这些年创新发展很块，但是我觉得只创新不够，技术的成熟也起了很大作用，以中国基础建设为例，国外的技术不一定比我们差，但我们做到了技术的普及，从而发展的很好。

这个问题在我经过了这门课的学习之后并没有得到解决，我们的产品虽然有创新的成分，但市面上也早已出现过相关的产品，因此创新在我这次软件工程课上得到的体现不是非常明显，而且上升不到技术的层面，最多是创意，对于我们这样6，7人的本科生小团队似乎离技术的创新还有些遥远，因此我依然不明白对技术的创新是关键该如何理解。

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

团队贡献分配问题

在我们的团队工作中，有非常重要的一项任务是团队贡献分的分配，在团队任务之初我们都制定了贡献分分配规则，按理说规则由大家制定，每个人都应该对这个表示赞同，但如果当初这个规则的制定没有考虑到一些内容，导致下面的情况：

• 有的人做的一些工作无法被看见，虽然当下接受了这个结果，但在后续的工作中心中有了芥蒂，导致破罐子破摔现象的出现，如何避免这样问题的出现呢？
• 不同部门之间的贡献该如何衡量呢，部门之间应该采取绝对的平均嘛，如果不应该，对一个部门的重视会不会导致另一个部门的不满呢？

这些问题非常的现实，也非常的重要，但我并想不出合适的办法。

团队中意见不统一问题

在alpha阶段，我遇到这样的问题，我担任前端开发，在实际开发过程中，经常会出现与PM意见冲突的情况，比如一些功能，我按照我理解的方式实现，能够支持我们想要的功能，但PM却希望我改用另一套方案，认为这样能改善用户体验，而在我看来这个需求在向某一类有特定使用习惯的人倾斜，这仅仅是团队意见相左时的一个个例，在这样冲突的条件下，有没有什么有效的方法能避免矛盾的激化或者是判断谁的意见更合理呢？应该完全听PM的意见吗？

软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” – 在实践中学习知识点。

请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点即可。

• 需求阶段
  • 学会了需求分析方法，使用NABCD的框架来分析需求非常的有用，一定要根据目标用户和场景来确认自己的需求，明确了需求，才能有开发的方向。在beta阶段，我们在进行需求选择时就优先考虑了用户呼声高等亟待实现的功能。
• 设计阶段
  • 设计时要尽量避免功能之间太过直接的先后关系，精心设计来保证每个人每一阶段都有事情可做，在alpha阶段我们就因为两个人开发的功能相互需要对方的支持而形成忙等的情况。
  • 在团队工作中，无论是alpha阶段我所在的拒绝VS组还是beta阶段我所在的顶级理解组，都有描述清晰的接口定义，以及使用说明，这一定程度上能反映出整个项目的功能设计上是非常清晰的，这一点十分重要，模棱两可的设计会引发非常多的问题。
• 实现阶段
  • 我在两个阶段都担任的是前端开发，alpha阶段是web端应用，beta阶段是安卓端应用，但两端开发中都面临的一个共同的问题是组件的选择，对于同一个功能，我们可以有非常多不同的实现，这些实现方法不总是一样好或一样差，我们需要前期调研并大量实践来得出更适合自己的一个。在alpha阶段我们在菜单栏实现上就选择了不那么合适的组件，经过大量探索和尝试也没能解决问题，后来听说beta阶段他们通过使用其他组件解决了这一问题。
  • 软工的几个项目是我第一次接触前后端分离的项目，我终于体会到了之前面向对象老师常说的高内聚、低耦合中的意味，前后端之间、前端的不同功能之间，仅仅通过接口进行沟通，无需关心其他功能是如何实现的，在alpha阶段已经体会到了其中的方便，但还不够明显，在经过转会之后，我通过接口文档和规格功能说明书以及项目管理等文档，快速了解了整个项目的工作流，让我在较短的时间内就能上手进行开发。
• 测试阶段
  • 测试在软件功能中是必不可少的，无论是在开发过程中的单元测试还是在每次提交前的回归测试，都能发现大量的问题，不断的测试能保证后续不出现更严重的问题。
  • 让用户使用内测版本非常重要（部分用户参与测试），因为我们的产品最终是要交给用户使用的，一些用户体验型的bug只有在用户使用时才能暴出来。
• 发布阶段
  • 软件工程不仅仅是要写代码、写程序，而是要开发一款“好”的软件，得用户说好才行，只有发布了产品，用户才有渠道了解接触我们的软件，在beta阶段我所在的组，为产品制作了精美的海报，让我感受到了软件工程的魅力，我们是真的在做软件而不仅仅是写代码，缺少了发布阶段，怎么能称之为软件工程呢？
• 维护阶段
  • 在软件发布出去之后，用户使用过程中可能遇到bug，在用户反馈后我们需要及时修复bug，我们alpha阶段就设置了反馈问卷，beta阶段新增的功能之一就是用户反馈，这对不断改进完善项目是非常重要的。

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

个人项目

在个人项目时，我完成的比较仓猝，那几天时间上正好和美赛冲突，在我完成美赛的提交后，个人项目离最后的截止时间已经不足12小时，加上还要写博客，用来完成代码的时间就更加短，虽然最终完成了项目，却因为在生成可执行文件时使用了debug模式而没有使用release模式导致运行速度大打折扣，扣了不少分数。从中吸取到了教训，任何成功的项目都必须投入与项目难度相匹配的时间，并且要熟悉自己所使用的编辑器之类的工具，磨刀不误砍柴工。

结对项目

在结对项目时，有了相对充足的时间，加上我和队友本身相互之间认识，沟通起来少了不少障碍，比较充分地体验了结对编程的特点。遗憾的是，受疫情的影响，我们只能采用线上的形式，虽然我们使用了Visual Studio的share edit功能，但是由于网络等原因稳定性较差，因为是在我个人作业的基础上进行拓展，所以我的队友时常面临掉线的问题，但我们仍然能快速的做代码复审，在对方完成代码后第一时间发现其中的问题和不足。后来项目推进一段时间后，我继续完善主要功能，队友转向去做松耦合的对接，效率大大提高，因为沟通及时，整个任务推进的比较顺利，从中学到了对方编程中的优点，也体会了结对编程这种模式下两人轮流做“导航员”能够起到事半功倍的效果。

团队项目

整个软工课程团队项目时间跨度最大，因此团队项目也是我学到和体会到东西最多的一个阶段。

首先是强制转会制度，在alpha阶段结束后，每个组都面临的问题就是要转入和转出成员，一个团队用了一个月的时间去不断磨合，从陌生到相互熟悉，并且共同开发出一款团队中每个成员都较为了解的项目，忽然就要有成员离开这个团队，无论是自己离开还是团队中的其他成员离开，心里都不是滋味，最后通过抽签的方式将我选了出来，心中百感交集，一方面因为我对团队中的成员已经产生了感情，另一方面融入一个新的团队需要学习大量新的知识，担心自己不能很好融入团队。当时我心中很不是滋味，认为转会会对1/6的同学（我们这样因为各种原因转会的同学）产生较大影响，而对另外5/6的同学产生的影响较小，认为课程制度对这少部分同学不友好，但当我真正经历了beta阶段后，我认为转会给这门课程增加了别样的趣味，转会的同学学到的知识面更广，能交到更多朋友，虽然是一次不小的挑战，但也是一次不错的经历。

其次，在团队项目中我真正感受到了软件工程几个字的含义，之前上的许多专业课都是在码代码，而不是做软件，一个优秀的软件，除了代码，还需要代码规范、项目管理、合理规划、充分调研、发布推广等，需求/设计/实现/测试/发布/维护6个阶段一个也不能少，感谢软件工程这样一门课程，让我在实践中学习，并在辗转两个团队之后获得了慢慢的成就感和获得感，再此感谢两个团队的所有成员给予我的帮助以及老师助教们一个学期的辛苦付出。