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

项目	内容
这个作业属于哪个课程	<2025年春季软件工程>
这个作业的要求在哪里	<[I.1] 个人作业：阅读和提问>
我在这个课程的目标是	学习软件工程的理论，将理论与实际相结合，提升系统思维的能力
这个作业在哪个具体方面帮助我实现目标	学习软件工程的理论，为之后的实践打好基础

问题1

我看了这一段文字：

软件工程师能直接看见源代码，但是源代码不是软件本身。软件以机器码的形式高速运行，还可能在几个CPU核上同时运行，工程师是“看”不到自己的源代码如何具体地在用户的机器上被执行的。商用软件出现了错误，工程师可以看到程序在出错的-瞬间留下的一些痕迹(错误代号、大致的目标代码位置、错误信息)，但是几乎无法完整重现到底程序出现了什么问题。当工程师回过头来看源代码时，它们还是安静地排列在屏幕上。

(来自第一章第9页)

我的疑惑是： 现如今已经有十分成熟的IDE或者工具用来查看代码运行时的情况，为什么软件还是不可见的呢？

我查阅了相关资料，可能是不可见性这个概念的问题。
不可见性这个概念更多的应该是对于用户来说的，举例来说，当用户使用一个手机应用时，你能看到按钮和屏幕反应，但看不到背后的代码如何处理输入、调用API或管理内存。而对于程序员来说，程序员能看到的背后的东西显然要比用户多很多，程序员可以使用各种分析工具来定位错误的原因，也可以利用自身的知识进行分析。书中提到的问题实际上是存在的，有时候错误的复现是困难的，但是总归是可以复现出来的。
我的困惑在于软件真的是不可见的吗？对于不同级别的人来说可见性不同的，总有不可见的一部分存在。但是这部分并非那样神秘莫测，并非真的“不可见”，是不是用“复杂性”这样的词会更好一点呢？

问题2

我看了这一段文字：

软件开发的工作量和质量怎么衡量呢?第2章提到的PSP认为有下列4个因素:
a.项目/任务有多大?
说明项目的大小，一般用代码行数(Line OfCode，LOC)来表示;也可以用功能点(Function Point)来表示

（来自第三章第49页）

我的疑惑是： 什么时候项目的大小用代码行数衡量，而什么时候用功能点来表示呢？功能点具体指什么？

我查阅了相关资料，首先对与这两个指标有了更深刻的理解。
大多数情况下，我们一般用代码行数描述项目的大小，这对于完成过几个大项目的我们来说有着深刻的体会。然而代码行数可以包括所有代码行（包括注释和空行）或仅计算有效代码行（不包括注释和空行），似乎在大多数情景之下，两种代码行数是混合使用的，具体使用哪一种取决于上下文。
而功能点的度量是一个很复杂的事情，用来衡量软件提供的功能数量和复杂性，而不关心具体的代码行数。
由维基百科的说法，功能点的具体度量方式是这样的：

功能点通过分析以下五类功能组件来计算：

• 外部输入 (External Inputs, EI)：用户输入的数据或控制信息。
• 外部输出 (External Outputs, EO)：系统生成并呈现给用户的数据。
• 外部查询 (External Inquiries, EQ)：用户发起的查询操作。
• 内部逻辑文件 (Internal Logical Files, ILF)：系统维护的内部数据集合。
• 外部接口文件 (External Interface Files, EIF)：系统与其他外部系统交互的数据。

每类组件根据复杂性（简单、平均、复杂）分配权重，然后加权求和，得出未调整功能点数（UFP）。再根据技术复杂性因子（TCF）调整，最终得到功能点总数。

所以功能点的计算是十分复杂的。
但是在查阅资料以后，我还是有疑惑，对于日常的项目来说，用代码行数来衡量项目的大小似乎已经足够的了，功能点的计算十分复杂，而且也有强烈的主观性，不适用于严谨的项目大小计算，那么功能点的适用范围到底是什么？

问题3

我看了这一段文字：

