607
社区成员
在第一章概论中提到,软件工程的目标— 创造“足够好”的软件,并对其做了定义:
什么是好的软件?一些同学认为,所谓好软件,就是软件没有缺陷(Bug),所谓软件工程,就是把软件中的Bug都消灭掉的过程。这的确是抓住了软件工程的一个要素。和软件打交道的专业人士都知道软件有“Bug”(缺陷),软件团队的很多人都整天和Bug打交道,Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。 ——P15
很多人认为有Bug就是质量不合格,没有Bug就是质量完美,其实这也未必。我们在大街上看到很多小汽车,这些汽车出厂时都通过了各自的质量检测,符合行业的质量标准。但是你问路人哪些车的“质量好”,很多人会告诉你有些车的质量大大好于另外一些车,那为什么还有人买那些质量“不够好”的汽车呢?对于某些顾客来说,某一类的汽车满足了他们的需求,他们就会买。如果销售人员不经市场调研胡乱推销自己公司的汽车,最后销量未必理想。
市面上有这么多不完美的产品,软件团队为什么还要把这些不完美的软件发布出来呢?为什么不能等到它们完美之后再发布?**软件工程的一个重要任务,就是要决定一个软件在什么时候能“足够好”,可以发布。——P16
从书本中大概能了解到一个好软件,就是Bug尽可能的少。而书中定义的Bug即软件的行为和用户的期望值不一样。那么如果一个功能对于一部分用户来讲是十分好用的,而有一部分的用户认为这是不合乎自己的期望值的功能,那么此时这算不算是Bug,工程师需不需要解决优化这个Bug。在一个被认定为“足够好”的软件发布后,得到的用户反馈中,哪些是有用的?什么时候才能将这个软件优化到相对稳定的版本?
不同的人对不同的事物有不同的看法,那么倘若这个软件已经被80%的用户认为已经很完美了,那剩下20%所提的建议还是否需要采纳,按照反馈来修复这20%所认为的Bug呢?我个人认为,Bug是相对的,只有软件的行为和大多数用户的期望值不一样才叫做Bug。
倘若一个软件能让80%的用户喜爱上那便是成功的好软件。但是如果那20%的用户提出的一些更加细致化功能化的模块时,程序员是否应该当做Bug来完善,这样会不会导致整个程序为了小部分的精致要求变得越来越复杂,到最后由小认知阻力的软件成长为一个大认知阻力的软件呢?
这样会不会导致整个程序为了小部分的精致要求变得越来越复杂
你可以看看手机版的微信app 的变化。 另外,WindowsOS, MacOS 的界面都一直相对固定,并且有一个版本的 Windows 还把 “开始菜单” 删除了,但是 OS 本身还是越来越大,越来越复杂。 为什么呢?