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

个人作业1：阅读和提问

项目	内容
这个作业属于哪个课程	软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	深入学习软件工程，掌握其核心思想，增强自身团队合作能力，学会敏捷开发
这个作业在哪个具体方面帮助我实现目标	从理论角度带我入门软件工程，初步了解软工的核心思想

Q1：程序效能分析

​ 第一次点开邹欣老师的博客园讲义时，第二章的程序效能分析很是吸引我的眼球，很好奇一段代码的效能是如何通过自动化的方式进行效能分析的，以及效能分析能在软件开发的过程中起到什么作用。

​ 这一章节以VSTS效能分析工具作为实例，来介绍能效分析工具的测试方式，以及能效分析工具的作用。在阅读的过程中我产生了如下问题：

1. 除了VSTS还有那些能效分析工具，以及处理VSTS使用到的a.抽样分析法 b.代码注入（Instrumentation）分析法，还有哪些常用的分析方法。
2. 能效分析工具除了可以帮助工程师找到相关的“高能耗”代码，还有什么别的作用。

搜索相关资料后得到了一些比较满意的答案：

1. 通过调研我找到了一款专注于CPU、GPU、FPGA等硬件层面的能效分析工具，英特尔推出的高性能分析工具Intel VTune Profiler，以下简称为VTune。其主要通过以下四种方式进行能效分析：

   • 硬件事件采样（HPC）
     基于CPU硬件计数器收集数据，分析 缓存利用率、指令执行效率 等硬件相关瓶颈，例如：
     • L1/L2/L3缓存未命中率
     • 分支预测失败次数
     • 指令并行度（IPC）
   • 代码注入（Instrumentation）
     在编译阶段插入探针，精确统计 函数调用次数、执行时间，适合细粒度代码路径分析。
   • 时间线分析（Timeline Analysis）
     可视化线程、进程的活动状态，识别 线程阻塞、调度延迟 等问题。
   • 微架构分析（Microarchitecture Exploration）
     分析CPU流水线效率、前端/后端指令吞吐，优化指令级并行性（如循环展开、向量化）。

   硬件与软件不同，硬件使用的语言更加底层，因此测试方法也更加底层，我很高兴的观察到代码注入既可以用于底层，也可以用于上层应用的能效测试。

   在这个过程中我尝试让deepseek分析VTune和VSTS的异同，它给了我一段比较搞笑的回答，没有什么意义，但是不知道为什么它突然以第一视角来回答我的问题：

   我是Intel VTune Profiler，专注于硬件级性能分析和多平台支持，擅长通过硬件事件采样、微架构分析等方法深入挖掘CPU流水线效率、缓存行为及多线程瓶颈，特别适合高性能计算和底层优化场景。而我的同事VSTS（Visual Studio Team Services）则更专注于微软生态内的开发流程集成与团队协作，通过抽样分析和代码注入提供轻量级的应用层效能分析。虽然我在异构硬件支持与深度优化能力上更胜一筹，但VSTS在CI/CD集成和敏捷开发中更便捷——我们像工具箱里互补的工具，开发者可以按需选择，甚至结合使用，既满足底层极致优化，又能兼顾团队协作效率。
   

   在调研的过程中我也了解到了许多其他的能效分析工具（找那么认真是为了我之后能在软工中使用到）了解了许多能效分析的方法，看的最多的应该还是代码注入，针对于不同的代码有不同的注入方式，虽然代码注入是一种高能耗方法，但是也是相对来说能耗分析比较详细的一种方法，能帮助我快速精准的定位到高能耗高优化空间的代码上。

2. 调研的第一步，问AI（估计是目前大学生都会用的方法），我认为在很大程度上解决了我的问题：

   • 性能瓶颈诊断
     • 系统级资源分析：监控CPU、内存、磁盘I/O、网络等资源的使用情况，识别系统整体性能瓶颈。
     • 线程/进程调度分析：检测线程争用、锁竞争、上下文切换频繁等问题，优化多线程程序的并行效率。
   • 功耗与热管理
     • 功耗分布可视化：分析不同模块或时间段的功耗曲线，帮助优化设备热设计（如移动端或嵌入式系统）。
     • 动态电压频率调节（DVFS）优化：指导调整CPU频率和电压策略，平衡性能与能耗。
   • 长期运行稳定性验证
     • 压力测试中的能耗监控：模拟高负载场景，分析程序在长时间运行下的能耗稳定性。
     • 异常事件关联：将能耗突变与程序崩溃、日志错误等事件关联，快速定位问题根源。

   这三个作用是我觉得比较核心关键的作用，因此我将他们贴出来了。

调研完之后还是稍微有点疑惑，我虽然知道了代码注入的大概逻辑，但是在实际实现层面依旧留有困惑，不知道具体是如何实现的，但是目前对于我来说只要知道大概逻辑然后能够运用应该就够了，或许将来从事相关行业的时候能够有更加深入的了解吧。

