需求是这样的：

写一个函数，根据结婚的次数给出婚假的天数。如果未婚，婚假天数当然是 0 天，如果是初婚，婚假天数为 15 天，如果是再婚或第 N 次结婚（N >= 2），则婚假天数为 3 天。

工作第一年

文件：main.js

function howLongMarryHolidays(marry_times) {
    if (marry_times == 0) {
        return 0;
    } else if (marry_times == 1) {
        return 15;
    } else {
        return 3;
    }
}

很多人可能都写过这样的代码。可以看到，这个版本的代码非常简单，基本上就是需求的直接翻译，它没有错误，甚至性能也不错。很多时候这样的代码可能在某个系统中运行很多年，但也有些时候，由于需求变更，你或你的继任者不得不对其进行重构。

工作第三年

文件：main.js

function howLongMarryHolidays(marry_times) {
    return [0, 15, 3][marry_times <= 1 ? marry_times : 2];
}

工作一段时间，了解了更多语言上的技巧后，你可能会写出这样的代码。这个时期，你相信高手的标志之一是用最少的代码解决问题，比如能用一行代码解决的问题，绝对不用两行。

这个时间段你代码看起来非常精简，有时也不乏优美之作，但也有一些为了精简而抛弃了可读性，同时损失的还有代码的可维护性。比如，如果需求突然变为再婚有 10 天婚假，第三次或更多次结婚时才是 3 天婚假，这时你需要深入到 howLongMarryHolidays 方法的实现细节中，至少需要修改两处地方才可以完成需求。

工作第十年

文件：config.js

exports.holiday_data = {
    // year: holidays
    0: 0,
    1: 15,
    'other': 3
};

文件：main.js

var holiday_data = require('./config').holiday_data;

function howLongMarryHolidays(marry_times) {
    var key = (marry_times in holiday_data) ? marry_times : 'other';
    return holiday_data[key];
}

在经历了无数次需求变更以及无数次熬夜加班之后，你逐渐意识到，写最少的代码并不能让你避免加班，代码的可维护性比精简长度更重要。经过分析，你发现这个简单的需求其实分为可变的配置项与基本不会变的逻辑两部分，于是，代码也被自然地分解成了两个部分，——配置与逻辑进行分离。

现在，代码量的确有所增加，但收益是逻辑更清晰了，维护时的成本及出错率也都降低了。当需要改变婚假规则时，一般只要修改 config.js 中的配置即可，并且这个修改通常来说是安全的。

小结

这只是一个简单的例子，对这个小例子而言，三种方法没有太大的差异。但如果遇到更复杂的需求，也许可以像最后一个方法那样，将易变的部分与稳定的部分隔离开来。你的代码似乎变长了，但长期来看，你的工作变少了。