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

个人阅读作业

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	I.1 个人作业：阅读和提问
我在这个课程的目标是	学习软件开发相关的知识，并且与同学一起完成一个软件工程项目，培养和锻炼个人能力
这个作业在哪个具体方面帮助我实现目标	了解软件工程相关的一些基本知识，并且有一个比较系统的理解

1. 小团队里，康威定律还会明显体现出来吗？

讲义里说“一个机构设计出来的系统，它的体系结构注定会沿用这个机构的内部交流模式”，那如果是学生课程项目这种小团队，大家分工并不稳定，康威定律还会很明显地体现出来吗？如果团队成员经常临时换任务、谁有空谁上，最后做出来的软件会不会更容易变成“拼接式”的系统？这个问题是我看讲义里讲康威规律时想到的，原文里写到“一个机构设计出来的系统，它的体系结构注定会沿用这个机构的内部交流模式”，后面还说“组织之间的交流方式，会极大地影响系统的设计”，以及“一个合适的团队结构，能更大地改进交流的效率”。我看到这里就联想到自己接触过的一些课程作业，前端同学只管页面，后端同学只管接口，数据库同学最后单独补表结构，结果系统虽然能跑，但模块之间像是硬拼起来的，接口命名、异常处理、字段风格都不统一。网上讨论微服务时，也经常有人提到团队边界会影响服务划分。所以我提这个问题，主要是因为书中的描述和我的经验是能对上的，但我还不确定它在小团队里是不是也同样明显，我想追问一下它的适用范围。

2. “愿意试用”到底怎么判断才不流于形式？

讲义里说，找到至少 10 个潜在用户，并且他们表示“愿意试用”，才算比较靠谱地找到了 Need。那这里的“愿意试用”到底应该怎么判断才不流于形式？如果只是同学口头说“可以试试”，这种算不算有效证据？原文里说“这些事情光靠拍脑袋和拍胸脯是不够的”，后面又写“找到10个潜在用户，他们表示‘一定会试用你的软件’，那么就算你找到了合适的需求”。我会追问这个标准，是因为它看上去很具体，但在实际里又很容易变空。比如学生项目最常见的情况就是问朋友一句“如果有这个 App 你会不会用”，对方一般都会顺口说“会啊”，可等真正做出来以后，可能根本没人下载，更别说持续使用。像备忘录、打卡、自律类产品其实已经很多了，很多人也会说自己需要，但真正长期使用的人并不多。我之前也看过一些产品调研经验分享，里面提到比起问“你想不想要”，更应该问“你上次遇到这个问题是什么时候”“你现在怎么解决”，因为真实行为往往比口头表态更可靠。

3. 建模到底做到什么程度才算够用？

讲义里介绍了 ERD、DFD、UML、Flow Chart 等很多建模方法，但在真实开发里，尤其是小项目里，究竟做到什么程度才算“够用”？如果图画得很多、很完整，但最后代码还是频繁改，那这些图的投入值不值得？这个问题主要是看“图形建模和分析方法”时想到的。原文先说，软件团队里的相关人员都要处理和了解这些信息，如果在处理过程中有误解和遗失，就会导致产品不能满足用户需求，所以建模当然是有价值的；后面又说“UML 就是这样的回答”，但同时又引用 Joshua Bloch 和 Peter Norvig 对 UML 工具并不热衷的看法，这就让我有点犹豫。因为我自己做小作业时，一开始也画过用例图、流程图，可后面需求一改，图基本就没人更新了，最后真正靠谱的反而还是代码和接口文档。很多开源项目也没有完整的 UML 图，但照样能靠 README、架构说明和测试文档协作下去。反过来，有些课程作业图画得很漂亮，可一问具体实现，组员自己也说不清楚。所以我提这个问题，是因为书中的推理和我的经验之间有一点张力，我并不是不懂这些术语，而是想知道图到底什么时候是真有帮助，什么时候又会变成额外负担。

4. 学生项目里的 Delivery 和 Data 到底怎么落地？

NABCD 里后来又加了一个 D，既包括 Delivery，也包括 Data。那如果一个学生团队现在还没有真正上线产品，也拿不到很多真实数据，怎么做才算对 D 有比较可信的说明？是不是只能停留在想象层面？讲义原文里写“在练习了多次的 NABC 之后, 我意识到也许还应该加一个D: Delivery。怎样把你的创新产品交到用户的手中”，后面又问“用户怎么能知道你的产品”，还提到“你有什么数据来证明新的功能带来的好处”。我觉得这部分一下就把问题从“能不能做出来”推进到了“能不能真的被别人知道和使用”。但从学生项目的经验来看，很多作品其实只是在答辩时演示一下，真正的用户入口、传播渠道、留存数据、复访数据都没有，这样的话，说“我们能高效触达用户”很容易变成空话。再比如很多 App 上线以后才发现，下载量不等于活跃用户，活跃用户也不等于愿意长期使用。如果没有埋点、问卷、访谈、回访这些数据，只看“有人点开过”，其实很难说明产品真的有效。所以我会提这个问题，主要是因为我知道 Delivery 和 Data 这两个词是什么意思，但我不太确定它们在我们做的好像很难真正应用的这些学生项目里到底应该怎么落地，做到什么程度才不算空写。

5. 明知道需求不道德时，现实里真的能直接拒绝吗？

当软件工程师明知道一个需求在道德上有问题，但这个需求又是公司、老师、客户明确要求的，这时候“应该拒绝”在现实里到底能做到多少？如果拒绝会影响实习、工作或者成绩，那软件工程师应该怎么处理？这个问题是我看讲义里举一些的例子想到的，比如“一个程序员奉命实现一个功能, 把用户机器上的另一个公司的程序给卸载掉”，还有“一个程序员写了一个手机游戏软件, 然后把用户的通讯录信息悄悄上传”，后面又引用 IEEE/ACM 的规范，说软件工程师应当让这个职业成为“beneficial and respected profession”，并强调“PUBLIC - Software engineers shall act consistently with the public interest.” 这些原则我当然是认同的，但我也会想到现实里的一些例子，比如以前网上争议很大的全家桶安装、默认勾选附加软件、偷偷收集用户信息，还有抢票插件、抢课脚本之类的东西，技术上都能做出来，可道德评价并不一致。尤其是对新人、实习生和学生来说，很多时候并没有那么大的决定权，所以我会追问，除了原则上说“应该拒绝”，现实里有没有更可操作的做法，比如保留记录、向上反馈、推动团队讨论风险之类。就是想不明白，主要是因为讲义里的原则性表述和现实经验之间有一点冲突感，想要知道它们到底怎么才能真正的在现实的工作之类的里面实施。