Q2：结对编程

​ 最开始在群里看到结对编程这个词的时候还以为是打错字了，觉得应该是结”队“，也不是很理解为什么需要两个人一起组队进行开发，两个人和一组人有什么很大的区别，都会产生分歧和矛盾，也都需要沟通，那一组人不是更能锻炼沟通能力吗？

​ 但是看现代软件工程讲义 3 结对编程和两人合作我大概明白了结对编程的真谛——不断的复审，结对编程不只是两个人合作那么简单，而是两人使用同一台电脑，看同一个屏幕，一个作为编程手，一个作为复审员进行开发。看起来两个人变成合用一台电脑会降低开发效率，但是实际上有过上学期写上万行编译器的经历之后会发现，一个人的开发经常容易在写代码的过程中走神，而两个人的开发会强行提高另一个的效率同时也不会因为人数较多有摸鱼的机会，在这个过程中两个人能够互相学习对方的技术，取长补短。同时不断的复审还能在很大程度上提高代码的质量。

但是在阅读的过程中，我产生了一个问题：结对编程在理论上强调提高代码质量和团队协作，但在实际情况中，如何有效解决学生因性格差异或技能不匹配导致的合作效率低下问题？

我查了资料，有说法认为结对编程的成败取决于角色分配和沟通机制（如《Pair Programming Illuminated》中提到“互补技能组合比相似技能更有效”），也有研究指出强制结对可能引发抵触心理（ACM期刊案例，2018）。根据我的实践，在课程项目中尝试结对编程时，曾遇到一方主导、另一方被动跟随的情况，最终代码质量并未显著提升，反而因沟通成本增加了开发时间。
但是我还是不太懂，我的困惑是：
如果结对编程的核心是“平等协作”，那么在学生团队中（尤其是能力差异较大的情况下），如何通过具体的方法（如动态角色切换、任务拆分）避免“伪结对”现象（即形式化合作）？
例如，是否应引入第三方工具或流程（如定时强制交换角色、独立模块交叉复审）来确保双方实质性参与？这与作者提倡的“让程序员自主决定方式”是否存在矛盾？

Q3：敏捷开发

​ 在介绍敏捷开发的这一章节，我对MSF（Microsoft Solution Framework）很感兴趣，于是仔细的看了这一章节的内容，对引文中的阿超说的一句话印象深刻：”我们可以不用管MSF演化的细节，要记住所有模式都不是一成不变的，关键是要掌握变化的原因。“

​ MSF的八大基本原则围绕团队协作、项目管理和价值交付展开。主要有以下内容：

• 推动信息共享与沟通（Foster open communications）

• 为共同的远景而工作（Work toward a shared vision）

• 充分授权和信任（Empower team members）

• 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）

• 重视商业价值（Focus on delivering business value）

• 保持敏捷，预期变化（Stay agile, expect change）

• 投资质量（Invest in quality）

• 学习所有的经验（Learn from all experiences）

​ MSF原则强调透明协作、目标一致、权责对等和价值导向，通过工具和文化保障执行。其本质是在动态变化中平衡各方利益，而非机械遵循流程。例如，充分授权需工具支持，商业价值需用户深度参与，质量需长线投资而非短期投机。这些原则共同构建了高效、灵活的软件开发方法论。

​ 在阅读的过程中，我产生了一些疑问，作者认为授权能激发成员责任感并支持自下而上的计划制定。但我在实践中发现，当团队成员能力差异较大时，可能出现"授权陷阱"：比如初级程序员高估自身效率导致延期，或技术骨干因过度承担他人职责而burnout。文献中提到"授权需匹配能力评估"（如Tannenbaum-Schmidt领导力模型），但MSF未明确如何平衡授权与能力适配。我的困惑是：在缺乏成熟能力评估机制的中小团队中，如何避免"过度授权"带来的失控风险？是否应先建立能力基线再逐步授权，还是通过工具监控（如TFS任务追踪）强制弥补能力缺口？这似乎与MSF倡导的"信任优先"存在潜在矛盾。

Q4：团队合作与角色

​ 这一章节中我了解到了三个不同的角色——PM，Dev，QA。第五章的c，d，e章节

​ PM（项目经理）是项目全局的统筹者，负责需求管理、资源协调和进度把控，通过与客户沟通明确目标，并确保团队理解产品愿景。Dev（开发工程师）聚焦技术实现，负责代码编写、架构设计和功能交付，需遵循需求文档并主动反馈技术风险。QA（测试工程师）保障产品质量，主导测试用例设计、缺陷追踪和验收验证，需在需求阶段介入，持续与开发同步问题。

