提出问题
快速通读教材《构建之法》，并参照提问模板，提出5个问题。
如何提出有价值的问题？
请看这个文章：http://www.cnblogs.com/rocedu/p/5167941.html ，以及 在互联网时代如何提问题。
还有这些要点：
- 在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文
- 列出一些事例或资料，支持你的提问。
- 说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
模板
一个模板可以是这样：
我看了这一段文字 （引用文字），有这个问题（提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。
或者这样：
我反对作者的观点（提出作者的观点，自己的观点，以及理由）。
大学生应该能写出自己的思考， 而不是摘抄书本内容。
提示：编程经验不多的同学，建议看16章 “创新”， 提出自己的问题。
答：
首先，《构建之法》这本书的内容确实很充实，涵盖了很多软件工程相关的概念和内容，而且有很多有趣的对话和情景剧，让读者更加能够接受和理解其中的一些较专业的内容，可能我的基础不太扎实，感觉我虽然能理解它表面上的意思，但总感觉它里面还包含更深一层的，我挖掘不到的内涵，个人感觉这本书还是适合基础稍微好一点的人看会更有价值。
其次，我只看了前面几章以及老师推荐的16章，所以问题大部分都是比较靠近前几章的内容。
①关于专与精
当我们谈论“全栈工程师”的时候，我们说的究竟是“交响乐作曲家写各个乐器的乐谱”，还是
“演奏家满场奔走，操作各种乐器”呢? 当工程师设计软件的时候，工程师的设计、修改错误
等活动大致等同于交响乐的谱写完善阶段，两个职业都假设一旦程序/乐谱写好，它们就会被
正确地执行。当一个运维工程师在维护一套系统的时候，运维团队要了解各个模块的作用、维
护知识，以及和硬件、商业模式相关的各种事件的需求。如果这大部分运维工作都是由一个运
维工程师来完成，那么这位工程师的确是“全栈”。--《构建之法》第三章
选择当可以写各个乐器的乐谱的作曲家，还是可以操作各种乐器的演奏家有什么依据吗？
②关于过早优化
大家也要注意避免没有做分析就过早地进行“效能提高”，刚才有人提到我们可能要提高排序的性能，但是从图2-6 来看，system.collections.Arraio 只占了FreqOneWord( )不到1/50的时间，如果我们不经分析就盲目优化，也许会事倍功半。我们在第三章还会讲到过早优化的其他例子。--《构建之法》第二章
过早优化: 既然软件是“软”的，那它就有很大的可塑性，可以不断改进。放眼望去，一个复杂的软件似可很多模块都可以变得更好。一个工程师在写程序的时候，经常容易在某一个局部可题上陷进去，花大量时间对其进行优化、无视这个模块对全局的重要性，甚至还不知道这个“全局”是怎么样的。这个毛病早就被归纳为“过早的优化是一切罪恶的根源”。--《构建之法》第三章
关于程序优化的时机，这真的是一个令人头疼的问题，在程序设计或课设过程中，对于某个模块既希望优化使其能具有更强大的功能，但又担心能否在最终将其全部功能都充分利用到而纠结半天，究竟怎样才能避免过早优化，怎样确定程序优化的时机？
参考资料：过早的优化是万恶之源，细数优化7大原则
“现代计算机科学的鼻祖”Donald Knuth曾说过“过早的优化是万恶之源”，因为：让正确的程序更快，要比让快速的程序正确容易得多。文中讲了7个原则，简单罗列如下：
- 究竟要优化什么？
- 选择一个正确的优化指标
- 优化在刀刃上
- 优化层次越高越好
- 不要过早优化
- 依赖性能分析，而不是直觉
- 优化不是万金油
③关于软件设计思想与软件工程思想
3.对通用的软件设计思想和软件工程思想的理解。这一方面就比较虚，什么是好的软件设计思想? 什么是好的软件工程思想?一个工程师开了博客，转发了很多别人的文章，这算有思想么? 另个工程师坚持做任何设计都要画UML图，这算有思想么?--《构建之法》第三章：初级工程师的成长-3
-
软件是一种知识型产品，需要创造性，并依赖每个开发人员的创造力和积极性。所以引导人们新的思考，引导人们不断认识软件工程而建立独特的软件工程思想。
-
软件工程在过去几十年的发展历程中，也形成了一些鲜明的新思想。例如，IBM 提出了软件开发思想的4项要点——迭代开发、以系统架构为中心、持续的质量保证以及管理变更和资产，其中只有“持续的质量保证”和传统工业工程是十分吻合 的，而其它3项具有软件特性所拥有的思想。软件的变更比较频繁，自然对其管理的高要求，进一步促进迭代开发的合理性。--参考：软件设计思想
-
我认为初级软件工程师的成长确实应该包含对软件设计思想和软件工程思想的理解，但是要如何才能做到正确理解这两种思想，在我们实际生活中，包括软件设计与实现的过程中，很容易会出现让自己觉得矛盾的想法，而网上的资料又各执一词，要如何才能确定我们的理解是正确的，又或者说如何才能正确理解软件设计思想与软件工程思想？
④关于软件开发的质量与re-work（返工）
软件开发的工作量和质量怎么衡量呢? 第2 章提到的PSP认为有下列4个因素:
a.项目/任务有多大?
说明项目的大小，一般月代码行数(LineOfCode,LOC) 来表示; 也可以用功能点(Function Point) 来表示。
b.花了多少时间?
可以用小时、天、月、年来表示。一组人所花费的时间可以用(人数x 时间)来表示，例如某项目花费了10个人x 月。
c.质量如何?
交付的代码中有多少缺陷? 交付有两个定义:①在代码完成（code complete）时，交付给测试人员；②在软件最终发布时交付给顾客。--《构建之法》第三章
笔者认为，re-work 只是表明在软件开发过程中花费的时间，re-work 的多寡并不跟最终的质量成正比关系，软件开发过程很大程度上是一个探索和实验的过程，不同的re-work能帮助工程师深人了解项目的各个难点，尽早交付原型，找到最优解决方案，等等。因此，re-work是有价值的。当然，如具一个程序员为了一个简单的问题而不断地re-work,其工作效率就不是太高一这可以用时间花费来衡量。--《构建之法》第三章
为何说re-work 的多寡并不跟最终的质量成正比关系，我的想法是：当工程师从程序中发现了问题并进行re-work，这样程序的质量也会随着提高，发现越多的问题，进行越多次的re-work难道不应该使最终的质量更好吗（虽然会消耗更多的时间）？
⑤关于非团队与团队
A.在讲团队之前。我们要讲讲什么是“非团队”。
王屋村里经常发生这样的一幕:
王屋村的居民大智要把一堆砖头从村头搬到村尾他来到顶球酒吧前，看到前面三三两两地蹲着一些人，有些人面前放着一块包装箱纸板，上面写着“Java,五毛一行”;“网页前端，不酷不要钱”;“专做PS,擅长人体”;“通吃SQL、NoSQL"，等等。
大智冲这些人喊了一嗓子: 搬砖的有没有?一百块砖一毛钱! 地上蹲着的一些人抬头看了看，有一两个人慢慢站起来了。大智看了看人数，又喊了一声: 中午有盒饭! 这时七八个人都站起来了.拍拍尼股就凑到大智面前。大智就带着他们走了。
这七人个人是团队（Team）么? 不是，他们只是一群乌合之众，临时聚集在一起，各自完成任务就领钱走人。--《构建之法》第五章-团队与非团队
B.可以看出，团队有共同的特点:
1.团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。王屋村搬砖的“非团队”成员则不然，每个人想搬多少就搬多少，不想干了就结算工钱走人。
2.团队成员有各自的分工，互相依赖合作，共同完成任务。王屋村搬砖的“非团队”成
员则是各自行动，独立把任务完成，有人不醉而别，对其他的搬砖人无实质影响。--《构建之法》第五章-团队与非团队
我还是无法理解为什么文段A是在描述非团队这个概念，我觉得他们也是有一致的集体目标（把一堆砖头从村头搬到村尾），也要一起完成这目标，成员有各自的分工，互相依赖合作，共同完成任务。对于团队而言，也有成员由于某些原因而退出的情况，这与“不想干了就结算工钱走人”难道不是一样的道理吗？