瀑布模型是在实施软件之前*行之有效的描述系统的模型，它能帮助软件实施时循序渐进，而非循环反复。人们一直当它是一个好的实施方案，而一篇论文中恰好将它列为很差的实施方案，因此引起广泛讨论。http://en.wikipedia.org/wiki/Waterfall_model

　　● 用户知道他们想要什么，他们也能够将需求阐述清楚。

　　● 有某种语言、技术或是流行方法将会是杀手锏，能够取代你正在使用的方法，解决你的问题。

　　● 人月神话里说，在一个开发团队中增加人手会让效率成线性增长。http://en.wikipedia.org/wiki/The_Mythical_Man-Month

对规范文档的认同意味着对实际功能的认同，甚至规范文档本身写的很模糊或是有出入也要遵守规范文档。http://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.php

　　● 唯有一种方法能将开发实施得*，程序员的自由被所用的语言严格束缚。

　　● 有多于一种方法来完成一个任务，程序员有完全的自由。

　　● 设计样式是通用的，而不像某种编程语言的表达式一样有诸多限制。

　　● *的技术方法就是*的方法。

　　● 你可以用正则表达式来解析 HTML：http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags

　　● 不需要理会市场反应，应该让市场来适应软件。

　　● 软件可以被精确估计。

　　● 软件开发可以被当作固定价格、固定限期的项目出售。

　　● 对象是对现实世界*的描述。对象*的应用方面便是描述真实世界中的实体。

　　● 数据应该隐藏在对象后面，对象应提供操作数据的需要的所有方法。

　　● JavaScript 和 Java 有关系。

　　● 逻辑应该和显示完全分离开。

　　● 软件开发*重要的是需要好的数学能力，*的学习方法是学习理论的计算机科学，数学能力强的也能写出好的软件。解决逻辑难题的能力是判断一个软件工程师能力在*有效方法。

　　● 软件就是表面上看到的，设计后面发生了什么不需要引起我们的注意，尤其对于那些非技术出身的经理和客户来说更是这样。

　　● 编写软件对于缺乏人际沟通能力的人来说是一个好职业。

　　● 软件可以有效的用其他媒介来模拟和设计，例如 wireframes 或 Photoshop comps，因为用实际的代码来设计（HTML 和 CSS）太难，太贵了。

　　● 设计师们不能也不需要学习写代码，应该尽量远离真实的代码。

　　● 设计仅仅是表面上的装饰，其重要性没有好的开发重要。

　　● 软件可以基于一系列的抽象的基础之上可靠的构建，你仅需要理解*上的抽象层，而不需要了解背后的实现细节。参看 Joel Spolsky 关于抽象漏洞定律的讨论：http://www.joelonsoftware.com/articles/LeakyAbstractions.html

　　● 当你*终发布了新的应用或是网站，就意味着一切结束了。