I1《构建之法：现代软件工程》：阅读和提问

[21371142-柯棋严]

项目	内容
这个作业属于哪个课程	2024年北航敏捷软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程的方法论，并通过实际开发产品进行实践。
这个作业在哪个具体方面帮助我实现目标	通过阅读《构建之法：现代软件工程》，接触并掌握敏捷开发的知识，以问促学，为后续实践做下理论铺垫。

---

Q1：单元测试一定要由程序的作者本人来写吗？是否存在一种高效有效的单元测试方法供程序员快速针对自己的代码进行测试？

问题来源

《构建之法——现代软件工程》第2章 个人技术和流程 P21-P28

原文上下文

如何能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？单元测试就是一个很有效的解决方案。
...
单元测试必须由最熟悉代码的人（程序的作者）来写。
代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
...
单元测试必须和产品代码一起保存和维护

资料查询

现在比较主流的单元测试框架有：Junit、Mockito、Spock、TestNG、PowerMock。Junit： Junit是最常用的Java单元测试框架之一，它提供了一组简单易用的API，可以方便地编写和运行单元测试。Junit主要优点包括易学易用、广泛使用、生态丰富等，但它缺乏一些高级功能，如模拟对象等。Mockito： Mockito是一个用于模拟对象的Java单元测试框架，它可以帮助开发人员创建和管理模拟对象，从而进行真正的单元测试。Mockito的主要优点包括功能强大、易于学习和使用、支持扩展等，但它可能会带来一些性能问题。

更多地介绍可以前往参考资料进行了解

参考资料：https://blog.csdn.net/Edward_hjh/article/details/129670775

问题详述

关于单元测试，其实在面向对象的课程中有所接触JUnit相关的知识，并且通过前序课程的学习，我也能清楚的认识到测试的重要性。但是经过自己编写JUnit的亲身经历来说，随着代码规模的急剧增加，单元测试较黑盒测试的优越性越来越突出，但是对于编程者来说仍是一笔不小的时间开销。并且我调研了Mockito、Spock、TestNG、PowerMock等其他单元测试工具，单元测试的工作量事实上并不算小。同时书中强调“单元测试必须由最熟悉代码的人（程序的作者）来写”，这其实从某种方面就限制了编程者的效率。在我看来，单元测试可以交由其他精通测试、并且对待测试代码有一定熟悉程度的人来撰写，这更利于团队合作的开展，而且编程者对自己的代码测试时很容易陷入思维误区，编程时没有考虑的情况很难说编写测试时就能百分百覆盖。

Q2：什么样颗粒度的编程规范是合适的呢？不同人的代码习惯不同，如何形成有效的统一呢？

问题来源

《构建之法——现代软件工程》第5章 团队和流程 P101

原文上下文

很多软件公司的团队最后都演变为功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。
在这个功能完成之后这些人又重新组织，和别的角色一起去完成下一个功能。
...
每个小组都由一到三个人组成，每个小组都是一个有自主权的单元，可以自由选用最有利于他们完成工作的任何技术。但是，每个小组必须与其他小组就编程规范达成一致。

资料查询

阿里巴巴的编程规范是一套详细的编码指南，旨在提高软件开发的质量和效率，同时促进团队协作和代码的可维护性。这套规范涵盖了多种编程语言，包括Java、JavaScript、Python等，反映了阿里巴巴在软件开发实践中积累的丰富经验。阿里巴巴的编程规范特别强调代码布局和格式、命名规约、编码原则、安全规范、异常和日志管理、单元测试。
参考资料：https://developer.aliyun.com/article/1254280

问题详述

合适的编程规范颗粒度是一个需要仔细平衡的问题，旨在实现代码的一致性和可维护性，同时又不至于限制开发者的创造性和效率。过于粗糙的规范可能导致规则过于宽泛，难以解决具体的编码问题；而过于细致的规范则可能过分限制开发者，降低开发效率并增加学习成本。所以，理想的编程规范应该在确保代码质量的基础上，给予开发者足够的灵活性。编程规范的制定是一个动态的过程，需要不断地调整和完善以适应团队和技术的发展。通过明确规范的核心原则，鼓励团队参与和反馈，并保持一定的灵活性，形成一个既有利于提高代码质量又能适应个体差异的有效编程规范体系。当然，具体的理念落地还需要不断地打磨迭代，例如阿里的编程规范或许可以作为不错的借鉴。

Q3：MSF 强调开发者与客户的合作性，但是什么是适度合作呢？客户对于产品开发的干预是越多越好吗？

问题来源

《构建之法——现代软件工程》第7章 实战中的软件工程 P145

原文上下文

MSF强调产品团队与顾客的交流与合作，并不是产品团队拿到合同之后，就闭门造车，直到产品完成才告诉用户，给他们一个惊喜（通常“惊”大于“喜”）。项目当然是项目团队成语做的，但是项目的商业价值要由用户说了算，那些“我觉得用户会喜欢”的东西要及早和用户交流，因为“我觉得”和“用户觉得”是两码事。

资料查询