一个作曲家在写一首交响乐的时候，他可以写各个乐器的乐谱，充分发挥不同乐器的特点，这说明他对各个乐器是非常了解的。然而在演奏这首交响乐的时候，不会是一个演奏家满场奔走，一会儿拉小提琴，一会儿吹单簧管，不会是一个人来演奏各个乐器。

（来自第三章第57页）

这是在谈论“专还是精”的时候所举的一个例子。

我的疑惑是：在实际的学习和工作的过程中，我们是应该更注重于精还是专，需要在某一特定领域深入钻研还是在多个领域都有较高的技能水平

我在查了资料以后发现有很多种说法，两方面都有各自的优势和不足。
如果选择“专”，那么容易在行业内脱颖而出，但是过于专注于某一领域的话，可能难以适应时代的发展，如果自己的领域的需求下降，自己难以转型。
而如果选择“精”，可以在不同项目中灵活切换，适应市场需求。但是自己在每一个领域之中可能都难以达到比较高的水平，容易在竞争中处于劣势。而且需要投入更多时间和精力平衡多个技能。
在书中的观点是，我们在团队合作的时候应该有更加明确的分工，然后各司其职，这样整个团队的成就能够更高。那么我疑惑的点是，对于个人呢？如果一个人只是能够做到团队要求的技能，其他的技能并不熟练，这对于个人的发展来说是不是也是可以接受的呢？

问题4

我看了这一段文字：

谁来做这第三步半呢?程序员写完功能的时候，我们感觉好像项目完成了80%，殊不知后面的20%往往要花费80%的时间，敏捷流程没有明确表明到底何人何时以何种优先级来完成这20%的任务。

（来自第6章121页）

我的疑惑是：剩下的20%的任务是什么？能不能降低花在这种任务的时间？

按照书中所讲的，剩下的20%的任务就是一些大量收尾工作，但是这是不是可以在前期提前做好呢？
对于测试、优化、修复 Bug、文档撰写这样的问题，实际上是可以在开发过程中逐步做好的。因为我们不可能在写代码的过程中完全不进行测试，而等到最后才开始进行测试和修复bug的工作，以及最后的优化也是可以在前期的开发过程中进行的，甚至有的优化涉及到架构的变化，这就必须在前期做好，而不是在开发接近完成的时候才进行。对于像部署这样的工作，也是需要提早进行适配的，而不能是在快结束的时候才进行。
在我看来，这样的问题本质上是敏捷流程执行不到位或团队协作不充分导致的，实际上很多的事情都可以提前做好。真正的敏捷开发过程中是可以有效减少这部分时间的，从而实现更加高效的开发。
那么，有没有什么更加系统的理论或者方法能够减少降低花在这种任务的时间？

问题5

我看了这一段文字：

如果一定要说专业能力的话，PM的专业就是理解和表达，你能否理解不同人的心理、需求和言外之意?你能否借助文字、图表、草图，甚至代码来清晰准确地表达自己的想法?PM 要始终能满怀激情地向用户兜售产品，向团队兜售希望。史蒂夫·鲍尔默的销售能力就是一个极好的例子!
PM 通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧!不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解"

（来自第9章198页）

我的疑惑是：“一定的”专业能力具体是需要多少的专业能力，哪方面的专业能力？

在书中的描述中，PM 似乎不需要很深的技术背景，而更强调沟通与管理能力。而书中所给的专业能力也是难以量化的技术能力，和写代码也不是特别相关，那么是不是说即使完全没有技术背景，也可以胜任 PM 的职责？
我在查资料后发现，不同项目，不同的具体的行业，以及不同的公司，对于这个问题的答案都不尽相同。如果团队的支持比较完善，PM也不需要特别强的专业背景。技术背景不是 PM 的硬性要求，但是对于不同的 PM 来说，具备一定的技术基础显然是一个加分项，这样也更能取得团队中的信任。实际上，更重要的是是否具有通用管理能力以管理一个大的团队。
那么，更进一步地，我想知道，正如之前所提到的，团队更希望的是所有人的分工明确，各司其职，那么是不是说，越是成熟的公司，PM 就越是强调管理能力，而PM的技术背景就越是不重要的呢？