KISS原则和YAGNI原则

如何理解 KISS 原则？

KISS 原则的英文描述有好几个版本：

Keep It Simple and Stupid
Keep It Short and Simple
Keep It Simple and Straightforward

它们表达的意思其实都差不多，其实就是：尽量保持简单。

我们知道，代码的可读性和可维护性是衡量代码质量非常重要的两个标准。而 KISS 原则就是保持代码可读性和可维护性的重要手段。代码足够简单，也就意味着很容易读懂，bug比较难隐藏。即便出现bug，修复起来也比较简单。

代码行数越少就越“简单”吗？

我们先来看一个例子。下面三段代码可以实现同样一个功能：检查输入的字符串 ipAddress 是否是合法的IP地址。

// 第一种实现方式：使用正则表达式
public boolean isValidIpAddressV1(String ipAddress) {
	if (StringUtils.isBlank(ipAddress)) return false;
	String regex = "^(1\\d{2}|2[0-4]\\d|25[0-5]|[1-9]\\d|[1-9])\\."
			+ "(1\\d{2}|2[0-4]\\d|25[0-5]|[1-9]\\d|\\d)\\."
			+ "(1\\d{2}|2[0-4]\\d|25[0-5]|[1-9]\\d|\\d)\\."
			+ "(1\\d{2}|2[0-4]\\d|25[0-5]|[1-9]\\d|\\d)$";
	return ipAddress.matches(regex);
}

// 第二种实现方式：使用现成的工具类
public boolean isValidIpAddressV2(String ipAddress) {
	if (StringUtils.isBlank(ipAddress)) return false;
	String[] ipUnits = StringUtils.split(ipAddress, '.');
	if (ipUnits.length != 4) {
		return false;
	}
	for (int i = 0; i < 4; i++) {
		int ipUnitIntValue;
		try {
			ipUnitIntValue = Integer.parseInt(ipUnits[i]);	
		} catch (NumberFormatException e) {
			return false;
		}
		if (ipUnitIntValue < 0 || ipUnitIntValue > 255) {
			return false;
		}
		if (i == 0 && ipUnitIntValue == 0) {
			return false;
		}
	}
	return true;
}

// 第三种实现方式：不使用任何工具类
public boolean isValidIpAddressV3(String ipAddress) {
    char[] ipChars = ipAddress.toCharArray();
    int length = ipChars.length;
    int ipUnitIntValue = -1;
    boolean isFirstUnit = true;
    int unitsCount = 0;
    for (int i = 0; i < length; ++i) {
        char c = ipChars[i];
        if (c == '.') {
            if (ipUnitIntValue < 0 || ipUnitIntValue > 255) return false;
            if (isFirstUnit && ipUnitIntValue == 0) return false;
            if (isFirstUnit) isFirstUnit = false;
            ipUnitIntValue = -1;
            unitsCount++;
            continue;
        }
        if (c < '0' || c > '9') {
            return false;
        }
        if (ipUnitIntValue == -1) ipUnitIntValue = 0;
        ipUnitIntValue = ipUnitIntValue * 10 + (c - '0');
    }
    if (ipUnitIntValue < 0 || ipUnitIntValue > 255) return false;
    if (unitsCount != 3) return false;
    return true;
}

第一种实现方式是使用正则表达式，代码行数是最少的，那是否就符合 KISS 原则？答案是否定的。虽然代码行数最少看似简单，实际上却很复杂，一方面，因为正则表达式本身是比较复杂的，写出完全没有bug的正则表达式本身就比较有挑战；另一方面，并不是每个程序员都精通正则表达式，而他们维护这段正则表达式也就很困难，反而导致代码可读性和可维护性变差。所以这种实现方式并不符合 KISS 原则。

第二种实现方式和第三种实现方式，更倾向于选择第二种实现方式。为什么？第三种方式通过逐一处理IP地址中的字符来判断是否合法，相比第二种使用工具类的方式更加有难度，更容易写出bug。第二种实现方式代码逻辑更清晰、更好理解，更加符合 KISS 原则。

不过，你可能会说，第三种实现方式虽然实现起来稍微有点复杂，但性能要比第二种方式高一些。

其实，第三种方式是属于过度优化。除非 isValidIpAddress() 是影响系统新性能的瓶颈代码，否则，这样优化的投入产出比并不高，增加了代码实现的难度、牺牲了代码的可读性，性能上的提升却并不明显。

