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

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

项目	内容
这个作业属于哪个课程	2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	了解现代软件工程的思想和开发方法
这个作业在哪个具体方面帮助我实现目标	熟悉软件工程的基本概念和流程

Q1、如何量化判断一项创新技术是否值得发展？

IT 行业的创新 - 创新的迷思 (5-6)

这就是著名的Iridium铱星计划的手机, 它的确凝聚了多种先进的技术, 看似简明的思想 – 我只用往天上发 66 颗卫星, 把地球全覆盖了, 大家就可以随时随地打电话了。这比在地面上每隔几十公里就建造一个手机基站要好不知多少倍, 对吧!
不幸的是, 这个服务在1998 年开始, 不到一年的时间就申请破产保护了。

“铱星”使用卫星通话的技术让我想到了当下火爆的“星链”，两者使用了类似的技术，而前者的出现时间却要早上几十年。“铱星”的创新诚然有高超的技术力支撑，但因为缺少配套的需求最终泯然众人。
我们在设计软件时，总是强调创新开发，但如何去衡量一项创新是有价值、有市场的呢？一项技术的普及，到底是其高技术力创新的胜出，还是市场博弈中的幸存者偏差？

Q2、AI可以作为技能的替代，解决“低层次”问题吗？

技能的反面

你发现他把时间都花在“解决 (低层次) 问题”上了, 你想考察的“算法技能”、“C#程序设计技能” 都无暇顾及。注意, 这是在他认为非常精通的编程工具和编程语言中出现这样的问题。你要这样的员工么?
那怎么提高技能呢? 答案很简单, 通过不断的练习, 把那些低层次的问题都解决了, 变成不用经过大脑的自动操作, 然后才有时间和脑力来解决较高层次的问题。

文中这里把编程语言的语法等称为“低层次”问题，认为技能就是让我们把“低层次”问题变成不用经过大脑的自动操作。在人工智能高度发展的现在，让LLM写一个没有语法错误的程序并不困难。那么此时程序员可以只专注于解决高级的问题吗？即一个精通数据结构、算法、软件工程的程序员是否具有了不需要自己写一行代码，只需要负责上层设计也能开发一个好软件的能力？
GitHub最近涌现的高星项目不乏这样的例子，也许它们与好软件的要求还差了一段距离，但随着AI实力的增强和更多有能力程序员的产出，实现这个目标想必不在话下。

Q3、从小处着手解决问题和不要重复造轮子是冲突的吗？

软件工程 之 画扇面

解决大问题固然让然感觉美妙, 但是把小问题真正解决好, 也不容易, 我们回头看看博客园, csdn 等IT人士云集的网站, 每天都有很多巨大的新想法、惊世骇俗的评论冒出来, 争论美女/张飞/巨石的重构问题, 对一些通用的框架/平台发出一些人云亦云的评论, 等等。这些文字, 大多数会转化为墨水, 把扇面涂黑, 让后人在上面写下金字。

作者在这一节鼓励我们开发时设置一个明确的小目标，但是软件开发者的社区如此庞大，很难有哪些真正的小问题是没有被人涉及过的，此时继续我们的开发与不要重复造轮子的理念是冲突的吗？如果为了避免重复造轮子又去给我们的设计添加新的目标，是否又踏入了“画扇面”的陷阱？

Q4、对于实际生产中不会触碰到的边界情况，是否有必要单独考虑？

现代软件工程讲义 9 测试 关于闰年的测试

在1950-70年代, 很多程序用两位数字表示年份 (00–99), 那些聪明的程序员认为这已经足够了, 没想到这些程序和设计影响了很多要和它们兼容的程序 (就像 Excel 要兼容 Lotus 1-2-3 那样), 到了1990年代后期, IT 业花了很多人力物力来解决 Y2K 的千年虫问题。

这里提到了经典的千年虫问题，对于当时的程序设计人员而言，他们没想到自己的程序可以运行到千禧年，也就没有考虑对应的情况。那么对于测试人员而言，设计一个看似无用的测试场景是必须的吗？这到底是给程序开发套上了一具枷锁，还是宁可错杀一万也不放过一个的严谨？

Q5、用户调研真的能导向真正的创新吗？

现代软件工程讲义 6 用户调研

我们在开发软件的时候，总想知道用户到底想的是什么, 对各种功能的偏好是什么, 掌握这些信息，我们就可以按部就班地去满足用户的需求。大家可以靠直觉，靠老板的命令，靠互联网上传来的各种信息，靠拷贝其它软件, 靠其它不靠谱的手段… 当然我们也可以靠一些经过实践证明行之有效的办法。

教材详细介绍了如何通过调研获取用户需求。但在现实行业中，不乏有因为过于听取用户意见却起了反效果的例子。在软件工程中，过度依赖用户调研和反馈循环，是否会导致产品设计陷入“局部最优解”，甚至是发生退步？