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

项目	内容
这个作业属于哪个课程	2026春季软件工程
这个作业的要求在哪里	[l.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件的系统开发流程，通过团队合作完成软件
这个作业在哪个具体方面帮助我实现目标	迅速了解课程目标

《构建之法：现代软件工程》阅读后的五个疑问

问题一：在AI编程工具普及的当下，"单元测试"到底该谁来写？

引发思考的章节：第2章 个人技术和流程

书中第2.1节花了不少篇幅讲单元测试的重要性，说好的单元测试要覆盖各种边界条件，程序员应该在编码的同时甚至之前就把测试写好，还提到了"测试驱动开发"（TDD）的理念——先写测试再写代码。这些我都觉得挺有道理的，单元测试确实是保证代码质量的基本功。

但问题是，这本书写作的时候AI编程工具还没有像现在这么普及。到了2026年的今天，GitHub Copilot、Cursor这些工具已经可以根据函数签名直接帮你生成质量还不错的单元测试了，覆盖率有时候甚至比我自己手写的还高。那我就很想问了：既然AI都能自动生成测试了，程序员还有必要自己一行一行地写吗？TDD那套"通过写测试来想清楚需求和接口"的思路，让AI代劳之后还剩下多少价值？

我比较担心的是这种场景：写完代码以后让AI一键生成测试，跑一遍全过了，然后就觉得万事大吉提交了。但仔细想想，AI生成的测试很可能是"顺着你的代码逻辑来的"，你代码里没考虑到的边界情况，它大概率也想不到。说白了就是覆盖率数字好看，但真要靠它来揪出程序员自己的思维盲区，恐怕不太行。所以我觉得在AI时代，单元测试的玩法可能得变一变了——比如让人来想测试的核心逻辑，AI负责补充边界用例，这种人机搭配的模式会不会更靠谱？书里关于单元测试的那些经典做法，哪些是不管技术怎么变都不会过时的"内核"，哪些又是该随着工具进步而更新的"外壳"？

问题二：PSP（个人软件过程）的详细记录，真的值得花那个功夫吗？

引发思考的章节：第2章 个人技术和流程

书中第2.3节介绍了个人软件过程（PSP），大意是程序员应该详细记录自己开发过程中的时间分配和缺陷情况，比如设计花了多久、编码花了多久、引入了几个bug、每个bug修了多长时间之类的。书里认为坚持做PSP记录能帮你摸清自己的效率规律，以后估算项目时间也更准，算是一种持续自我改进的方法。

道理是这么个道理，但说实话我自己试过，体验不太好。课程作业里我尝试过记录开发时间，结果发现一个很尴尬的事情：记录这个动作本身就在不断打断我。正想着一个比较复杂的算法怎么写，突然得停下来在表上填"13:22到13:45，设计阶段"，思路直接就断了。心理学上管这种状态叫"心流"，一旦被打断要重新进入是很费劲的。我后来查了一下，PSP这套东西最早是卡耐基梅隆大学的Watts Humphrey提出来的，他自己也说过这是需要长期训练才能养成习惯的。可现实情况是，互联网行业节奏这么快，到底有几个程序员真的在坚持用PSP？现在GitHub的Commit记录、WakaTime这类IDE时间统计插件，其实已经能自动帮你记下不少信息了，是不是某种程度上已经替代了手动PSP？

我并不是说PSP完全没用，但总觉得书里把它说得太好了，实际上手成本挺高的。我想搞清楚的是，在现在这个开发环境下，PSP的价值边界到底在哪儿？什么情况下值得投入精力去做，什么情况下用现成的自动化工具凑合一下就够了？

问题三：软件团队中"主治医师模式"真的就过时了吗？

引发思考的章节：第5章 团队和流程

书中第5.2节列了好几种软件团队的组织模式，什么主治医师模式、明星模式、社区模式、业余剧团模式、功能团队模式等等。其中"主治医师模式"来自《人月神话》里Brooks提的"外科手术队伍"——就是一个最强的程序员（相当于主刀医生）负责核心架构和关键代码，其他人都围着他转，打辅助、写工具、搞文档。书里的态度大概是觉得这种模式太依赖个人英雄了，不太适合现在的大型项目。

但我自己观察到的情况好像不完全是这样。你看Linux内核，这么多年不一直是Linus Torvalds拍板大方向吗？Python之前也是Guido van Rossum一个人当了那么久的BDFL（仁慈的独裁者）。就算是一些技术创业公司，CTO一个人定架构、其他人负责实现的模式也很常见，而且效率还挺高的。反倒是那些特别强调"人人平等、集体决策"的团队，我见过不少讨论了半天谁也说服不了谁的，最后什么也没决定。

所以我觉得问题的关键其实不在于"主治医师模式好不好"，而在于那个"主治医师"水平到底行不行，以及万一他判断失误了团队有没有纠错的办法。特别是在学生项目里，组员之间水平差距经常是很大的，这时候硬要搞"扁平化"分工，让一个刚学会写代码的同学和一个已经做过好几个项目的同学"平等讨论"架构方案，是不是反而在浪费时间？书里比较推崇功能团队这类均衡的模式，但我总觉得在团队小、水平参差不齐的时候，主治医师模式可能才是更务实的选择。不知道这个想法对不对。

问题四：敏捷流程是不是被"神话"了？

引发思考的章节：第6章 敏捷流程

书中第6章系统讲了敏捷流程，Scrum、Sprint、Backlog那一套都介绍了，还和传统的瀑布模型做了对比。敏捷的核心理念大概是"人和交流比流程工具重要""能跑的软件比齐全的文档重要""拥抱变化比死守计划重要"。书里第6.2节也提到了敏捷存在一些问题，给了一些应对方法。

但我总觉得这些年"敏捷"这个词已经被捧得有点过头了，圈子里谁要是说自己还在用瀑布模型，好像就显得很落后似的。可实际上呢？我了解到不少团队的所谓"敏捷转型"，搞到最后就变成了"没有文档的瀑布"——每天的站会沦为大家轮流念流水账，Sprint Review走个过场，Backlog堆了一大堆从来没人清理。而且有人指出，在需求明确、团队稳定的项目上，敏捷反而不如传统模型高效。像航天、医疗这些对安全性要求特别高的领域，你让人家"拥抱变化"？需求文档都得反复评审好几轮的那种。

书里虽然承认了敏捷有问题，但我感觉对它的局限性讨论得还不够到位。所以我想问的是：敏捷真的适合所有类型的软件项目吗？什么情况下老老实实用瀑布反而是更明智的？还有就是，当一个团队宣称自己在"做敏捷"，我们拿什么标准来判断他们是真敏捷还是只是挂了个牌子的混乱开发？书里语气上明显更偏向敏捷，我怕这会让读者产生一种"敏捷是万金油"的误解。

问题五："典型用户"（Persona）会不会变成团队自嗨的刻板印象？

引发思考的章节：第10章 典型用户和场景

书中第10.1节讲了"典型用户"（Persona）这个概念，就是开发团队虚构出几个有名有姓、有具体背景的用户形象，给他们设定年龄、职业、技术水平、使用习惯之类的属性，然后围着这些虚拟用户去设计功能和场景。书里还举了些例子，比如给搜索引擎设计不同的典型用户：学生、上班族、老年人之类的。

这个方法确实比空泛地说"用户需要XXX"要具体得多，听起来也更有画面感。但我有个顾虑：我们构建出来的Persona，到底是真实用户的合理抽象，还是只是反映了团队自己的偏见和刻板印象？比如说我们设定"大学生用户小明，喜欢打游戏，对新技术接受度高"——这就真能代表大学生了？我身边一堆同学对技术完全不感兴趣的。再比如写"50岁的张阿姨，不太会用智能手机"，但实际上现在五十多岁的人刷抖音、用微信支付比我还熟练的多了去了。

往深了说，Persona这个方法有个前提假设：用户可以被归成有限的几类。但真实的用户行为可能是连续分布的，哪有那么泾渭分明的几类人？微软那种大公司有海量用户数据，拿数据支撑着构建Persona好歹还有点根据。可对于我们这种学生团队或者初创小项目来说，Persona不就是几个人关在会议室里拍脑袋想出来的吗？我自己就有亲身经历——上学期课程项目里我们组也尝试做Persona，结果大家写出来的用户画像说是"用户"，看着更像"理想化的自己"，根本没跳出自身的视角。所以在缺少真实数据支撑的情况下，Persona到底是在帮我们聚焦需求，还是在制造一种"我们很了解用户"的虚假安全感？