1.1 在一个被认定为“足够好”的软件发布后，得到的用户反馈中，哪些是有用的？什么时候才能将这个软件优化到相对稳定的版本？

[GreyZeng]

在第一章概论中提到，软件工程的目标— 创造“足够好”的软件，并对其做了定义：

什么是好的软件？一些同学认为，所谓好软件，就是软件没有缺陷（Bug），所谓软件工程，就是把软件中的Bug都消灭掉的过程。这的确是抓住了软件工程的一个要素。和软件打交道的专业人士都知道软件有“Bug”（缺陷），软件团队的很多人都整天和Bug打交道，Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。 ——P15
很多人认为有Bug就是质量不合格，没有Bug就是质量完美，其实这也未必。我们在大街上看到很多小汽车，这些汽车出厂时都通过了各自的质量检测，符合行业的质量标准。但是你问路人哪些车的“质量好”，很多人会告诉你有些车的质量大大好于另外一些车，那为什么还有人买那些质量“不够好”的汽车呢？对于某些顾客来说，某一类的汽车满足了他们的需求，他们就会买。如果销售人员不经市场调研胡乱推销自己公司的汽车，最后销量未必理想。
市面上有这么多不完美的产品，软件团队为什么还要把这些不完美的软件发布出来呢？为什么不能等到它们完美之后再发布？**软件工程的一个重要任务，就是要决定一个软件在什么时候能“足够好”，可以发布。——P16

从书本中大概能了解到一个好软件，就是Bug尽可能的少。而书中定义的Bug即软件的行为和用户的期望值不一样。那么如果一个功能对于一部分用户来讲是十分好用的，而有一部分的用户认为这是不合乎自己的期望值的功能，那么此时这算不算是Bug,工程师需不需要解决优化这个Bug。在一个被认定为“足够好”的软件发布后，得到的用户反馈中，哪些是有用的？什么时候才能将这个软件优化到相对稳定的版本？

不同的人对不同的事物有不同的看法，那么倘若这个软件已经被80%的用户认为已经很完美了，那剩下20%所提的建议还是否需要采纳，按照反馈来修复这20%所认为的Bug呢？我个人认为，Bug是相对的，只有软件的行为和大多数用户的期望值不一样才叫做Bug。

倘若一个软件能让80%的用户喜爱上那便是成功的好软件。但是如果那20%的用户提出的一些更加细致化功能化的模块时，程序员是否应该当做Bug来完善，这样会不会导致整个程序为了小部分的精致要求变得越来越复杂，到最后由小认知阻力的软件成长为一个大认知阻力的软件呢？

原文地址

[SoftwareTeacher]

@GreyZeng 希望产品团队能从历史中吸取教训，不犯同样的错误。

[GreyZeng]

@SoftwareTeacher windows 11 会不会是下一个 windows 8？

[SoftwareTeacher]

这样会不会导致整个程序为了小部分的精致要求变得越来越复杂

---

你可以看看手机版的微信app 的变化。 另外，WindowsOS， MacOS 的界面都一直相对固定，并且有一个版本的 Windows 还把 “开始菜单” 删除了，但是 OS 本身还是越来越大，越来越复杂。 为什么呢？