代码逻辑复杂就违背 KISS 原则吗？

刚刚我们提到，并不是代码行数越少就越 “简单”，还要考虑逻辑复杂度、实现难度、代码的可读性等。那如果一段代码的逻辑复杂、实现难度大、可读性也不太好，是不是就一定违背 KISS 原则？回答这个问题之前，我们先来看下这段代码：

// KMP algorithm: a, b分别是主串和模式串；n, m分别是主串和模式串的长度
public static int kmp(char[] a, int n, char[] b, int m) {
    int[] next = getNexts(b, m);
    int j = 0;
    for (int i = 0; i < n; ++i) {
        while (j > 0 && a[i] != b[j]) {
            j = next[j - 1] + 1;
        }
        if (a[i] == b[j]) {
            ++j;
        }
        if (j == m) {
            return i - m + 1;
        }
    }
    return -1;
}

// b表示模式串，m表示模式串的长度
private static int[] getNexts(char[] b, int m) {
    int[] next = new int[m];
    next[0] = -1;
    int k = -1;
    for (int i = 1; i < m; ++i) {
        while (k != -1 && b[k + 1] != b[i]) {
            k = next[k];
        }
        if (b[k + 1] == b[i]) {
            ++k;
        }
        next[i] = k;
    }
    return next;
}

上面的代码是 KMP 字符串匹配算法的代码实现。这段代码完全符合我们刚提到的逻辑复杂、实现难度大、可读性差的特点，但它并不违背KISS原则。如果选择使用 KMP 算法是因为系统瓶颈，本身就复杂的问题，用复杂的方法解决，并不违背 KISS 原则。

不过，平时的项目开发如果问题不影响性能瓶颈，能用编程语言提供的现成的函数就能足够的情况，还是非得用 KMP 算法等复杂方式实现，那就真的违背 KISS 原则了。

如何写出满足 KISS 原则的代码？

实际上，我们前面已经讲到了一些方法，这里稍微总结一下：

• 不要使用同时可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等

• 不要重复造轮子，要善于使用已有的工具类库。经验证明，自己去实现这些类库，出bug的概率会更高，维护的成本也比较高

• 不要过度优化。不要过度使用一些奇技淫巧（比如，位运算替代算数运算、复杂的条件语句代替if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性

实际上，判断代码是否足够简单是一个挺主观的判断，同样的代码有人觉得简单，有人觉得不够简单。评判代码是否简单，还有一个很有效的间接方法，那就是code review。如果在code review时，同事对你的代码有很多疑问，那就说明你的代码可能不够“简单”需要优化。

还有，一定不要过度设计，不要觉得简单的东西就没有技术含量。实际上，越是能用简单的方法解决复杂的问题，越能体现一个人的能力。

YAGNI 跟 KISS 说的是一回事吗？

YAGNI（You Ain’t Gonna Need It）原则，直译就是：你不会需要它。它的意思是：不要去设计当前用不到的功能；不要去编写当前用不到的代码。这条原则的核心思想就是：不要过度设计。

当然，这并不是说我们就不需要考虑代码的扩展性，我们还是要预留好扩展点。再比如，我们不要再项目中提前引入不需要依赖的开发包，这样的做法也是违背YAGNI原则。

从刚刚的分析我们可以看出，YAGNI 原则跟 KISS 原则并非一回事。KISS 原则讲的是 “如何做” 的问题（尽量保持简单），而 YAGNI 原则说的是 “要不要做” 的问题（当前不需要的就不要做）。

总结

KISS 原则是保持代码可读性和可维护性的重要手段。关于 KISS 原则可以有以下总结：

• KISS 原则中的 “简单” 并不是以代码行数来考量的。代码行数越少并不代表代码越简单，我们还要考虑逻辑复杂度、实现难度、代码的可读性等

• 本身就复杂的问题，用复杂的方式解决，并不违背KISS原则

• 同样的代码，在某个业务场景下满足 KISS 原则， 换一个应用场景可能就不满足了

对于如何写出 KISS 原则的代码，有以下几条指导原则：

• 不要使用同事可能不懂得技术来实现代码

• 不要重复造轮子，要善于使用已经有得工具类库

• 不要过度优化