关于构建之法阅读中的一些思考

1. （总体性问题）书本中，作者是一只在强调需求分析的重要性，软件设计的重要性，但是书本的写作到发行，我觉得与软件工程有很多十分相像的地方。我觉得作者在写书的时候，没有充分的考虑到读者的使用需求。比如，参考资料只是给了相应的网址链接，并没有给出一个二维码或者包含全部链接的索引网页。这种设计之下，除非读者对于相关内容非常感兴趣，否则，根本不会输入链接，访问相关资料。使用成本过大。

 

2.问题：软件测试中，常常用单元测试和回归测试等方法，保持软件的鲁棒性，但是回归测试的特性决定了它在每次完成代码功能的修改后，需要用所有的测试用例重新测试，我想这样的测试方法耗费的成本是不是有点过大，它与完成整体的版本更迭后，统一测试的方法孰优孰劣？

 

3.软件编程的方法中有一种方法叫做结对编程，一人做主要的编码工作，一人做代码复审，这样的规划真的合理么？？

　　1.他提出驾驶越野赛车（驾驶员，副驾驶员），驾驶飞机（驾驶员，副驾驶员）等案例。我觉得这就是一个写作的败笔。生活中每一件事情都有自己的特殊性，不恰当的类比，不但不利于讲明道理，反而会使类比变成一种歪理。这种工作强行把做和思考强行分割开来。这就好比程序员与项目经理之间常常发生矛盾，项目经理常常提出一些不切合实际情况的需求交给程序员做。

　　2.项目的规划者和项目的执行者之间的矛盾没有充分的考虑到。这样的结对编程会不会出现九龙治水水不治的情况。

4. 如何改进老板式编程：

　　项目很多都是老板谈妥，软件功能往往由行政体系决定，在中国，软件常由老板驱动，但是，老板大多都是外行，不了解相关的技术实现，那么如何改进这样的编程体系呢？

5. 有一个著名的停机定理，“不能证明软件工程无错，只能证明软件有错”，例如在win98的系统的编写过程中，

修复bug所写的代码量是编写系统代码量的1.5倍，那我们该如何抉择代码重构与修复bug的界限呢？