所有有趣的问题都是扩展性方面的问题

John Sloan是Digital Aggregates Corporation公司的技术咨询师，他关注超大型和超小型系统，包括分布式，实时、高性能、嵌入式、高度并行系统等多方面。他有一个名为Chip Overclock的博客，最近发布了一篇文章——《所有有趣的问题都是扩展性方面的问题》。

John之前曾在美国国家大气研究中心工作，2006年时，他绘制了一个图表：

这个图表的横轴是以年为单位的时间，纵轴是技术随时间演变的对数值。John在1997年做了相关的数据挖掘，下面是他的一些假定：

微处理器速度每2年翻一倍。

内存密度每1.5年翻一倍。

总线速度每10年翻一倍。

总线带宽每5年翻一倍。

网络连接速度每1年翻一倍。

网络带宽每10年增加10倍。

第二存储密度每10年增加10倍。

每个微处理器上的CPU核每1.5年翻一倍。

虽然有些数据已经不再准确了，但是John的基本理念没有变：

所有的技术都在变，但是速率不同。这意味着：你之前基于掌握的技术做出了一些技术决策，但是这些决策对于你目前掌握的技术来说可能已经不再正确了。

……

我的经验告诉我：所有有趣的问题都是扩展性方面的问题。这张图展示出了可扩展性的时间因素。

2006年，John还展示了一张饼图，列出了软件开发生命周期中的各项成本占比。其中，维护成本占到67%。也就是说，即使你能消除掉所有初期开 发和测试的成本，软件生命周期的成本也只能缩减三分之一。John还听说：有些要支持上百万行代码的组织认为，67%还是太低了，有些甚至能达到80%。

John提到：

Les Hatton发现：软件维护可以大概分为三类——修正（修复出问题的代码）、完善（改进某些没有问题的代码，比如提升性能或是降低维护成本）、适应。最后这一类将上述两个图结合在一起。适应性维护是说：因为你不能控制的某些东西发生改变，你必须要改变你的代码。

John的嵌入式领域工作经验告诉他：他常常碰到适应性维护情况。因为某些厂商常常不再生产某些关键硬件组件，而且没有兼容的可替代品。

而他在企业级服务器端的开发经验也有同样情况。

大量的软件基于商业或开源框架和程序库。你会想要升级到最新版本，因为要修复关键的bug，或者更新全新特性，因为这会影响你的最终交付时间，可最后却发现：你如此依赖的软件做出了“改进”，提供者调整了它的编程接口！这样的事情就会让产品经理急得像热锅上的蚂蚁。

John认为，要应对这样的事情，可以从Arduino和其8位Atmel megaAVR微控制器学习。他对比了自己使用的Mac Mini和Freetronics EtherMega单板，指出：

当我在为EtherMega单板编写代码时，我之前编写桌面或者服务器平台的经验，包括如何在时间和空间之间权衡等等，都可以抛出窗外了。举个例子，根据应用情况，如果需要某个值，每次都重新计算可能更好，而不是计算一次然后存储起来，因为在EtherMega上，存储字节要远比CPU处理周期更为重要。

John接下来提到：

为嵌入式系统开发软件和为高性能计算或大型分布式平台开发软件，二者需要的技能在很大称度上相同，我不是第一个发现这一点的人。

……

在高性能计算（之前成为超级计算）领域中有个趋势：“重新计算”，而不是“计算然后存储”或者“计算然后传输”。因为纯计算能力的增长要远远超过内存或通讯带宽的增长。为这些微控制器小不点编程，与为大型超级计算机编程，二者之间的相似之处比我们想象的多得多。

给微控制器小不点编写软件，这迫使你严肃对待资源限制，要先考虑时间和空间的权衡，要思考如何向上扩展，更要认真思考如何向下扩展。

最后，John号召大家都尝试下嵌入式开发：

在我的Amigo项目中使用像Arduino和FreeRTOS这样的技术，让我成为了一个更优秀、更聪明、更能深入思考的软件开发者。我相信你也同样可以从中受益，不管你的问题所在领域及其规模如何。

InfoQ的读者们，您在自己的项目中是否遇到了类似的问题呢？