提出问题
快速通读教材《构建之法》，并参照提问模板，提出5个问题。
如何提出有价值的问题？ 请看这个文章：http://www.cnblogs.com/rocedu/p/5167941.html ，以及 在互联网时代如何提问题。 还有这些要点：
- 在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文
- 列出一些事例或资料，支持你的提问。
- 说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
Q1:关于依赖问题修复以及程序优化、扩大化/泛化的时机选择
P52 3.2 软件工程师的思维误区
其中关于依赖关系提到两种极端思想：一种是想弄清楚所有细节、所有依赖关系之后再动手心理上过于悲哀，出了问题都赖在相关问题上；另一种是过于积极，想马上修复所有主要的和次要的依赖问题。对于新手来说，虽然理解，可是真正实践起来却并不理想。经验的不足让我们难以把握，即便是积累一些经验后，也很难实现。如何能够快速准确定位？
过早优化、过早扩大化/泛化，提到软件具有很大的可塑性和扩展性，不应该在局部问题上陷进去，花大量时间对其进行优化，可是一个软件的模块之间存在着各种复杂的依赖关系，如果不尽早对其进行优化，中后期优化起来不就更复杂？（有想法就去想办法实现这是我基于现在学习阶段所提出的想法）
Q2：关于驾驶员与领航员连续工作的时限问题
P87 4.5.4 如何结对编程
其中提到驾驶员和领航员不断轮换角色，不要连续工作超过一个小时。我的想法是，现在的我们编程等各项能力都不是很精通，也许在一个小时内并没有太大的进展，此时停下来，可能会打断之前的思绪。再者，两人一起学习的时候会比单独学习更具有热情，相互之间也可以竞争，对大脑的刺激也会更强烈，一个小时并不能完全放飞两人的思绪。所以我觉得可以适当延长。（我所提的问题全部基于我对于现在学习阶段的想法）
Q3：关于敏捷流程的定义问题
P114 敏捷的流程简介
其中说到在软件工程的语境里，“敏捷流程是一系列价值观和方法论的集合”。看到这里我脑海里还是有一点的概念的。可是继续看后面对敏捷流程的一系列介绍，我对敏捷一词的概念越来越模糊。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
--引用自《百度百科--敏捷开发》
于是我问了一下度娘，结果搜到这么一条百科词条，我彻底蒙了好吧。感觉这和普通开发流程并没有什么不同。
然后我无意中看到某些同学的博客也有这个问题并且找到《谈谈我理解的敏捷开发》。其中有这么一段
敏捷开发的意义在于它只关注文档中的重要点，或者尽可能的去简化文档，敏捷开发其实更注重的是人与人之间的沟通、交流。所以它强调以人为核心。
好吧，总算知道它是何方圣神了。之前貌似一直用学语文的眼光去看待“敏捷”'_'!
Q4：关于灵光一闪现该不该实践
P346 16.1.1 迷思之一：灵光一闪现，伟大的创新就紧随其后
迷思一，这句话说得有点绝对，但也不能说完全错误。书中提到阿基米德和牛顿是在顿悟之前已经在相关科学打下了深厚的基础，同时也为这些问题进行了长时间的思考，于是那些看似神奇的时刻才会光顾他们。并借此得出推论——不要一开始就想着找到并拼对所有的拼图块，以为能够打造一个巨大的创新。我并不是非常认同这个推论。首先，创新，顾名思义就是要创造新的东西，灵光一闪，本身就是突发奇想，以前从未有过的想法，对于我们来说就是新的东西。并且灵光一闪有可能转瞬即逝，如果不抓住，就容易错过。其次，如果不是本着找到并拼对所有拼图块的理念，那么在发现错误时可能并不会及时修正且如果问题积累过多容易半途而废。然后，灵光闪现时及时实践求证，尽管可能会出错，但是在实践中的积累会为下一次的灵光提供条件。
Q5：关于“已经成功的公司还能创新么？答案是肯定的”所持的疑问
P360 上半页
“已经成功的公司还能创新么？答案是肯定的”这句话挑不出半点毛病，可是联系上文
当企业成功很久以后，就会有“文化”，就像历史悠久的大学、民族那样，有些事情，你的前辈就是这么过来的，你的前辈也是这么过来的。大家都习以为常，甚至以这样的文化（或者是惰性）、祖宗之法为自豪。商鞅变法，胡服骑射，都是古代创新的例子，这两个例子都有最上层支持，但是如果自下而上搞创新，“文化”未必会喜欢你，说不定会出人命的。
文中提到“文化”会限制创新，这句话不就有点乱入了？
