读《构建之法》提出的问题与思考

在大致阅读《构建之法》后，我提出一些问题：
问题1：在书中的第一章节讲软件的一些背景知识，我在看到书中第15页，有趣的是到底一个软件的好坏
怎样来评价，是不是没有一个bug的软件就是完美的，这样提出来的问题都是错误的我觉得，没有绝对的
事物，有错误的软件或者程序可能会在解决问题的路径中发现一些更加有价值的东西，我们需要从哪些
方面来描述或评价软件的好坏？让它成为足够好的软件，这样是不是像我们这些人在设计软件的时候就
能够有意图的让这些问题尽量不出现。
问题2：在书中的2,3,4,5章中从个人，到双人合作再到团队合作进行介绍，在第四章的75页，有对goto
进行描述，书中有句话这样说“只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto”,我
的观点是不赞同，学过一点关于这个语句的用法，老师也说这个语句最好不用，也极少用这个语句，查
资料goto语句不受限制的跳转，这样会导致结构化设计风格，还会降低代码的可读性，这样我觉得这个
语句弊大于利，能避免就不用，不能为了清晰表达程序逻辑冒风险。
问题3：书中第8章讲了需求分析，在我们着手一个项目开发设计，编码之前需要了解客户需求，怎样才
能够准确了解和挖掘他们对软件的需求，引导出真实的需求，太难了，到底用户调研能不能获取到真实
的用户需求，我们如何能够通过比较好的用户交流，比较全面的了解和弄清他们的需求呢？这有没有好
的一套方法流程？这样就会不会在详细设计过程中又反过来讨论需求。
问题4：在书中第238页讲了一个表达控制流，有限状态自动机，但是我不知道是怎样来表达控制流的，
我想问这在解决问题建模时怎么来用它？控制流和数据流之间又是怎么进行交流？需要进行什么样的控
制，查阅资料说有限自动机是一种计算模式，是表示有限个状态以及在这些状态之间的转移和动作等行
为的数学模型。
问题5：在书中291页讲到压力测试，书中说压力测试就是验证软件在超过设计负载的情况下是否能返回
正常结果，不产生严重的副作用和崩溃。超负载下我们的程序到底能不能正常运行，不死机，我提出问
题怎样进行压力测试怎样才是刚好？为什么很多“小”问题在加压下就会被放大？我理解的这样进行加
压的测试是不是会因为内存泄露或者资源泄露，产生死锁而得不到压力测试的临界点。