《构建之法》阅读与提问

《构建之法》阅读与提问

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区-CSDN社区云
这个作业的要求在哪里	个人作业-阅读和提问-CSDN社区
我在这个课程的目标是	学习软件工程理论基础，通过实践锻炼开发能力
这个作业在哪个具体方面帮助我实现目标	快速了解软件工程的基本概念，为之后的作业打好基础

问题1：

提出问题

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

事例资料

在上学期的编译实验中，我们要自己实现一个编译器。假如我实现了一个编译优化功能，我希望对这个功能进行单元测试。但是这个模块的输入输出都只是一个指向语法树数据结构的指针。如果想要手动构造测试样例的话，可能要实例化上百个对象，这使得单元测试十分困难。

对于一些处理图形、图像的软件（游戏引擎、CAD），往往需要通过搭建起一条可视化的流水线之后才能够通过视觉效果直观判断是否有问题，而中间结果往往是张量或者更复杂的数据结构。

章节内容

第2章 个人技术和流程 2.1 单元测试 P21

绝大部分软件都是由多人合作完成的，大家的工作相互有依赖关系。最典型的例子就是，某人负责的模块的功能被其他人调用。软件的很多错误都来源于程序员对模块功能的误解、疏忽或不了解模块的变化。如何能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？单元测试就是一个很有效的解决方案。

问题2：

提出问题

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

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

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

事例资料

原文：Why I Hate Scrum - DZone

翻译：为什么我恨Scrum? - 知乎 (zhihu.com)

章节内容

第6章 敏捷流程 6.1 敏捷的流程简介 P116

在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过 Scrum 大师（ Scrum Master ) 来完成。这一措施较好地平衡了“交流”和“集中注意力”的矛盾. 有任何需求的改变都留待冲刺结束后再讨论。

冲刺期间，团队通过每日例会（ Scrum Meeting ) 来进行面对面的交流，团队成员大多站着开会，所以又称每日立会

问题3：

提出问题

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

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

章节内容

第5章 团队和流程 5.2 软件团队的模式 P98

就像在手术台上那样，有一个主刀医师，其他人（麻醉，护士，器械 ）各司其职，为主刀医师服务。这样的软件团队中，有首席程序员（Chief Programmer )，他 / 她负责处理主要模块的设计和编码,其他成员从各种角度支持他 / 她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。佛瑞德 布鲁克斯在主管 IBM System 360项目时就采用了这种模式。在一些学校的软工课上，这一模式往往退化为“一个学生干活，其余学生跟着打酱油”。

第5章 团队和流程 5.2 软件团队的模式 P99

交响乐团的演奏有下面的特点。

• 家伙多，门类齐全。

• 各司其职，各自有专门场地，演奏期间没有聊天、走动等现象。

• 演奏都靠谱，同时看指挥的。

• 演奏的都是练习过多次的曲目，重在执行。

当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队就会采取这种模式。

问题4：

提出问题

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

• 结对编程的效率主要体现在bug少、代码质量高等隐式利益上，直观感受上效率是下降的
• 结对编程是对现有的企业考核体制的挑战
• 结对编程对开发人员的素质要求较高
• 不懂开发的管理人员无法理解结对编程的好处

问题：如何逐步引导企业采用结对编程来提高效率呢？

事例资料

一个一线开发人员创作的很有意思的漫画

漫画 | 结对编程实在太可怕了！！ (qq.com)

章节内容

第4章 两人合作 4.5 结对编程 P85

每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随

时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位= 这样，程

序中的错误就会少得多，程序的初始质量会髙很多，这样会省下很多以后修改、测试的时间。

具体地说，结对编程有如下的好处：

1. 在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。两人合作，还有相互激励的作用，工程师看到别人的思路和技能，得到实时的讲解，受到激励，从而努力提高自己的水平，提出更多创意。
2. 対开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
3. 在企业管理层次上，结对能更有效地交流，相互学习和传递经验，分享知识，能更好地应对人员流动。

总之，如果运用得当，结对编程可以取得更髙的投入产出比

问题5：

提出问题

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

示例资料

vs code中对于 html 的缩进往往使用两个空格

IDEA 中补全的代码往往遵循下述的格式c，而非书中推荐的格式d

章节内容

第2章 个人技术和流程 2.1 单元测试 P22

图 2-1 中，底部窗口标题为 Create Unit Tests, 右键选中 User , 岀现 “New Test Project“弹窗，这样就可以创建新的单元测试。

创建好单元测试后，注意到在 Solution Explorer 中出现了三个新的文件。

如何管理设置文件呢? 右键再选属性（ Property ) 并不对，必须双击设置文件才能进入管理及设置界面进入设置界面后，可以让单元测试产生 “demouser.dll” 的代码覆盖报告。

…

第4章 两人合作 4.2 代码风格规范 P70

缩进：是用 Tab 键好，还是 2、4、8 个空格？

4 个空格，在 Visual Studio 和其他的一些编辑工具中都可以定义 Tab 键扩展成为几个空格键。不用 Tab 键的理由是，Tab 键在不同的情况下会显示不同的长度，严重干扰阅读体验。4 个空格的距离从可读性来说，正好。

下面的改进（格式 c )虽好，但还是不够清晰：

if (condition) {
 DoSomething();
} else {
 DoSomethingElse();
}

于是，我们最后选择了下面的格式d

if (condition) 
{
 DoSomething();
} 
else 
{
 DoSomethingElse();
}