在“MSF管理的组队模型与亿泰公司的的项目管理”中，关于以客户为中心有这样的阐述：满足客户对任何优秀的小组来说都被看作是第一位的。在整个开发过程中，以客户为中心包含了小组对了解和解决客户业务问题的承诺。衡量以客户为中心的理念体系获得成功的方法之一是能否使设计中每一个特性都符合客户和用户需求。同样，实现客户满意度的一个关键方式是使用户积极地参与设计并在整个开发过程中提供反馈意见。这样，小组和客户都能的使期望和需求更加吻合。
参考资料：http://www.zjetime.com/msf.htm

问题详述

不能否认“以客户为中心”是一个团队不可或缺的理念，但是我认为客户过多的干预反而不利于团队的开发进程。客户中心理念的本质在于确保产品能满足市场需求和用户期望，而不是让客户完全主导开发过程。
首先，客户干预的过度可能导致 “需求蔓延”，这是项目管理中的一个常见问题。当客户不断变更需求或增加新功能，团队可能会发现自己在没有额外资源的情况下，试图满足这些不断变化的要求。这不仅会延迟项目进度，而且还可能导致产品质量受损，因为团队需要在有限的时间内完成更多的工作。其次，过度的客户干预可能削弱开发团队的士气和创造力。开发团队成员通常对他们的工作充满热情，渴望创造有意义和有影响力的产品。当客户的干预过多时，团队成员可能感到他们的专业判断和创意被忽视，这可能导致士气低落和创新能力的下降。

经过一些思考，我认为适度的合作意味着在保持项目目标清晰和团队自主性的前提下，允许客户的反馈和需求指导产品的开发方向。

Q4：A/B test 作为一种需求分析的手段，是否能真的客观反应用户需求？且其适用范围是否太窄？

问题来源

《构建之法——现代软件工程》第8章 需求分析 P166

原文上下文

A/B 测试看起来很简单：

• 决定试验哪两种不同的UI，以及衡量标准、数据收集流程、试验运行时间、人数；
• 在技术上实现A/B 测试（通常在5%-10%的用户上运行试验）
• 收集数据，分析数据，形成结论
• ...

A/B测试当然也有弱点：

• 运行成本随着时间的推移而变大，增加网站运维的复杂度，对网站数据收集和数据挖掘的能力也是一个考验；
• ...
• 用网站当前的用户做实验，万一引起巨大的方案，用户就真的流失了

资料查询

事实上，书中对于A/B test的介绍比较简短，我进一步查询了相关的资料：A/B Test是用于测试特定用户群，对不同版本的产品特征反应的线上实验方法。本质：基于抽样的统计学假设检验(显著性检验) 。关联：AB测试是灰度发布法的子集。基本原则：1.尽快得到实验结论，尽快决策；2.收益最大化，用户体验影响最小
参考资料：https://www.zhihu.com/question/20045543/answer/2173644967

问题详述

常见的A/B 测试指标有用户id、订单id、付款用户数、完成订单数，点击量等等。这些数据我认为只能从一定角度反映用户的注意力，却不能完全真实地反应用户的使用体验，正如原文所说的：“用户的情绪反应你看不到”，我认为过度指标化地进行需求分析，很容易让软件脱离人性化、以用户为导向的研发目标。同时，根据我自身作为用户和开发者的经验，A/B 测试的适用范围较为有限，首先比较对象不能过多，即使是两个方案的比较已经很大程度增加了团队的负担；其次能够采用A/B测试的方案较少，教材中以UI为例，但诸如软件架构、功能研发等问题没有统一指标，且不同方案兼容成本很高，采用A/B测试的可行性并不强。总之，A/B测试不失为一种需求分析的手段，但是其实用性我认为并没有非常大，更适合和焦点小组、用户调查问卷、可用性研究结合，从而形成一个全面的需求分析。

Q5：在大模型盛行、计算资源愈发重要的时代，成功的团队是否更能创新？

问题来源

《构建之法——现代软件工程》第16章 IT行业的创新 P356-P360

原文上下文

这难道不对么？这些企业因为创新而成功，创新是它们的企业基因。它们当然会继续创新下去，感情上是这样，这种感情驱使了很多求职者想“加入一个伟大的公司”。但是在实际上，你会发现很多成功的企业进入了一个创新者的困境。
...
成功的企业要满足股东们的巨大期望值...
成功的公司有价值观——追逐利润...
成功的公司有流程...
成功的公司重视用户...
成功的团队有老大的心理...

问题详述

原文中，作者也没有否认“已经成功的公司还能创新”这一命题，事实上，我认为相比之下，成功的团队也有很多利于他们自身创新的优势，尤其是在计算资源格外重要的今天，这些优势从某种程度上来讲我认为是大于作者所列举的劣势的。首先，成功的企业不一定需要上市，不一定会受资本的裹挟，这样的公司在国内便有很多，例如华为、大疆。其次，巨大的成功基础也带来了这个团队更强的抗风险力，带给了团队创新的底气和基础，相比于初创公司的不堪一击，成功的团队能够更好地统筹资源进行调配，从而抵御开发过程中的不稳定因素。再者，成功的团队有足够的经验，这种经验一定不能是墨守成规的经验，而是一种思维模式，如果一个团队能够保持持续的头脑风暴与思维碰撞，延续经验中的可取之处，我反而仍为成功的团队更容易创新。