软件工程个人作业- 提问回顾与个人总结

软件工程个人作业- 提问回顾与个人总结

回顾

提问博客：软件工程个人作业-阅读和提问

问题一

• 原文

10.1.5 分行
不要把多行语句放在一行上。
a = 1; b = 2; // bogus
if (fFoo) Bar(); // bogus
更严格地说，不要把不同的变量定义在一行上。
Foo foo1, foo2; // bogus

• 问题（不同意教材的观点/不能回答的问题）
  对于一行定义多个变量，我认为如果变量在功能上具有一致性，定义在同一行反而有利于代码的可读性。在代码编写时将具有相同作用的变量定义在同一行，无论是回顾代码时还是其他人阅读时都能更加简明。那么如果团队能对此达成共识，在开发时可否不完全按照教材上的代码规范编写？（对于其余代码规范同理）此外，如果团队成员都为同一种代码编写习惯（如缩进的tab键），是否有必要让全体成员都按照代码规范进行改正？

• 解答
  在团队开发的过程中，我对代码规范的意义有了一定的了解。代码规范是为了增加其他成员对代码的可读性，这需要改变部分人的代码习惯。书中的代码规范只是提供一个范例，并不需要严格按照书上的内容执行，可以在团队协商后得到一个共同遵守的代码规范。对于一行定义多个变量，由于开发中存在不同类型而有并列关系的变量，每行只定义一个变量反而会增加代码可读性。

问题二

• 原文

10.3.5 代码复审的核查表
4．具体代码部分
（4）有没有使用断言（Assert）来保证我们认为不变的条件真的满足？

• 问题（不能回答的问题）
  对于教材中这段关于Assert的要求，我有以下疑问。要求中需要Assert的范围是如何界定的？如果所有需要判定的变量都用一条Assert语句，是否过于繁琐，从而引起代码的冗余导致可读性下降？如果只判定一部分变量，如何判断某变量是否需要用Assert判定？如果仅根据编写该部分代码的负责人的个人想法，可能会使得断言覆盖不完全，从而失去了断言的目的。既然如此，有没有一个详细具体的判定方式能判断Assert的覆盖范围？

• 解答
  assert语句一般用于期望但不确定的条件，一个典型的用例是契约式编程中对前条件的检查。在实际开发中，如果代码块被团队其他成员调用，则需要使用assert语句保证前条件成立。

问题三

• 原文

交响乐团模式 (Orchestra):
大家看过交响乐团的演奏。我觉得有下面一些特点:
家伙多, 门类齐全。
各司其职, 各自有专门场地，演奏期间无聊天走动随意交流等现象。
演奏都靠谱, 同时看指挥的。
演奏的都是练习过多次的曲目, 重在执行。

• 问题（不能回答的问题）
  对于这种各司其职的团队模式，如果一个分工需要另一个分工的接口（如前端和后端），那么该分工应该在另一分工完成后进行工作还是同时进行在最后对接？如果按次序进行会使工期延长，同时进行则不可避免在最后对接时进行修改，从而增加工作量，甚至产生bug。在这种情况下，该如何平衡两种方案的优劣？

• 解答
  团队不同部门的接口应是PM在代码开发前就设计好的，不存在对接时出现不匹配的问题。

问题四

• 原文

测试的角色(Test)要独立出来么?
回答: 首先, 我相信有分工是好事, 软件团队中应该有独立的测试 (Testing) 角色。所有人都可以参与QA 的工作 (报告bug 什么的), 但是最后要有一个角色对QA 这件事负责。 不但角色要独立，而且在最后软件发布的时候, 必须得到此角色的签字保证 （sign off）。我在微软参与的项目都是这样做的。

• 问题（不同意教材的观点）
  原文中认为测试QA的角色应当独立出来成为一个专门的角色，但我认为对于课程中的团队来说，5-7人中配置一个QA角色不一定是最好的方案。对于作者来说，他在微软的团队都是体系完整、经验丰富的，但我们作为缺乏经验的寥寥数人组成的团队，如果配置一个专门的QA角色会导致dev的人力减少。同时，由于缺乏测试经验，即使分出一个专门的QA角色，这位测试人员也可能不会发挥出很大的作用，测试可能出现漏洞。与此相比，我认为小团队工作应当完成测试前的其他工作后，再共同进行测试，这样的效率和正确率都会有所提升。

• 解答
  在团队开发中，我所在的团队只有5人，因人手不足而未分出一个专门的QA角色，因此每个人需要对自己编写的代码部分做系统性的测试。如果有一个专门的QA角色，可以减少其他人的工作量，并且加速开发的进度。但如果团队体量过小，也只能为整体开发而舍弃QA角色。

问题五

• 原文

用户调查问卷 (User Survey)
给用户事先规定好的问题, 让用户回答。

• 问题（不能回答的问题）
  我们作为大学生，由于社交的局限性，用户调查问卷收集的结果往往不能代表各个年代的人，以此形成的典型用户画像不能代表所有目标用户。所以，是否有一个好的方法能够收集到能代表各类不同目标用户的用户画像？这些方法是否能够被我们大学生所使用？

• 解答
  应考虑所开发软件的目标用户，针对目标用户设计问题和发放问卷，尽量动用团队中各成员的社交资源。

知识点

需求阶段

结构化需求模型包括：

• 数据流图和加工规格说明的功能模型
• 主要由数据字典和 E-R 图等组成的数据模型
• 由状态转换图、控制流图和控制规格说明等组成的行为模型

设计阶段

模块独立性可以从两个方面来度量：

• 模块本身的内聚（cohesion）：模块内部各个成分之间的联系，所以也称为块内联系或模块强度。
• 模块之间的耦合（coupling）：一个模块与其他模块间的联系，所以又称为块间联系。

模块的独立性越高，则块内联系越强，块间联系越弱。

实现阶段

软件实现的任务包括：

• 程序设计语言的选择。
• 集成开发环境的选择。
• 程序实现算法的设计。
• 程序编码实现。

测试阶段

多模块程序的测试共包括 4 个层次：单元测试、集成测试、确认测试、系统测试。

发布阶段

• 在发布之前做代码冻结。
• 对代码冻结后发现的bug要分级。
• 每次修复bug后，发布新的版本。
• 每次部署新的候选发布版本后，要做回归测试。

维护阶段

软件维护的类型包括：完整性维护、适应性维护、纠错性维护、预防性维护。

心得

在课程中，我首次参与了正式团队开发软件从需求分析到发布维护和全过程。作为后端开发，我的主要工作自然是代码编写。而团队开发中的代码编写与独立开发一个程序有很大不同。我在代码编写时需要考虑代码对其他后端成员的可读性，因此在代码风格和变量命名等方面需要遵循商讨得出的统一标准，与独自开发相比更加标准化。虽然失去了独自开发代码时的自由，但在开发大型程序时这种规范是必不可少的。此外，由于人手不足，我还参与了接口与数据库设计、数据处理、单元测试等工作，深刻地体会到代码编写仅仅是整个软件开发的一小部分，系统完成一个软件的开发需要各方的共同工作。