读《构建之法》思考与疑问
1、2与16章
第一章 概论
问题1、2和3
我看了
人类文明要向前发展， 离不开思考、 发现、 构建。 我曾经在微软亚洲研究院技术创新部工作过七年， 我所在的工程团队和很多计算机科学家在不同领域一起做项目……这是我在研究院之外的十余年中做得最多的项目类型， 也是这本书的英文名字。 希望读者看了这一节之后， 不再纠结“科学”和“工程”的问题， 在不同的学习与工作阶段， 投入到最适合的项目类型中去。
我的疑问是：想要从事理论研究一定要参与实践项目吗，我明白有实践带来的经验能一定程度上更好地研究，但是很多，毕竟理论研究是很困难的，如果再做项目，会不会没办法专注一个领域呢？
我查了资料发现,许多著名的计算机科学家一生都是为解决实际问题而驱动着进行思考和设计，如
Edsger Dijkstra ————来自维基百科
What is the shortest way to travel from Rotterdam to Groningen, in general: from given city to given city. It is the algorithm for the shortest path, which I designed in about twenty minutes. One morning I was shopping in Amsterdam with my young fiancée, and tired, we sat down on the café terrace to drink a cup of coffee and I was just thinking about whether I could do this, and I then designed the algorithm for the shortest path.
A year later, he came across another problem from hardware engineers working on the institute‘s next computer: minimize the amount of wire needed to connect the pins on the back panel of the machine.
……
那么，随之而来的是更多的困惑，因为我想从事与数学有关的理论工作，我平时应该关注什么实际问题，什么才是最适合理论研究的项目类型呢，已及，一般这些项目都由哪些机构负责呢？所以我认为理论到底应该和什么样的实践相结合是非常关键的。
第二章 个人技术和流程
问题1
看完这一章之后，我之前很多理所当然的想法得到了纠正，
如果我们不经分析就盲目优化，也许会事倍功半。
但因为书中许多的概念和方法都是第一次知道，很容易就会让“原来是这样”的心理掩盖对一切书本内容保持怀疑的态度。例如，
回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。单元测试是回归测试的基础。
在专注于模块基本功能的单元测试之外，还有功能测试—从用户的角度检查功能完成得怎么样。
初看只会觉得 “噢，原来有两种测试，单元测试是……回归测试是……”，而且我看完这一章有一种感觉，那就是在做项目的过程中，无论干什么之后都是先测试一下，一个小的修改在复杂的项目里都是牵一发而动全身，而且在PSP中一位SDE的花在上测试的时间也远比一位senior student要久，根据我查的资料，
还有 ”极限测试、集成测试、软体测试……" 等等，
回归测试带来的耗费占软件工程生命周期1/3总费用以上。
所以我认为提高测试的效率，以及精简测试的流程是很重要的，但是测试都是为了找出问题，否则不过是为测试而测试罢了，那么我认为呆板的测试流程虽然带来了规范，但也带来了浪费，不是最优的做法，现在是否有一种灵活的测试体系，针对不同的软件类型，不同的需求给出的测试流程呢？而不是统一的测试规范。
第十六章 IT行业的创新
在这一章的开头，列出了很多似是而非的 “创新的迷思”，这是确实提供了新的角度，其中有些我也比较赞同，但始终不能完全赞同。因为在我看来都只在做一件事，那就是否定绝对性（一……就……；……都……），这当然非常简单，因为绝对的大部分都是错的，而且反驳的方式也很简单，只要举出真实的反例就好了。而且提供了很多 “当创新已经/快要出现了，我们可以怎么办/走进小作坊” 的方法论。
