读《构建之法》思考后有感
这几天读了《构建之法》第一、二、十六章，感触颇深，作者从自身的教学经历和项目工程经验出发，所写所述十分贴合当今软件工程所需。阅读之后，受益匪浅。
第一章
原文：软件行业也有一句著名的笑话：这不是缺陷，这是一个功能！（It's not a bug, it's a feature!）很多人认为有Bug就是质量不合格，没有Bug就是质
量完美，其实这也未必。
问题：软件的Bug是否是绝对的？书中说Bug是软件的行为跟用户的期望值不一样，那是否某个软件的某一功能贴合某位用户的使用喜好而不适合另一位呢？那是否可以称为Bug？根据百度百科，电脑系统或者游戏程序中，如果隐藏着一些未被发现的缺陷或者问题，可以被人利用的，称之为Bug。那如果一个软件某一功能仅仅是不符合某些用户的喜好，是否可以称为Bug呢？
就我自己而言，曾经使用过某个小说网站手机app，它的一个功能是返回小说目录，而每次返回小说目录会返回到第一个列表，需要你手动继续往下翻并且不能输入数字跳转，而不是返回到阅读章节的那一列表，这是否可以称为Bug？
第二章
原文：在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那么这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。
问题：在软件项目中，如果一个模块或功能之前是可以正常工作的，但是到了一个新的构建中就出现了问题而不能正常工作。为什么会导致出现这样的问题，既然之前是可以正常工作的，那说明代码是没有问题的，那为什么会在新的构建中出现问题导致“退步”？
在我查阅资料后，并未找到说明为什么在一个新的构建中模块会“退步”。但是据我个人推测是否是原代码在新的构建中难以正常工作导致的。
第十六章
原文：技术的成熟度曲线，技术触发期、期望膨胀期、迷茫期、低调发展期、主流发展期五个阶段
问题：一个软件技术的成熟，从书中可以得知分为这几个时期，但是为什么会有迷茫期？从最初的技术触发期，但后来的用户的期望膨胀，导致软件原有的功能跟不上用户需求，这时可以通过各种渠道了解用户需求，进而进行改进，达到用户需求，所以应该是低调发展期，进一步完善和优化软件而后进入到主流发展期，为何会存在迷茫期？书中说迷茫期是第二轮第三轮融资，而后第二代产品出现，既然第二代产品出现，应该可以解决部分用户需求，那迷茫期应该不存在才对，是否软件开发者难以了解用户需求？