第十章代码

更少的软件(Less software)

让你的代码尽可能简单

你或许认为代码量加倍软件复杂性也相应加倍，但实际上，每增加一些代码，软件的复杂性就随之指数式增长。 代码的每一点增加，每一点改动，每一个相依性，每一个前指性（Preference) 都有着联动效应。轻率地增加代码，不用多久，你就会造出一个可怕的大稀泥巴。

对付复杂性的办法就是更少的软件。更少的软件意味着更少的特征（features），更少的代码和更少的浪费。

关键在于将每一个困难的问题（要求很多的软件）重新描述成一个简单的问题（要求少得多的软件）。你解决的问题也许不是和原先百分之百一样的问题，那也没关系。用20%的努力解决原先问题的80%就是一个很大的胜利。原先的问题几乎从来就没有糟糕到值得花5倍的精力去解决。

更少的软件意味着撇开水晶球。处理今天面对的问题而不是预测未来的问题。为什么？对明天的恐惧常常是毫无结果的。不要让幻想的问题把你拖住。

从一开始，我们就将产品的设计基于更少软件的概念。只要可能，我们就将问题简单化。我们发现，对简单问题的解决方案不仅更容易实施和支持，也更容易理解和使用。这都是我们用来区别于竞争对手的做法的组成部分。我们造的产品要做更少，而不是做更多。

• 软件越少，管理越易
• 软件越少，代码就越少，维护就越少（员工更快乐）
• 软件越少，改变的代价就越低，适应也更快，改变主意也无需更改如山的代码
• 软件越少，臭虫越少
• 软件越少，支持越少

决定哪些特征包括进去，那些特征拒之门外，这也和更少软件相关甚密。不要怕对难以实现的特征说不。只要不是必不可少的基本特征，就不要包括进来。这样既省时省力，也减少混乱。

同时也要慢下来。把一个主意丢在一边，平静一个星期后，再看看这是否还是一个好主意。这额外的酝酿时间，常常会让你想出一个更简便的解决方案。

鼓励程序员提出反建议
你想听到：”你建议的方法要花12小时，但我这样做只需1小时，它不做x，但它做y。”让软件推你回来。告诉程序员用他们认为最好的方法去战斗。

还有，寻找可以避免编写更多软件的途径。用屏幕文字的方式建议用户绕道而行，从而避免对于软件模型的更改。比如，建议用户上载指定尺寸的图片，而不是在服务器端作图像处理。

对你的应用（app）中的每一个特征，问问自己：有没有不需要这么多软件的方法来加进这个特征？只写需要的代码，不多不少。你的应用将会更简练而健康。

为快乐而优化

选择能让你的团队欢欣鼓舞的工具

快乐的程序员也是多产的程序员。这就是我们为什么要为快乐而优化。你也应该这样。不要单凭行业标准或性能指标来选择开发工具和开发方法。看看无形的东西：这其中存在激情、骄傲和精湛技艺吗？每天8小时在这样的环境下工作真的会快乐吗？

这一点在选择编程语言上尤为重要。尽管与公众看法相悖，编程语言并非个个生而平等。虽然几乎每个语言都能写出几乎每一个应用，对口的那个（the right one）不仅仅是让你的努力成为可能和可以忍受，而是让你觉得愉快和充满干劲。这都是为了使得每天工作的小小细节快乐有趣。

快乐有联动效应。快乐的程序员做正确的事情。他们写出简单易懂的编码。他们采用简洁、清晰、易懂和优雅的方法。他们乐在其中。

我们发现了使用语言Ruby编程的极致快感并通过我们的Rails框架（framework）将其传递到其他开发人员身上。Ruby 和 Rails都遵循为人类、为快乐而优化的信条。我们鼓励你尝试一下这对组合，给它们一个一展身手的机会。

总而言之，你的团队需要使用他们喜爱的工具。我们这里谈的虽然只是有关编程语言，但其原理也适用于应用、平台和其它任何东西。选择让人们兴奋的导火线，带来激动和鼓舞，更好的产品也就接踵而至。

代码在说话

当你的代码将你打回，聆听

聆听你的代码。它将提出建议。他将把你打回。它将告诉你毛病在那。他将建议新的做事方法。他将帮你遵循更少软件的模式。

一个新特性需要几个星期的时间和几千行代码？这是编码在告诉你很可能有更佳的方法。有没有简单的方法让你一小时完成代码而不是需要十小时的复杂的方法？这又是代码在指引着你。仔细聆听。

你的代码将引导你找到又便宜又轻易的修补办法。在捷径显露出来时要倍加注意。当然了，容易做的特性也许与你原先所想的特性并不完全一致，那又何妨？只要它足以胜任，并且给你更多时间作别的事情，那就留着它。

管理债务

还清你的代码和设计”账单”

我们通常将债务与金钱挂钩，但债务还有别的形式。你可以很容易就拖欠代码和设计的债务。

东拼西凑一些能用但让人汗毛直竖的代码，你就是在增加债务。随便搞一个足够好但并非真正好的设计，你还会再来一遍。

偶尔为之，不足为虑。实际上，它常常是你完成整个”迅速实现”事情所需的技巧。但还是应该认识到它是一笔债并需要在其他时候通过清理可怕的代码和重新设计差强人意的页面这种方式进行偿还。

就像你该定期将部分收入纳税一样，定期将一部分时间偿还你的代码和设计债务。否则，你只是付着利息（修理劣作），而不是偿还本金（并迈步前行）。

开放门户

让数据通过 RSS，API等途径走向世界

不要试图锁住你的客户。客户想什么时候，以何种方式拿他们的数据都要悉听尊便。要做到这一点，我们必须放弃将数据封存的念头。而要让数据遍地跑。让人们通过 RSS Feed 取得他们的数据。提供 API 让第三方开发商在你的工具上进行开发。这样做不仅让你的客户的日子更好过，而且还扩大了你的应用所能做的事情的可能性。

过去人们常常认为 RSS Feed 只是用来跟踪博客和新闻网站的好方法。但它要比这更强大。它也是客户无需一次次地登录就能获得一个应用的内容最新变化的绝妙方法。Basecamp 的 RSS 使得用户只需将 URL 放入新闻阅读器（newsreader），从而无需频繁登录网站就可以留意项目信息、任务列表（to-do lists）和项目里程碑。

API 让开发者为你的应用建造附加（add-on）产品。这些产品的价值很可能难以衡量。例如，Basepack 提供的 API 让 Chipt Production 公司开发出在苹果Mac OS X 上使用的任务栏组件（Dashboard widget）。这个小组件让人们从桌面电脑增加、编辑提醒单（reminders），列表项和更多信息。客户们对此欣喜若狂，甚至说这是促使他们使用 Backpack 的关键因素。

公司让数据自由流动以获得回荡效应的其它好榜样：

• Google Maps API催生了有趣的结合应用（mash ups）。这些结合让人们把从其它来源摘取的数据（比如公寓租售列表）绘到地图上。
• Linkrolls提供办法让人们获得最新的 del.icio.us书签并显示在他们自己的网站上。
• Flickr 让其它公司使用商业 API 以便顾客能购买相册、海报、DVD 备份和邮票。来自Flickr的 Stewart Butterfield 说：”我们的目的是百分之百开放，并对你需要用照片来做的事情提供最多的选择。”