| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 北航2026春软件工程 |
| 这个作业的要求在哪里 | 个人作业：阅读和提问 |
| 我在这个课程的目标是 | 了解、熟悉软件工程开发一般流程和方法，与团队共同完成软件项目，提高团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过阅读《构建之法》，系统性地了解软件开发一般流程和通用范式，为以后的开发工作通过方向性指导 |
阅读提问
一、代码注入到底怎样分析效能？
在《构建之法》的第2.2节 效能分析工具中第31页中写到：
另一方面，代码注入就是将检测的代码加入到每一个函数中，这样程序的一举一动都被记录在案，程序的各个效能数据都可以被精准地测量。
即便教程似乎对于“代码注入”这种分析方法进行了详细阐释，但是在阅读完整个章节后，我依旧对于“代码注入”这个术语不太理解。
而在查阅资料后，我终于了解到：“代码注入”是修改程序源代码，将源程序功能之外的具有监控作用代码粗暴地插入源程序功能代码中。例如对于以下代码：
def calculate_sum(arr):total = 0for num in arr:total += numreturn totalnumbers = [1, 2, 3, 4, 5]
result = calculate_sum(numbers)
print(f"总和: {result}")
注入监控代码后变为：
import time
call_count = 0
total_time = 0
def calculate_sum_instrumented(arr):global call_count, total_time# 注入点1：函数开始，记录开始时间start_time = time.time()call_count += 1total = 0for num in arr:total += num# 注入点2：函数结束，计算耗时end_time = time.time()elapsed = end_time - start_timetotal_time += elapsedreturn totalnumbers = [1, 2, 3, 4, 5]
result = calculate_sum_instrumented(numbers)
print(f"总和: {result}")
print(f"函数被调用了 {call_count} 次")
print(f"总执行时间: {total_time:.6f} 秒")
在理解代码注入的具体工作方式后，我终于理解了为什么教材后面指出“这一方法的缺点是程序的影响时间会大大加长”，显然注入的代码需要CPU时间影响，需要额外内存开销，甚至会影响编译器的优化功能。
二、“过早优化”真的是罪恶的根源吗？
在《构建之法》第3.2节 软件工程师的思维误区的49页写到：
既然软件是“软”的那它就有很大的可塑性，可以不断改进。放眼望去，一个复杂的软件似乎很多模块都可以变得更好。一个工程师在写程序的时候，经常容易在某一个局部问题上陷进去，花大量时间对其进行优化，无视这个模块对全局的重要性甚至还不知道这个“全局”是怎么样的。这个毛病早就被归纳为“过早的优化是一切的根源”。
教程认为过早的优化（例如开发过程中对某个功能进行优化）是“罪恶的根源”，并将其总结为软件工程师的的思维误区。我对于该观点基本认同，如果不考虑重要性，对于某个模块进行无止境的优化确实会导致严重后果。
但是我认为对“过早优化”这一概念需要辩证看待。“过早优化”源于Donald Knuth，原始完整论述是 “程序员们浪费了大量的时间去思考或担心他们程序中非关键部分的速度，而这些在调试和维护方面的尝试实际上产生了强烈的负面影响。我们应当忘记微小的效率提升，大约 97% 的时间都该如此：过早优化是万恶之源。”我认为这句话的重点是对“非关键部分”的优化带来的“微小的效率提升”。所以我认为在工程早期，面向全局和关键路径的架构与设计优化，不仅不是“罪恶”，反而是明智和必要的。
三、提高技能一定要先解决低层次问题吗？
在《构建之法》第3.3节 技能的反面的第57页中写到：
那怎么提高技能呢？答案很简单，通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。
结合教材前面的论述，不难理解这里的低层次问题是诸如数组如何定义的编程基础语法问题。
或许在几年前这样的理解是明智的，但是在当下AI盛行的时代，这一前提已被颠覆。如今，借助Copilot、ChatGPT等工具，开发者能即时跨越语法障碍，无需将其“练成自动操作”。低层次问题可随时交由AI解答，从而使人们能直接调动设计模式、架构思维等高层次通用经验，快速切入并解决复杂的实际问题。传统的线性进阶路径，在智能辅助下已显得低效而过时。
四、好的产品设计需要的是简单的“同理心”吗？
在《构建之法》第12.1节 用户体验的要素的第251页中写道：
什么是同理心？就是理解别人的处境、心理、动机的能力。西方谚语Put yourself in other people's shoes.正是此意。设计不同于传统的数学题，是没有唯一的标准答案的。有一颗为用户着想的“同理心”，是好的产品设计的出发点。
结合教材后面提到的假币投诉邮件地址和微软拼音输入法例子可知，这里的指的是软件开发者需要考虑到用户的体验。但是我认为这些例子中的软件开发者缺乏的不是一种同情的能力，他们缺乏的是对于用户反馈的重视，对于项目实际运行中的问题的忽视，是主观的，而同理心也是主观地去“猜想”用户体验，而我认为真正重要的是客观接受用户的反馈。因此，好的产品设计不应止步于主观的“推己及人”，而更需建立客观反馈的畅通渠道。真正的用户思维，不仅要求开发者怀有共情的初心，更要主动收集数据、倾听声音，并将反馈转化为产品的切实改进。唯有如此，“同理心”才不会沦为空中楼阁，而是扎根于真实的用户土壤之中。
五、为用户简化操作就一定让用户满意吗？
在《构建之法》第12.1节 用户体验的要素的第260页中写道：
“不让用户犯简单的错误”(Foll Proof)的原则当然是大多数人都同意的，高明的设计能让操作者不需要花费额外的注意力，也不需要经验和专业知识即可凭直觉完成正确的操作。
诚然，我同意一个优秀的软件能够让用户快速地掌握并使用，这是简化用户操作的结果。但是我认为并不是所有的简化为用户带来的体验都是正面的，我认为只有不侵犯用户的自主选择的权力的情况下，为用户简化操作、甚至“一键”完成想要的操作才是合理的。
而为用户简化操作简化地“太好了”，以致于用户都不需要任何思考就能够完成“想要的”操作，我认为不亚于绑架。一个典型的例子就是“摇一摇”广告，用户无需点击，只要设备识别到移动就立即跳转至广告详情页面。广告一经推出，立即收到了铺天盖地的声讨，创意提出者也收到了友好的问候。所以我认为这里的操作简化必须守住给用户选择权的红线，为用户留足思考时间。