提出问题
快速通读教材《构建之法》，并参照提问模板，提出5个问题。
如何提出有价值的问题？ 请看这个文章：http://www.cnblogs.com/rocedu/p/5167941.html ，以及 在互联网时代如何提问题。 还有这些要点：
- 在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文
- 列出一些事例或资料，支持你的提问。
- 说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
一个模板可以是这样：
我看了这一段文字 （引用文字），有这个问题（提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。
或者这样：
我反对作者的观点（提出作者的观点，自己的观点，以及理由）。
问题一：什么人群适合看《构建之法》这本书？
为什么会有这样的疑问呢？在于我粗略看下这本书后发现，我不适合看这本书。确实，本书作为计算机专业的教材很有意思，当作者提出一个具有争议或让人困惑的观点时，会通过文中虚构的人物来提出读者可能的疑问，并通过对话的形式，给出作者自己的见解。
但是如果学生没有足够的代码量和工程经验（比如我），对里面所讲的很多问题并不会有太多的切身体会，可能很难深刻理解。
我认为《构建之法》最适合有一定代码量积累和经验的人阅读，尤其是在做项目过程中，时常感到困惑的一线工程师，或者是面对一个庞大的软件项目开发任务而感觉力不从心，无力掌控的负责人。此时，这本书就能帮助读者“理论结合实际”，发挥它最大的功效。
不知道作者在写书时，学院老师在选教材时是否有考虑过这个问题呢？？。
部分问题已经得到作者的解答,希望对大家也有帮助.
问题二：
本书的培训目标是
1.研发出符合用户需求的软件
通过实际的工作收集、推导、提炼需求......
-- 引用自《构建之法》P11 第一章 概论
成功的软件总是解决了我们生活中的迫切需求，但是不同的人群有不同的需求
"推导"，"提炼需求"的意思是满足大部分用户的需求吗?程序员是否有必要为满足小部分人的需求去做软件,或者为软件添加某些功能？
部分问题已经得到作者的解答,希望对大家也有帮助.
问题三：第四、五章大谈双人合作，团队合作的好处，但作者忽略了一个重要的前提，也就是所谓的团队准入机制
哪怕是复仇者联盟，没有超能力的普通人也是加入不了的
交友之前先择友，恋爱之前先择偶，团队合作前先团队准入选择队友，这么简单的常识性大道理，老是被我们一遍又一遍的忽略
任何没有团队准入机制就堂而皇之的跟你大谈团队合作重要的机构，组织，或者个人，都是流氓行为
大学很多时候自己单干和团队协作是不能够自己选择的。我也是大学生，我觉得合作也不尽然全是好处，如果团队合作能够选择队友尽量选择靠谱或者同时责任心较强的人，那OK。若不能选择队友，遇到猪队友，那只会给自己徒增“游戏”难度。
问题四：
软件的行为和用户的期望值不一样，就叫bug。是否是BUG，取决于用户和开发者的不同角度。
--引用自《构建之法》P16
程序员好与不好的评价只有模糊的定义，在我所查资料中“调试Debug能力是评价一个程序员的标准之一”。然而在阅读完这段话之后，我思考自己写的程序里没有BUG是不是也可以作为一个程序员是否好的标准。如果你实现了用户不需要的功能算不算BUG ？这对于程序员来说到底是一件好事还是坏事？
**问题五:第六章 敏捷流程 "敏捷"是否等同于速成? **
现在人都是对短期能达到目标或获得奖励的事更有兴趣更能坚持的。恕我直言，这是为了迎合绝大多数国人急功近利急于求成的心态。所以我不奢望其效果。
一味的追求速成的人不都是“伪努力者”吗??
“21天学会编程”、“一个月助你过英语四六级”等课程层出不穷。仿佛这个世界上真的有种适用于所有人的方法。
捷径有，但真正能花别人1%的时间学到100%的知识是不太切合实际的。
豆瓣读书笔记
部分问题已经得到作者的解答,希望对大家也有帮助.