​ 三者协作贯穿全流程：需求阶段三方共同确认需求可行性，开发阶段QA同步编写测试用例并参与代码评审，测试阶段Dev及时修复缺陷，PM平衡需求变更与交付压力。日常通过站会同步进展，利用TFS/Jira等工具实现需求-任务-缺陷的闭环管理，形成“PM驱动目标、Dev构建方案、QA验证质量”的三角制衡。

​ 看了关于PM、Dev、QA角色分工的说明，发现传统理论强调三者通过文档交接形成"质量闸门"（如CMMI模型），但实际在敏捷团队中，QA过早介入Dev的开发阻碍原型迭代速度，而PM夹在中间难以平衡交付压力和质量控制。查阅DevOps文献发现"Shift Left Testing"主张QA全程参与需求评审，但实践中需求频繁变更导致测试用例维护成本激增。我的困惑是：当三者目标冲突时（如PM的进度红线、Dev的技术债清理、QA的回归覆盖率），是否存在比每日站会更有效的实时决策机制？是否需要引入第四方角色（如技术项目经理）协调，还是说这种摩擦本身就是敏捷迭代必要的张力？

Q5：靠谱的项目建议NABCD

​ 最后一个问题在课本的第九章第e节——《如何提出靠谱的项目建议》，最近我们的软工小组刚开完会，讨论了我们要做什么项目，项目的整体规划，在讨论过程中我发现”提出靠谱的项目建议“是一件相对较难的事情，不仅需要你有足够的经验，还需要对自己的建议有完善的思考，能够经得起组员的推敲，因此在讨论过程中，主要的项目建议都是由两位比较有经验且逻辑思维过人的同学提出的。我不是这两位同学之一，这也是我为什么仔细看这一章节的原因hhh

​ NABCD可以拆分为：

• N (Need 需求)：你的创意解决了用户的什么需求?
• A (Approach 做法)：找到了用户的痛苦, 下一步, 得看看你有什么招数, 特别是独特的招数, 来解决用户的痛苦。
• B (Benefit 好处)：这个产品/服务会给客户/用户带来什么具体好处呢?
• C (Competitors 竞争)：充分考虑竞争对手，思考产品的竞争力
• D (Delivery 交付， Data 数据） ： 怎样把你的创新产品交到用户的手中?

但是看完空泛的概念之后，我产生了如下问题：

1. 需求验证的矛盾：
   文中提到要找到用户的“刚性需求”，但用户可能无法主动表达颠覆性需求（如福特发明汽车前的马车用户）。
   • 我的实践：我曾尝试通过问卷调研用户需求，但发现结果表面化（例如用户说“需要更好的时间管理工具”，但实际可能只是现有工具的重复）。
   • 困惑：如何平衡“用户明确表达的痛点”与“用户未意识到的潜在需求”？是否存在更有效的方法（例如观察用户行为而非直接提问）？
2. “做法”与“能力”的落差：
   文中要求团队提出“独特招数”，但学生团队技术能力有限（如仅掌握基础编程），可能难以实现技术壁垒。
   • 我的经验：在课程项目中，我们曾试图用机器学习优化校园食堂排队问题，但因数据量和算法能力不足而失败。
   • 问题：如何定义“独特招数”？是否允许整合现有技术（如调用API）而非完全自主创新？若团队能力不足，是否应调整需求而非硬扛技术难点？

总结下来就是：NABCD框架看似系统，但对缺乏经验的学生团队，如何将其转化为可落地的行动步骤（例如：如何低成本验证需求？如何量化“好处”？）可能比理论更关键。是否应结合更具体的工具（如精益画布、MVP设计）来补充这一框架？

总结

​ 在开始第一次作业之前，我不知怎的饶有兴致的看起了往届学长学姐的第一次作业，作业题目是——[2020BUAA软工助教]第1次个人作业 - 分解 - 博客园。主题是阅读软件工程师的成长经历，然后总结出一篇自己的个人经历或者根据自己的经历谈谈感想。从个人的角度来看，我觉得往届的选题要比这一届更有意思，也能带来更多的反思。很喜欢一位不知道是学长还是学姐的前辈写的一篇停下来，回头看 ——记2020BUAA软工第一次作业-热身！ - CookieLau - 博客园，从ta的文字里我能感受到和我现在一样的迷茫，和ta一样对大牛前辈的敬仰，同时ta的文章也给我带来了很多思考，很赞同ta文章中对大学意义的见解：”科研是兴趣驱动、兴趣导向的，单纯有能力可能会学的很好，但未必学的很高。在学校的实验室的试错成本要比到时候步入社会了时候的犯错成本低得多。若能在学校的期间就发现自己的真正未来方向所在，我觉得大学实习的意义已经达到的差不多了。“学生时期的是试错成本，而步入社会后外面需要面对的就是犯错成本了。当时的实习还可以选择在学校的实验室里实习，现在只能到外面去实习了，但是相比于已经步入社会的人士，我们依旧有足够的成本去试错，希望我们能在有限的大学时光里用较低的成本发现自己未来的方向吧。