提问回顾与个人总结

问题回顾

问题链接：(35条消息) 《构建之法》阅读与提问_hua0x522的博客-CSDN博客

问题1

对于一些特殊的项目，它的模块难以进行单元测试，这种情况有没有什么其他方式能够减少错误？

在结对编程的作业中，我们为每一个功能进行了覆盖率很高的单元测试，保证功能的正确性，但是也相应地投入了很多精力。在团队项目开发中，我作为项目的前端开发，经常需要高效地完成开发需求，并且应对随时可能出现的新需求。这使得我没有时间去编写单元测试，而且由于前端涉及的东西比较广，很多都和UI、底层框架有关系，难以进行形式化的定义，因此难以进行单元测试。

遗留的问题：是否有对前端行为较好的单元测试方法论？

问题2

关于敏捷开发我有一些问题。

首先，敏捷开发的每个小阶段被称为Sprint，是橄榄球比赛中冲刺的意思，形象地体现了敏捷开发周期短的特点。但是正如同运动员是没法一直冲刺的，如果让敏捷开发成为常态，这是否会导致开发人员的工作量大幅增加、工作压力增大？如果一个公司从瀑布模型转型到敏捷开发，如何保证不会出现更严重的加班现象和软件质量的下滑呢？

其次，我不是很理解每日立会为什么要站着开？经过检索，我发现是为了让会议简短，不浪费时间。但这样做不免像书中提到的敏捷原教旨主义做派。我之前在一个10人以上的队伍中参与开发工作，每次开会最浪费时间的地方在于：产品经理或者高阶开发在和某个部分部分负责人商讨的时候，其他的开发人员往往是闲置的，因为他们并不需要知道这些细节。也许，把会议的范围缩小，让Scrum Master跟负责不同部分的人员同步，是更好的办法。

对于第一部分，在团队项目的开发阶段大家确实都很累（也有相当大的原因是由于其他课程的压力），但是由于前期需求规划做得比较明确，所以大家对于任务量都有较为清晰的认知，能够合理安排自己的时间。在两个开发阶段中，虽然我们很累，但是从来没出现严重的进度延误，更没有出现大家一起熬夜坐牢调试的情况。

对于第二部分，我认为敏捷的原教旨主义大可不必。只要大家理解敏捷开发的宗旨，会议形式等等没有必要计较。对于会议规模，我们也采用的是全体组会和小范围讨论会结合的方式，这样的交流方式很灵活，能够满足敏捷开发的要求。

问题3

书中第5.2节介绍了很多团队开发模式。其中有一些模式听起来很不错，想法很美好，例如：交响乐团模式、功能团队模式等等。我们都会希望能够使得团队实现这些好的运作模式。但在实际操作中往往会产生问题。我思考的问题是：团队模式和团队成员的特点究竟谁决定谁？

以软件工程的敏捷开发为例，假设我们的团队中有一位传奇人物，能力超强、经验丰富、与其他成员也很默契，那么这时候我们的团队是应该根据团队成员的特点选择主治医师模式，还是应该根据敏捷开发的特点选择爵士乐模式呢？

在组成团队之初，大家都会寻找和自己互补的队友。团队成立后，大家会根据每个人以往的经历和偏好特点进行初步的分工，例如：PM、前端、后端等等。而在团队需求、设计、实现等几个阶段之中，也会有一些成员展露出自己的天赋，例如美工、安全测试等等，这时可以考虑对分工进行动态调整，做到人尽其用。

问题4

我认为结对编程是一种优秀的开发模式，它有效地解决了两个问题：代码复审与沟通造成的时间消耗 和 长时间从事单一工作带来的边际效益递减。但是目前互联网公司中并没有流行起来结对编程的热潮，根据我的检索，原因主要有：

结对编程的效率主要体现在bug少、代码质量高等隐式利益上，直观感受上效率是下降的
结对编程是对现有的企业考核体制的挑战
结对编程对开发人员的素质要求较高
不懂开发的管理人员无法理解结对编程的好处
问题：如何逐步引导企业采用结对编程来提高效率呢？

正如助教留言所说，结对编程在理论上虽好，但是实践中往往会遇到各种各样的问题。尤其是在结对编程的开始阶段，由于开发人员对于结对编程的模式不熟悉、对于结对的队友编程风格的不熟悉等等，往往难以获得结对编程的好处。而我们的结对作业由于周期太短，也有上述问题，因此我还是无法判断结对编程是否真能够带来理论上的诸多好处。

问题5

最后我想讨论软件工程对开发人员约束粒度的问题。为了详细解释软件开发的某些流程，作者经常会介绍具体的工具，有时还会直接给出代码。在结对编程的章节，作者给出了十分精确的编程习惯。我对此感到疑惑。软件工程是否需要关心这些具体的工具和语言规范？再发散一点的话，软件工程所倡导的内容，应该被灵活对待作为公司文化，还是被严格执行作为写进员工守则呢？

由于我们的团队项目的规范性很难与正规的企业项目相媲美，所以这一个问题仍然存疑。据我的了解，有类似于Google C++ Style这样的代码规范，也有一些相对来说比较抽象的工程管理模式和开发模式，所以软件工程其实是一个涵盖很广泛的问题。

实践学习

需求

需求分析的时候不能只从用户的角度分析需要什么，还要考虑更多的因素，例如：网络安全问题、运营相关的法律法规、运营成本、时间成本等等。

设计

虽然功能是一个项目/产品的核心，但是美观的界面永远是最吸引用户的，因此对于UI设计应该要更重视一些。

实现

尝试了没用过的组件库，对Vue的了解更深刻了，也知道了一些关于安全的知识。

测试

Alpha阶段测试没有问题的功能，即使没有修改过，Beta阶段也有可能出现问题。因此，回归测试也很重要。

发布

开发团队应该指定一个发布的规则，写明什么阶段完成什么功能之后应该发布。当然，由于敏捷开发中用户也充当重要的角色，所以发布的时间也要尽量缩短。

维护

这一阶段应该考虑编写更详细的开发文档，同时对于Bug进行严格复审，对于新功能的诉求集体讨论，以防新的改动对于原有功能的影响。

理解心得

软件工程的团队项目是本科阶段所有课程作业中最接近真实开发环境的了，当看到我们的项目真正在服务器上跑了起来，当第一个学生在我们的平台上提出了问题，当第一个辅导师开始回答问题，我都会由衷地地为我们团队所有成员的努力感到骄傲。感谢软件工程课程给了我们一次do something的机会。

软件工程将会在今后伴随着大多数同学，无论是在科研、在工作之中都会发挥很大的作用。希望即使时过境迁，我们还能够用科学的方法确保所开发的软件安全高效。