1. 【摘自《译言》】
2. 1. 任何一个程序一旦发布就意味着它已经过时了。 【所以永远需要升级版本】
3. 2. 让需求根据程序调整往往要比让程序根据需求调整来得容易。
4. 3. 如果一个程序是有用的，那它必将被改变。
5. 4. 如果一个程序是无用的，那它必须被注释。
6. 5. 在任何一个程序里只有10%的代码会被执行。 【那为什么还有其他90%代码？ 因为这90%是为这10%服务的】
7. 6. 软件会无限扩张以占用所有的系统资源。 【看看Windows就知道了】
8. 7. 任何有价值的程序都会包含至少一个错误。 【存在bug-free的程序吗？不存在】
9. 8. 一个演示版的程序完美无瑕的几率和关注它的人数成反比，最终要花费的金钱的数量是原数量的平方。 【不做不错，越做越错，承接第7条】
10. 9. 一个程序的致命错误要到其发布至少半年后才会被发现。 【千年虫问题跨越了千年】
11. 10. 不可检测的错误是无穷无尽的，并以各种形式存在；相反，可检测的错误从理论上讲是有限的。 【因为看不到，所以不知道有多少。但是，不要让我太轻易就找到bug。】
12. 11. 随着时间的推移，修正某个错误所需花费的精力会成指数级增加。 【所以不如重写】
13. 12. 程序的复杂度会一直增长，直到超出维护它的程序员的能力为止。
14. 13. 一段你自己写的代码如果几个月不曾看过，重读的时候还不如当作是别人写的代码去理解。
15. 14. 在每个小程序里都会有一大段代码想要破壳而出。
16. 15. 你越快开始编写代码，就会需要越长的时间。 【所以要TDD，但是TDD写的太快，TDD自己也会出错】
17. 16. 一个项目如果没有精心策划，那将需要比预期多出两倍的时间来完成它；相反的，如果项目是精心策划过的，就只需要多出一倍的时间。 【如果想按时完成，只有一个办法，把项目停掉】
18. 17. 向一个落后于进度的项目添加程序员只会让项目更加落后于进度。 【man/month早过时了】
19. 18. 一个程序的完成程度总在90%到95%之间。 【因为第7条】
20. 19. 如果你让一团糟糕的代码自动化，那你就会得到一团自动化的糟糕的代码。
21. 20. 建立一个连傻瓜都会使用的程序，而只有一个傻瓜才想要去使用它。
22. 21. 用户直到他们使用了一个程序之后才知道他们究竟想要的是什么。 【太正确了，所以需求调研等同于鸡同鸭讲】

Popularity: 16% [?]

1. 架构师对于PowerPoint的熟练程度要远远胜过流行的Java IDE。
2. 光是部署基本环境（比如应用程序服务器和数据库）就需要若干张ＤＶＤ和几个小时。
3. 一些流行的服务器需要几分钟去启动和部署，而你每天要重复这一过程若干次。
4. 为应用服务器的bug立案（并且重现问题的所在）往往比你自己修复它需要的时间更长（当然，如果你有源代码的话） 。
5. 很难为开发者们找到一个可以高效运行那些“企业级”开发工具的硬件，而且因为这些开发工具十分昂贵，想要弃他们不用也很困难。
6. 架构师热爱分层，光是从持久层传递一个持久实体到表现层，就需要若干次mapping。
7. 一切都是可配置、可替换、可建模的。ＸＭＬ的负担十分巨大。问题是：上一次你真正的需要在工程中替换某些东西是什么时候？
8. 无论是瀑布式还是敏捷式都充满各种专业术语和奇怪的规范。两者都可以非常的低效。看上去只做最基本的有时真的很难。
9. 开发者有的时候非常极端：不是用成千上万的模式和最佳实践把所有东西都过度设计，就是直接了当的使用“意大利面条”式的开发风格。
10. “快感已经不再”很多开发者、构架师和经理们已经失去了他们的狂热和激情。这也是为什么许多工程如此低效的原因之一。
11. 即使像留言板这样的程序，也要考虑高可用性，不掉线、集群。复杂性统治一切。
12. 奇怪的质量保证规则（比如文档化很明显的getters／setters方法）加大开发和维护成本。
13. 构架师和开发者热爱框架。即使对于最简单的增删查改类的程序，也要用到internet://**/*.jar，而不是Java SE或者应用程序服务器提供的API。

【英文原文】

如果真的出现这种情况，那就太可怕了：

一定要找那最流行的框架，
用功能最强大编辑器，
做就要做最复杂的系统，
轻量级的绝对不行，
框架最简单也得是ＳＰＲＩＮＧ，
什么ＥＪＢ啊，ＨＩＢＥＲＮＡＴＥ啊，ＳＥＡＭ啊，能用的全都得用上，
表现层要可配置、持久层要可替换，
程序最好能用一万年，
客户一见面，甭管有事没事，
都得问人家：您准备换框架不？
系统还得能够集群
访问量再小也得同时开１０几台服务器
一天２４小时在线
火星撞地球了都能提供服务
服务器上跑得都是weblogic、websphere
你要用一jboss，都不好意思跟人家打招呼
你说这系统，得做多长时间？
（怎么地也得５年吧？）
５年？那是一期工程，
１０年起，
你得揣摩老板的心理，
愿意花５年开发一套系统的老板，
根本就不在乎再多等５年，
什么是软件工程你知道么？
软件工程就是，搞什么都不用最好的，用最复杂的
所以我们口号就是：
不求最好，但求最复杂。

