2023年软工作业—阅读《构建之法》

项目	内容
这个作业属于哪个课程	北航软工社区
这个作业的要求在哪里	作业1要求
我在这个课程的目标是	学会结对编程和敏捷开发
这个作业在哪个具体方面帮助我实现目标	结对编程和敏捷开发

提问

以下问题均无法回答，似乎没有标准答案。

问题1：如果量化敏捷开发的效果？是否存在比敏捷开发更具效率的价值观和体系？

在《构建之法》的第六章中的第115页有：

问：为啥很多研究都证明敏捷很有效果?
答：大多数被测试、被研究的新东西都很有效果，这是Hawthorne效应。例如你可以测试“给每一个程序员发毛绒玩具，然后测试劳动生产率”,你会发现毛绒玩具能提高劳动生产率!

从上述文字中发现，敏捷能够提高生产率，但是这就是最佳的催化剂了吗？
虽然敏捷开发在很多情况下能够带给团队很大的效益，但是还是应该因地制宜，不是所有的团队都适用于敏捷开发，所以我认为也不存在一个标准的评价指标和体系，例如还有MSF等团队模型可以考虑其中。所以我觉得不存在普适的，适用于所有情况的最有效的价值观体系。敏捷开发能带来更多的效益是经验告诉我们的，没有科学依据。

问题2：为什么"冒烟测试"仅仅是测试致命性bug?

在《构建之法》的第十三章中的第244页有：

问：有人提到一种“冒烟测试”,是怎么回事?
答：事实上这是一种基本验证测试，据说是从硬件设计行业流传过来
的说法。当年设计电路板的时候，很多情况下，新的电路板一插上电
源就冒起白烟，烧坏了。如果插上电源后没有冒烟，那就是通过了“冒
烟测试”,可以进一步测试电路板的功能了。我们正在讨论的BVT也
是一种冒烟测试。

书中未对“冒烟测试”作详细介绍。
经过查阅资料,维基百科上对"冒烟测试"的解释如下:

smoke testing is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of [test cases] that cover the most important functionality of a component or system, used to aid assessment if main functions of the software appear to work correctly.When used to determine if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called an intake test.Alternately, it is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team. In the DevOps paradigm, use of a BVT step is one hallmark of the continuous integration maturity stage.

冒烟测试就是在每日立会构建之后，对系统的基本功能进行简单的测,其重点在于 daily build，也就是说冒烟测试是随着每一次构建而产生的,而不是所说的测试阶段。
除此之外，《构建之法》中还提到了回归测试【在书中的28页】，两者比较来看。
经过查阅：

冒烟测试测试的是致命性Bug。

冒烟测试和回归测试的区别在于，冒烟测试是找的致命性bug，并且可以节约测试时间成本；但是回归测试就是在对旧代码更改引入的新代码进行测试，看看是否引入新的bug，或者退步。为什么冒烟测试仅仅测试的是致命性bug？虽然此种说法和书中的描述相似，即电路板插上电源是否会冒烟，有没有导致程序跑不动的问题。但是在多轮冒烟测试之后，是否一些小的bug在多轮冒烟测试时未及时检出，导致最后debug时由于bug年代较为久远而导致的效率太低？

问题3：WBS细粒度是否会因为项目的规模而改变?

在《构建之法》的第十三章中的第244页有：

问：所有的文档、工作计划也算在WBS中么?
答：如果这些文档是可交付给客户的，或者开发团队要掌控制作文档
的花费(人力),那么文档也可以算在WBS中。如果项目很小，或
者文档不是很复杂，那么文档工作就可算为项目管理的一部分，而不
必单列为一个交付件(Deliverable)。

经过查阅：

可见WBS分的细粒度如何,主要取决于项目的大小.但是往往由于某些原因会使得WBS和项目之间没有紧密的联系。

于是产生疑问：为什么WBS的细粒度要根据项目的大小儿改变？不应该是基本两周的时间完成一个叶节点？这意味着WBS的细粒度应当是恒定的？对这个分解还是不太清楚并存疑。于是又查到：

由于WBS不是一个事事巨细的覆盖整个项目的分解结构，所以很多细节都不会体现在WBS中。

《构建之法》第170页:

从结果出发构建WBS，而不是从团队的活动出发.

所以结果导向的WBS分解，我觉得WBS的细粒度应当和需求相关，但是不应该因为需求的改变而改变WBS的细粒度。但是对于实际开发过程中是如何做的还有待考量。WBS体现主要是可交付成果，因此常常会被束之高阁。经过查阅,我还发现WBS可以与其他编码体系配合，体现不同的配置关系，比如WBS和OBS结合,就可以进行指责配置。同时我觉得如何分层分级也是一门技术活，层级多，难管理，层级少，难执行。

问题4：小强地狱的出现是否是由于每日构建的质量门禁过低？

在《构建之法》的第240页中对"每日构建"的定义中未提及每日构建的具体事务.
经过查阅,发现daily build就是把一个软件项目的所有的最新的代码从配置库中取出,然后从头进行编译,链接和运行。

Daily build一般是每日下班后半夜进行,前提是员工check in 最新的code到配置库中.所以可以把daily build戏称为nightly build.然后在第二天上班时把错误给所属模块负责人并敦促解决.

所以daily build是为了减少构建失败的次数,需要尽早发现问题,降低解决问题的成本.同时还可以最小化集成成本.

那么如何有效地进行Daily Build呢?

1. 进行工具协同:固化流程,实时纠偏
2. 制定标准:制定质量门禁
3. 积跬步:在构建后进行冒烟测试

于是产生疑问：如果出现了小强地狱，是否意味着之前的每日构建设置的质量门禁过低？两者是否存在着直接的联系？并且我发现在每日构建之后进行的冒烟测试也仅仅是测试出了致命性的bug，对隐藏的小bug视而不见，是否会导致一直都有百分之十几到二十几的人在小强地狱？我觉得小强地狱的存在不利于团队的发展，所以测试和每日构建之重要不言而喻。

问题5：什么是集成测试的合适时机?

在<构建之法>的P248中写道:

在模块本身稳定之前就提早做集成测试，可能会报告出很多Bug,但是这些由于提早测试而发现的Bug,有点像汽车司机在等待绿灯时不耐烦而拼命地按喇叭—也就是说，有点像噪音。我们还是要等到适当的时机再开始进行集成测试。

可见不是一个新的模块加进去就要进行集成测试.经过查阅之后:

理论上，集成测试在单元测试之后,但是这样做效率太低。
实际上，单元测试和集成测试同步进行，在单元测试中先测试几个函数的功能，然后再集成测试一下这几个函数的接口。

所以我产生疑问的是实际开发中集成测试是否和单元测试混为一谈，何为同步进行？较频繁地进行集成测试是否会导致效率太低？如何平衡测试和效率的问题？两者应该是互相制约和互相影响的。我觉得我应该会在之后的团队实践中得到答案。