你是否曾经参加过这样的会议：
发言人1：客户希望页面的背景是绿颜色的。
发言人2: 我们能确定他们会一直使用绿色吗？也许我们需要增加一个配置背景颜色的选项。
没有人反对，经理从来不参加这种无聊的设计会议，会议室里沉默了下来….
发言人3：只提供一个设置背景颜色的配置项会显得功能很弱，我们最好能提供全套的颜色配置方案。
发言人4：你是指提供多个成套配色方案，还是指让用户可以自己去配色？
发言人2(麻烦的始作俑者)：当然要提供成套方案，但用户可以自主修改，这样我们就能把所有可能性都考虑进去。
讨论一直持续下去，直到他们决定开发一个拥有无数个颜色选择器和其它功能的换肤系统，而会议的收场是这样一句：
发言人6：这个系统听起来很棒，但我们应该用什么颜色作为系统的缺省背景颜色呢？
…没有人还记得：
客户指定要求的是绿色，只要绿色，没有其它颜色。
是不是有点夸张？也许吧，但我是参加过跟此类似的会议的。就我来看，我参加过的会议有的比这更糟糕，我并不想中伤任何人，因为我自己也不是个无可挑剔的人，对于这些人我就不说了。
总之，在这样的会议讨论中，很多事情都走入迷途，对于系统设计，我们应该明白一个简单的规律——遗憾的是没有人意识的这个简单规律——系统设计的头一个规律——一个我们应该铭记在心，在任何系统或架构设计会议上都该反复默念的规律：
今天的常量是明天的变量。
这并不是一个能够人一眼看穿的规律，但如果你能认识到几乎在所有的系统设计方面这都是一个事实的话，这能成为一个指导性的规律，它能够让你在做决定时更有信心，做出更符合实际的决定。
可问题就在于，搞技术的人大部分都不知道今天是什么日子。他们通常会犯两种错误，要么：
- 当所有需要做的事只是处理今天的常量这样的简单案例时，他们却在孜孜不倦为明天的变量做计划，评估，设计和编程。
- 要么，他们不明白，当“客户变更需求”时，客户的做法和任何人无异——从昨天拿来简单的东西，在今天把它变的复杂一些。
所以，你可以把这句话反过来说，“今天我做的所有事情明天都会变。会变的更复杂。任何我认为是固定或恒量的东西，将来都会变化和变成变量。”
这是什么意思？
我们都知道（希望如此），我们不应该在代码里直接嵌入常量，这会使代码很难维护。我们在头文件里定义常量，或获取外部被当作参数传进来的资源。这样能使代码更灵活，这是好事。这样的代码更健壮，它能在不需要改动的情况下处理更多的场景。
要理解“今天的常量是明天的变量”，你首先要认识到，在我们的系统中隐藏着各种形式的“常量”，藏在我们很难发现的地方，这使得当明天来临、它们不再是恒定和常量时，你很难去修改它们。
另外一个对于这个规律要理解的事情是，时刻记着今天是什么日子。大部分我们今天在做的东西、实现到的功能也许永远都不会再改变。人们特别容易去设想它们可能会改变，但究竟会怎样，无从得知。所以，今天常量不要把它改成明天的变量。
重回到会议上
让我们重回到最初提到的会议。下面是当人们知道“今天的常量是明天的变量”的规律后会议的进行方式。
发言人1：客户希望页面的背景是绿颜色的。
发言人2:我们能确定他们会一直使用绿色吗？也许我们需要增加一个配置背景颜色的选项。
我们的英雄：我们不知道客户是否会一直使用绿颜色，我们永远都不可能知道客户在何时会改变他们的想法，我们知道的是，今天的常量是明天的变量。然而，我们应该把这种颜色放在CSS样式表里，而不是直接嵌入到网页里，当日后如果需要改变时，我们就很容易的做到，怎么样？
有人含含糊糊的说是的，应该放到样式表里，会议继续。
这个例子很牵强吗？
这确实是一个非常牵强的例子，会有人不使用样式表吗？会有人在代码里嵌入常数吗？
天真的孩子们，事实证明，我们并不总是使用CSS样式表。当网页开发刚流行时，CCS是一个可有可无的选项(相信我！)，那时我们就是直接把样式信息直接放在网页标记里，这就是在代码里嵌入常数，只是在不久前人们才意识到这样不正确，CSS才被人们发现。
这种事情一遍一遍的在我们身边反复发生，你想起来会感到惊奇，请找出你认为应该常量却被“埋没在代码里”的东西，请把它们定义成常量。
今天的文章是明天的承诺
关于这个话题我还会发表很多的文章，不管未来会发生什么变化，但今天我会严格按照我的计划发表。
祝好运。
[本文英文原文链接：Do You Know What Day It Is? ]