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

[20373042-张资尧]

软件工程个人作业- 阅读与提问

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区
这个作业的要求在哪里	个人作业-阅读和提问
我在这个课程的目标是	掌握团队开发软件的能力并实践
这个作业在哪个具体方面帮助我实现目标	了解团队开发软件的流程和工具

问题一

• 原文

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的覆盖范围？

问题三

• 原文

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

• 问题（不能回答的问题）

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

问题四

• 原文

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

• 问题（不同意教材的观点）

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

问题五

• 原文

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

• 问题（不能回答的问题）

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

[SoftwareTeacher]

@暗夜无风 （4）QA 的测试计划，也会和代码的设计几乎同时开始，这样能帮助尽早发现问题。

[暗夜无风]

（1）按照公司的安排，你没有过多的选择。放在同一行看个人喜好，我个人是觉得挺不错的，然而一个公司都有代码规范的，不规范的在上线时过不了审核。
（2）assert不是都需要使用的，assert一般在调试bug时使用。
（3）前后端一般都是一起进行，或者稍微等待一起，事先两者应该先定义好接口，然后各自开发，最后再一起调试。
（4）在一个大团队里，QA是重要的。QA需要想到前后端想不到的case，然后对整个系统进行测试，这不简单。QA需要等到其它成员完成后开始。
（5）爬虫，自己去爬取各大知名软件的数据可能是好的选择。

[BrownSearch]

问题3：冲刺例会的目的就是在于日日清，比较好的方式是前端和后端的开发人员两两结对，定期进行对接，一般是积累几个问题一起找个固定时间一起对接
问题4：QA角色确实不一定需要完全独立出来，根据实际情况而定。一种可行的做法是：一个同学主管测试，这个测试是指压力测试/整体的代码复审/部分核心代码的测试，其他开发工作可以少分配一些