Popularity: 22% [?]

祖尔测试（Joel Test）询问以下十二个问题：

你们使用源代码控制吗？
你们每步都做构建吗？
你们做每日构建吗？
你们有缺陷数据库吗？
你们会在写新代码之前修复缺陷吗？
你们有与当前工作吻合的进度安排吗？
你们有规约吗？
程序员工作环境安静吗？
你们采用了市面上最好工具吗？
你们有测试人员吗？
你们会要求应聘者在面试时写代码吗？
你们做走廊可用性测试吗？（到走廊上随便拉一个人试用程序）

我们的得分是：

你们使用源代码控制吗？ 是的，我们使用Subversion。 （+1）
你们每步都做构建吗？ 是的。 （+1）
你们做每日构建吗？ 是的，我们做Daily Build 和 Daily Deployment。（+1）
你们有缺陷数据库吗？ 是的，我们使用Matis Issue Tracking系统管理defects。（+1）
你们会在写新代码之前修复缺陷吗？ 通常会，但有时不完全遵守。（+0）
你们有与当前工作吻合的进度安排吗？ 有，我们采用Scrum，有每日的“站立会议”（+1）
你们有规约吗？ 有，但似乎并没有完全遵守（+0）
程序员工作环境安静吗？ 不算非常安静，只能尽最大可能保持安静（+0）
你们采用了市面上最好工具吗？ 有所谓最好的工具吗？我们用最适合使用的工具（+1）
你们有测试人员吗？ 有，我们有专业的测试工程师（+1）
你们会要求应聘者在面试时写代码吗？ 会，直接上机编程（+1）
你们做走廊可用性测试吗？（到走廊上随便拉一个人试用程序）不会（+0）

OK，总得分是：8分。

Joel 说：

得 12 分为最佳，11 分还可以接受，得10 分或更低就说明你们问题大了。其实多数软件组织只能得 2、3 分，他们迫切需要帮助，因为微软等公司一直都得12分。

看来我们的问题大了，我们需要努力去改进的是：先修正缺陷，给程序员更好的工作环境，遵守规约。

【关于祖尔】
祖尔·索伯斯基（Joel Spolsky）曾担任微软项目经理，负责 Excel 开发。当Joel 离开微软、创办自己的小软件公司时，还开设了一个名为“祖尔谈软件（Joel on Software）”的网站，发表文笔尖刻但充满实用建议的趣文。

Popularity: 20% [?]

20 世纪 90 年代，软件开发界出现了一个新的方法论：“轻量级方法论”，这让它区别于CMM世界缓慢而笨拙的“重量级”方法论。2001 年，该领域中的 17 位领军人物，聚集于犹他州的滑雪胜地，想要找出他们互相关联但有不同的方法之间的共同立场。

敏捷软件开发（Agile Software Development）应此诞生，还有一份宣言（Agile  Manifesto），全文如下：

我们正通过实践和帮助他人来揭示开发软件的更好方法。
经由这项工作，我们估量：
个体和交互  胜于  过程和工具
可工作的软件  胜于  面面俱到的文档
客户协作  胜于  合同谈判
响应需求  胜于  遵循计划
即，尽管右栏条目有其价值，但我们更看重左栏条目。

【这17位人物是】Kent Beck、Mike Beedle、Arie van Bennekum、Alistair  Cockburn、Ward Cunningham、Martin Fowler 、James Grenning、Jim
Highsmith、Andrew Hunt、Ron Jeffries、Jon  Kern 、Brian Marick 、Robert  C.
Martin、Steve Mellor、Ken Schwaber、Jeff Sutherland 、Dave Thomas

Popularity: 17% [?]

Scrum and XP in Trenches 的中文版发布了，命名为《硝烟中的Scrum和XP》。

在本书中，作者Henrik Kniberg讲述了他在一年的时间里，带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸（3～12人）、sprint长度（2～6星期），定义“完成”的不同方式，不同的backlog格式，各种测试策略，在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等，还试过了把XP跟Scrum组合。

本书描述的是一个成功敏捷团队的工作过程，没有理论、没有引用、没有脚注、没有废话。…可以把它当作一些基础实践的入门指南，帮助团队进行正确实施——但不能模仿，你需要了解自己所处的环境，进而对具体实践做出取舍，创造出属于自己的过程。

我们也在使用Scrum和XP，这个敏捷团队的成功经验一定会为我们带来更大的进步。 周末，刚好可以读一下这本中文翻译版。

Popularity: 19% [?]