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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程知识，通过团队协作开发一个具备实际应用价值的软件，从需求分析、设计、开发到测试和部署，完整经历软件开发生命周期，提高工程实践能力。
这个作业在哪个具体方面帮助我实现目标	认知并理解软件项目的开发流程和规范

问题一：如何在保持封装性的前提下测试私有方法？

书中提到：

单元测试应该覆盖所有代码路径，包括错误处理路径，为了保证单元测试的代码覆盖率，单元测试必须测试公开的和私有的函数/方法。

· 我的经验：

在编写单元测试时，我们通常会进行已经对外暴露接口的公开方法的测试，确保它们在各种输入下的正确性。然而，对于私有方法，由于被层层封装与方法内部的复杂逻辑，比较难以直接进行单独的测试。

· 我的疑问：

如何在不破坏封装性的前提下，确保私有方法的正确性？是否有最佳实践来间接测试这些私有方法，或者在某些情况下直接测试私有方法是可以接受的？

问题二：结对编程中如何进行合理的角色分工与合作效率？

书中提到：

结对编程要求两位程序员肩并肩工作，其中一位担任驾驶员，另一位担任导航员，两者需要不断切换角色，实现即时反馈和高质量代码的双重保障。

· 我的经验：

在项目团队建立时，我们往往会寻找能力互补的伙伴组队，以使得团队整体的技术实力和技术面最大化，尤其是在建立小团队时。

但是结对编程中，却要我们和队友一起完成相同的开发，因此这能只在我们技术栈的交集中发挥最大的作用，而交集之外的“个人特长”对项目的交付流程甚至更加至关重要，却不能通过结对编程展开，导致角色固化

· 我的疑问：

1. 是否在团队组建初期就要考虑到结对编程，以此指导招聘策略？
2. 在实际项目中，如何科学地调整与切换驾驶员与导航员的角色分工，确保双方都能充分发挥各自优势？
3. 当团队成员技能水平存在较大差距时，如何避免“角色固化”，让经验较少的一方也能快速成长，而不会影响整体开发效率？

问题三：实践中对敏捷开发方式的选择是否真的“敏捷”？

书中提到：

敏捷 (Agile) 是一股思潮, 它包括了好几种软件开发的方法论 (methodology); 这些方法论又是建立在许多业界证明行之有效的最佳实践方法 (best practices) 上面的。 如图所示:

· 我的经验：

在过去的开发经历中，由于缺乏“客户”的持续存在，我们实际上很少变更功能或受到交付期限的限制，导致对敏捷开发不能充分地实践，而现在需要进行敏捷开发时，又发现“敏捷开发”集成了多种开发的方法论。

而在众多方法中选取最适合自己项目的开发方式是一个很麻烦的过程，而且大多数方式都用于提高软件项目在整个开发流程中的质量，无法在一开始区分出优劣

· 我的疑问：

是否有一些公认的技术路线，而非大杂烩式的选择，让新手尽快上手敏捷开发，以避免在众多开发方式中反复选择浪费时间，反而背离了“敏捷”？

问题四：SCRUM、MSF等方法对团队的自组织与跨职能协作是否要求过高？

书中提到：

SCRUM：

Scrum对团队的要求很简单：self-managing， self-organizing， cross-functional， 但是这很难做到。软件项目的团队各式各样 (各种团队类型的介绍)， 假设一个团队做得还不错，现在要变成 Scrum 流程, 那团队要做下么的改变:
Self-managing: 以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次sprint 结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自我管理”不等于“没有管理”。
Self-organizing: 以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
cross-functional: 以前spec 由PM 来写, test 由测试人员来做, 现在每个人都全面负责，自己搞定spec, 和别人沟通, 同时自己搞定测试。

MSF：

充分授权和信任
这一点的关键是“授权”这个词，英语是Empower，是什么意思呢？
授权（Empower）有两个意思：一是给某人权力和权威（Give authority to somebody：to give somebody power or authority）；二是给予某人更多自信和自尊（Inspire somebody with confidence：to give somebody a sense of confidence or self-esteem）。
在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权力在自己的职权范围内按照他们自己的承诺完成任务，同时，他们也充分信任其他同事也能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划。

· 我的经验：

SCRUM和MSF对团队的组织方式都描绘出近乎于“乌托邦”的构想，即不需要自上而下的规定，每个开发者都能自主地负责好自己的部分，并为团队做出贡献。

然而，在实际的雇佣关系中，设定严格的规章制度、时间节点与考核才是更多团队的选择

· 我的疑问：

在实际的项目团队中，更多是雇员而非自发的爱好者，在这样的团队里，是否SCRUM和MSF只是理想的标准？

在进行层级组织与严格监督的团队中，实施SCRUM和MSF的想法会不会导致效率下降与流程不好管控？

结对编程中能否使用SCRUM或MSF的思想？

问题五：在实际项目中的用户设计里，该如何展示软件的各种功能才能满足差异化的需求？

书中提到

01 可视性原则
系统状态有反馈，等待时间要合适
02 系统界面符合现实惯例
使用用户语言而不是开发者语言，贴近生活实际而不是学术概念或开发者的概念。
03 用户有自由控制权
操作失误可回退
04 一致性和标准化
同一事物和同类操作的表示用语要各处保持一致
05 预防用户出错
关键操作有确认提示，及早消除误操作
06 减少记忆负担
识别胜于回忆，提供必要的信息提示（可视&易取），减少记忆负担
07 使用效率和灵活性
为新手和专家设计定制化的操作方式，快捷操作可调整。
08 易读性
减少无关信息，体现简洁美感
09 帮助用户识别，诊断并修复错误
给用户明确的错误信息，并协助用户方便的从错误中恢复工作
10 提示和帮助文档
无需文档就能流畅应用当然更好，一般地文档很必要，而且也提供便利的检索功能，从用户的角度出发描述具体步骤，并且不要太冗长。

· 我的经验

在一个软件交付给广大的用户手中时，随着用户的增长，软件的所有功能不可避免地都会被使用到。

无论软件提供什么样的封装层级，在用户数量足够大时，总会有用户需要浅显的封装层级之下更深层的功能需求，而且这类用户往往是软件的目标群体

典型例子：编译器的编译选项、搜索引擎的高级过滤等

· 我的疑问

软件的用户交互设计有减少记忆负担、易读性等要求，所以商业化软件基本都采用简洁的交互界面，让用户以最直接便捷的方式使用软件的主要功能。

但在这样的情况下，如果有“资深用户”由于自身的需要，就需要体验更复杂的流程去获取到更深层的功能入口，“为新手和专家设计定制化的操作方式，快捷操作可调整”也在大多数时候也很难在功能的层面进行界定。

因此，如何科学地解决用户界面面向不同用户展示不同功能的矛盾，如何在商业推广与服务目标客户中找到平衡点？"自定义一切"固然可行，但是否为所有人增加了更多的负担？