[I.1] 个人作业：阅读和提问

[I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	培养掌握软件开发的全流程方法论、工具和实践技能，包括需求分析、系统设计、编码、测试、部署与维护，同时培养团队协作、项目管理和解决实际问题的能力。
这个作业在哪个具体方面帮助我实现目标	学习现代软件工程的理论知识，帮助更好地进行软件工程的实践，学习如何提出有价值的问题。

问题1：如何把握软件工程项目扩大化/泛化的“度”与时机？

在《构建之法：现代软件工程》中，作者提到：

软件的“软”还表现在它可以扩展。在写一个程序的时候，需要某个函数可以处理整数类型和字符串类型的信息，有的程序员往往灵光闪现——哎，能不能把类型抽象出来，让这个函数处理所有可能的类型？……有些软件本来是解决一个特定环境下的具体问题，有的程序员一想，我们能不能做一个平台，处理所有类似的问题，这样多好啊！……程序员的确需要这样的凌云壮志，但是要了解必要性、难度和时机。

——《构建之法：现代软件工程》第三章：软件工程师的思维误区

我的问题是，我们在项目实践中，如何把握扩大化/泛化的度与时机。

在之前的学习中，为了追求可扩展性，大家往往会提高自己程序的泛化程度，抽象自己的代码设计。在面向对象课程中，我们会考虑扩展/泛化问题，而在最初设计的时候思考很多情况。有时，太多的情况分类，导致一直在思考架构设计，半天都不能动手写代码。有时，考虑了很多，但是很多复杂设计在未来的作业都用不上。但是完全不考虑扩大化/泛化问题，可能会出现代码可扩展性弱，无法面对未来的功能需求的情况，导致代码重构。在书中作者也提到，项目的扩大化/泛化要了解其必要性、难度和时机，我的疑问就是其中的“度”以及时机应该怎么把握，是不是应该在设计文档中就有所体现与规范。

问题2： 属于辅助需求的外围功能可以采取“不做”的办法吗？

在《构建之法：现代软件工程》中，作者提到：

• 维持——以最低成本维持此功能。
• 抵消——快速地达到”足够好“、”和竞争对手差不多“。
• 优化——花大力气做到并保持行业最好。
• 差异化——产生同类产品比不了的功能或优势（我有人无的优势，或者一个数量级以上的优势）
• 不做——砍掉一个功能也是一个办法，我们并不一定要做所有的功能。

——《构建之法：现代软件工程》第八章：功能的定位和优先级

我的问题是，对于第三象限中的满足辅助需求的外围功能，可不可以采用“不做”的方法。

因为辅助需求和外围功能相对于杀手功能和必要功能而言，属于不需要“大力”去实现优化的，其优先级应该是最低的，而对于辅助需求的杀手功能，我们可以采用“不做”的方法，那我认为辅助需求的外围功能应该也可以“不做”，或者同样等待好的时机再实现。根据YAGNI原则，第三象限的功能也可以“砍掉”，使更多的时间去实现差异化，提高团队项目的价值和竞争优势。

问题3： 是开源还是闭源？

在《构建之法：现代软件工程》中，作者提到：

阿超：……如果我们的项目成功了，有人以“开源”的名义来要我们的源程序，我们答应么？

二柱：凭什么！

阿超：对呀，凭什么！在软件中凝聚了我们“无差别的人类劳动”——这就是软件这一商品的价值，我们的口粮、公司的水电费都得用这一价值去交换，我们如果重视商业价值，就要有重视商业价值的做法。有一些原来“闭源”的项目，后来变成开源的，总是有各自的原因，这些原因里面，商业运作的因素也很明显。

——《构建之法：现代软件工程》第七章：MSF基本原则

我的问题是，我们的项目是选择开源还是闭源，我们该如何选择。

关于开源和闭源一直是不同的人有不同的看法，两者也各有千秋。闭源软件在提供专业、可靠的支持方面表现出色，拥有专门的客户服务团队。用户可以期待一致的帮助和明确的问题解决责任。同时开发遵循受控、系统化的过程，质量控制受益于集中监督，商业模式清晰且可持续，通过许可证销售和支持合同产生收入（闭源的优势）。在书中也可以看到，MSF基本原则中就有重视商业价值，提供渐进的价值。而当下，开源软件也在不断发展，成本效益是最直接的好处之一，因为大多数开源软件可以在没有许可费用的情况下获得和使用。这种可及性使其对初创企业、教育机构和预算有限的组织特别有吸引力，同时透明性和安全性是其另一个显著的优势（开源的优势）。特别是最近DeepSeek的发布，进一步激发了开源的活力。所以我的疑惑是我们该如何选择项目该开源还是闭源，我们需要考虑什么方面。

问题4： 结对编程是否会产生更多的问题？

在《构建之法：现代软件工程》中，作者提到：

为什么结对编程

不间断地复审

如何结对编程

——《构建之法：现代软件工程》第四章：结对编程

我的问题是，当两位程序员水平有一定差距时，如果审核代码的程序员水平较低，会不会跟不上写代码程序员的节奏，反过来，审核代码的高水平程序员会不会等待写代码的程序员，而分散注意力以及不耐烦等，除此之外，当两个人进行结对编程，会不会因为对一些细小问题的看法分歧，而产生争论，从而因为这些问题而导致代码效率下降。

在书中，作者也提到了大家会对结对编程的疑问。在这篇文章中也提到了结对编程的好处以及存在的问题。这些问题是很可能发生的，遇到这些问题我们该如何解决，甚至说，找到一个合适的队友是解决结对编程问题的关键所在？

问题5：PM不需要较强的专业技术能力吗？

在《构建之法：现代软件工程》中，作者提到：

成为一个合格的PM，需要哪些能力呢？

1. 观察、理解和快速学习能力
2. 分析管理能力
3. 一定的专业能力

在一个项目中，PM的具体任务是什么呢？他们的任务是：

1. 带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计；
2. 管理软件的具体功能的生命周期（需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰）；
3. 创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍；
4. 代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级；
5. 分析并带领其他成员对缺陷/变更需求形成一致意见，并确保实施；
6. 带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件；
7. 收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。

——《构建之法：现代软件工程》第九章：PM做开发和测试之外的所有事情

我的问题是，一名PM不需要较强的专业技术能力吗，一个团队中PM应该选择谁来担任。

在书中，作者提到了一名合格PM应该具备的能力，其中关于专业能力只提到了：具有“一定”的专业能力，并没有强调PM需要有较强的专业技术能力。而在PM具体任务中，作者提到，PM的产品是规格说明书，同时第十章提到，规格说明书还包含了技术说明书。如果专业能力不强，PM形成的技术说明书，会为开发人员带来更多的障碍吗？在实践中，我们团队进行PM选择时，由于PM在团队中的“掌舵人”的能力，优先考虑了专业能力较强的同学进行担任，似乎大家也不愿意让不懂专业技术的人来担任PM。所以，这里我产生了疑惑，一名PM需要较强的专业技术能力吗，一个团队中PM应该选择谁来担任，PM应该怎么担任。