问题一：读了《构建之法》第三章有一点疑问,如何避免“分析麻痹”？
分析麻痹是一种极端情况是想弄清楚所有细节、所有依赖关系以后再动手，心理上过于悲观，不想修复问题，出了问题都赖在相关问题上。分析太多，脚都麻了，没法起步前进.（引自《构建之法》p48)
在本书中提出了“思维麻痹”这个思维误区。然而，在本书中没有说明如何去避免“分析麻痹”这种现象，或者对于已经有“分析麻痹”习惯的人如何才能渐渐改掉“分析麻痹”这种思维惯性。那么如何才能避免“分析麻痹”呢？
问题二：读了《构建之法》第四章有一点疑问,当代码解决了问题到底要不要一个代码复审者的存在？
当主程序员完成了自己的代码并解决了问题后，自己对整个程序的思路是清晰的，一个对此套程序思路毫无了解的人来复审程序时，会不会增加程序出错的可能性？
问题三：读了《构建之法》第五章有了一条疑问，团队项目如何合理有效的分配给所有的成员任务？
因为现在只参与过小团队，而每个人的水平会层次不齐，那么如何分配会比较合理，不至于让团队成为”主治医师模式“呢？
问题四：读了《构建之法》第八章有了一条疑问，如何精确获取用户需求并改动？
有一些软件在开发过程中，一部分客户对软件功能满意，而另一部分提出要大幅改动，这时该如何分析并进行下一步的修改。
问题五：读了《构建之法》第十三章有了一条疑问，用Ad hoc Test查bug是否必要吗？
“探索式”的测试(Ad hoc Test)既然是随机进行的，那就不可能把这些随机的bug查完，费时费力最后还是可能出现意料之外的bug，用Ad hoc Test查bug是否必要吗？