刚刚在阅读《程序员修炼之道》时发现的一些问题：
1：需求之坑：不为收集需求，挖掘它们。有一种能深入了解用户需求，却未得到足够利用的技术：成为用户。与用户一同工作，以像用户一样思考。描述需求文档时，要使用项目术语表。用WEB来收集和管理需求。
2.解开不可能解开的谜题：遇到不可能解决的问题时，退一步问问自己如下问题：1）有更容易的方法吗？2）你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？3）这件事情为什么是一个问题？4）是什么使它如此难以解决？5）它必须以这种方式完成吗？6）它真的必须完成吗？
3.等你准备好：一件事没有开始，是谨慎？还是在拖延？我觉得要通过自己的判断，事情的优先循序和紧急情况还有你的准备，再决定是否要做。而不是鲁莽的去做或者是不做拖延着。
4.规范陷阱：需求文档写上几百页不成问题，但是一旦用户看到了实际运行的系统，你就会被各种变更要求淹没。对有些事情“做”胜于“描述”
5.圆圈与箭头：有些设计图是给程序员看的，对最终用户没有意义，不要认为用上了UML等形式化描述图形就能制作出好的设计。
6.注重实效的团队:不要留破窗户，不要重复你自己，按功能划分团队
7.无处不在的自动化：持续集成的概念
8.无情的测试：早测试，常测试，自动测试
9.全都是写:嵌入在代码中的注释，注释应该讨论为何要做某事、它的目的和目标。
10.极大的期望：给他们的东西要比他们期望的多一点。
11.靠巧合编程：软件开发者，每天就像工作在雷区，有成百的陷阱等着抓住我们。
多余的或不必要的代码可能这次能够正常运行，但换个环境可能就会崩溃，另外会使代码变慢，或引入新的bug。总之，不要靠巧合编程。
要想着尽可能在开发周期的早期抓住并修正错误，道理很简单，但在项目进度压力大的时候，把这句话忘在脑后。
为编码工作划定优先级，把时间花在重要的上面，经常也是最难的部分。但如果基础设施不正确，再花哨的界面或装饰也没有什么用。
12.算法速率：没有什么可说的，就是o()表示法。