持续更新就是给软件上医保

其实软件很像房子。

想让你的房子整洁舒适，你必须每周打扫。随着时间的流逝，有些东西会出问题，你必须修理它或换新的。但大多时候你需要做的只是简单的给门或窗刷一道漆就行了。

如果房子料理的好，人们就会喜欢住在里面。

但想象一下，你现在要离开这个房子。刚开始，这个房子还会保持不错的外观，室内一切正常。可是，一旦不再有人打扫地板或清理垃圾，房子就开始落灰积沉。一段时间后有些东西开始出问题。起初只是一些小的、不重要的东西出问题，但有一天一场暴风袭击了它，毁坏了很多东西。

如果这些毁坏的东西没有人来修理，房子就会持续破败。

一段时间后，房子变得破败不堪，没有人再愿意去哪里。人们会告诉你，与其去修好它，不如盖个新的。

对任何软件产品来说，道理是一样的。

假设一个项目由你们7个人的团队来开发。每周你们会往里面增加新功能或修改bug。随着项目的变大，你们会做一些重构来保持软件架构的健康。你们会做一些迁移工作。时不时的升级软件包来修补bug、安全漏洞和新功能。

之后，开发工作突然停止了。也许是上级的某个人决定不再往这个项目上投入更多的资金。决策者说：“这个软件运行的很好。我们只需要它保持这样，我们不会再花钱来添加新功能。”

于是，你们这个团队被分配了其它任务，这个项目变成了没人照料的项目。系统目前还是正常运行，每天都在给现实生活中的人们提供着服务。

几年后，突然里面的支付系统出现异常。发生了什么？多少年都没有人碰过这些代码了。它怎么会突然的就不能用了呢？怎么可能？

无人照料，一场风暴来临了…

你需要知道，如今的软件不再是一个自我封闭的世界。基本上所有的软件都会和外部世界进行交互。软件要依赖操作系统，硬件，很可能还会有个数据库或其它后台服务。甚至还依赖一些外部API。它们全部是动态的，不停的在变化。所以，你的软件也需要跟着变化，这样才能保持正常运行。

在我们的这个例子中，是因为欧盟通过了一个新协议来统一货币。这导致老的支付API不再受支持。

这看起来不像是个大问题。我们的上级决策者决定招聘一个Ruby程序员来解决这个问题。这是一个Ruby on Rails + MySQL项目。很普通。Ruby程序员很快就招到了，而且估计出大概一两天就能解决问题。

然后，Ruby程序员开始查看项目代码，发现这是一个很老的项目，使用的是Rails 2.x，不是Rails 3.x或4.x。不，比当前的版本低两个大版本号。他从来没有用这么老的Rails版本开发过。

而接着的另一个让他惊奇的事情是，MySQL是4.0版的，不是5.0或5.5。不，低一个大版本号！项目中的MySQL驱动gem使用的是一个本地(native)扩展，无法在他的开发机上编译，因为他的gcc太新了。他必须降级gcc编译器版本，才能安装老的数据库驱动。

我只打算讲到这里。估计你已经知道我想表达的是什么了。

因为这个项目多年无人维护，导致现在即使一个很小的改动也变得异常痛苦。一个根本用不了一天的小bug修改，现在用去了一周时间。而且这个Ruby程序员非常不喜欢他现在干的活儿。其他程序员都可以使用Rails4.x里像“Turbolinks”这样有趣的功能，而他还在跟这些老破烂打交道。他宁愿建议扔掉这个项目，利用现在的最新技术重新开发一个。

教训是清楚的。如果你离开你的房子几年之久，你应该请一位家政每周清扫一次，而在软件开发世界里，这意味着你每周都应该花一点时间检查系统并更新相关依赖。

很多时候都是没有更新可用，外部世界没有任何变化。这种情况下，5分钟你就能维护完。

很多时候你会发现软件包出现了一个新的补丁或小版本升级。这时，你必须进行升级，看看测试是否仍然能通过，系统是否能正常运行。这种事情通常会花20分钟，完全值得投入，因为这些升级会修补bug，弥补安全漏洞，带来新功能特征。有些还会带来内存和速度的优化。

一般每过几个月，你依赖的数据库或API等软件包都会有一个大版本号的升级。替换他们可能会花数小时，甚至数天。但这是值得的，因为这些升级会让你的软件保持最新技术，这是用来吸引有天才的程序员最好的途径，他们都是喜欢最新的技术，而不是一堆老代码。有时候这些更新是必须的，如果不更新，你的应用就无法运行。

持续更新是为了让软件常年保持生命力，健康和新鲜血液。这能保证即使有业务逻辑上重大修改也能在合理的预算内、可以接受的时间里完成。持续更新就是你的软件项目的医疗保险。