设计模式专栏：http://t.csdnimg.cn/3a25S

目录

1.引言

2.代码并非行数越少越简单

3.代码复杂不一定违反 KISS 原则

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

5.YAGNI原则和 KISS 原则的区别

---

1.引言

        KISS原则的英文描述有3种版本:Keep It Simple and Supid、 keep It Short and Simple、Keep It Simple and Straightforward。其实，它们要表达的意思差不多，即“尽量保持简单”。

        KISS原则是一个“万金油”一样的设计原则，可以应用在诸多场合。它不仅经常用来指导软件开发，还经常用来指导系统设计、产品设计等，如冰箱、建筑和手机的设计等，本书讲解的是代码设计，因此，接下来，我们重点讲解如何在程序开发中应用KISS 原则。

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

        不过，KISS原则只是告诉我们，要保持代码“简单”，但并没有讲什么样的代码才算得上“简单”，更没有给出明确的方法来指导如何开发“简单”的代码。因此，KISS 原则虽然简单但不太容易落地。

2.代码并非行数越少越简单

        在下面的示例代码中，我们使用3种方式实现同一功能:检查输入的字符串ipAddress是否是合法的P地址。一个合法的P地址由4个数字组成，并且通过“.”进行分隔。每个数字的取值范围是 0~255(第一个数字比较特殊，不允许为0)。对比下面3段代码，读者认为哪一段代码符合KISS 原则呢?

//第一种实现方式:使用正则表达式
public boolean isValidIpAddressVl(String ipAddress)
{if(StringUtils.isBlank(ipAddress)){return false;}String regex = "^(1\\d{2)|2[0-4]\\d125[0-5]|[1-9]\\dl[1-9])\\."+"(1\\d(2}12[0-4]\\d|25[0-5]|[1-9]\\dl\\d)\\."+"(1\\d{2)12[0-4]\\d125[0-5]1[1-9]\\dl\\d)\\."+"(1\\d{2)12[0-4]\\d125[0-5]1[1-9]\\dl\\d)$";return ipAddress.matches(regex);
}//第二种实现方式:使用现成的工具类
Public boolean isValidIpAddressV2(String ipAddress)
{    if (Stringutils.isBlank(ipAddress))return false;String[] ipUtits = 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;}it (ipUnitIntValue <0 || ipUnitIntValue > 255){return false;}if(i == 0 && ipUnitIntValue== 0){return false;}}return false;
}//第三种实现方式:不使用任何工具类
public boolean isValidIpAddressV3(String ipAddress)
{char[] ipChars = ipAddress.toCharArray();int length = ipChars.length;int ipUnitIntValue = -l;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=-l;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;
}

        第一种实现方式利用正则表达式，3行代码就解决了问题。第一种实现方式的代码行数最少，那么是否符合KISS原则呢?答案是否定的。虽然第一种实现方式的代码行数最少，看似简单，但使用了比较复杂的正则表达式，而想要写出完全没有bug的正则表达式是很有挑战性的。对于不熟悉正则表达式的人，看懂并维护含有正则表达式的代码是比较困难的。基于正则表达式的实现方式导致代码的可读性和可维护性变差，因此，从KISS原则的设计初衷(提代码的可读性和可维护性)来看，这种实现方式并不符合 KISS原则。

        第二种实现方式使用StringUtils类和 Integer 类提供的一些现成的工具函数来处理IP地址字符串。第三种实现方式不使用任何工具函数，而是通过逐一处理IP地址中的字符来判断是否合法。从代码行数上来说，第二种实现方式和第三种实现方式的代码行数差不多。但第三种实现方式比第二种实现方式更有难度，更容易产生bug。从可读性来说，第二种实现式的代码逻辑更清晰、更好理解。相比来说，第二种实现方式更“简单”，符合KISS 原则。 虽然第三种实现方式稍微复杂，但其性能要比第二种实现方式高一些。从性能的角度说,选择第三种实现方式是不是更好呢?在回答这个问题之前，我们先解释一下为什么第三种实现方式的性能更高一些。一般来说，工具类的功能是通用和全面的，因此，在代码实现面、需要兼容和处理更多的情况、执行效率就会受到影响。而第三种实现方式，完全是自己操作底层字符，只针对IP地址这一种输入格式，没有其他不必要的处理逻辑，因此，在执行率方面，这种类似定制化的处理代码肯定比通用的工具类高。

        尽管第三种实现方式的性能更高，但我们还是倾向于选择第二种实现方式，因为第三种实现方式上实际是过度优化。除非isValidIpAddress函数是影响系统性能的瓶颈代码，否则，这样优化的投入产出比并不高，反而增加了代码实现的难度、牺牲了代码的可读性，而性能上的提升并不明显。

3.代码复杂不一定违反 KISS 原则

        上文我们提到，代码并非行数越少越简单，因为还要考虑逻辑复杂度、实现难度和代码的可读性等。如果一段代码的逻辑复杂、实现难度大、可读性也不太好，是不是一定违反KISS原则呢?在回答这个问题之前，我们先来看下面这段代码(来自《数据结5之美》中 KMP 算法的代码实现)。

//P算法: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 +l;}}return -l;
}
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;
}  

        上面这段代码逻辑复杂、实现难度大和可读性差，但它并不违反KIS原则，KMP算法以高效著称，当需要处理长文本字符串匹配问题(如几百MB大小的文本内容的匹配)，或者字符串匹配是某个产品的核心功能(如Vim、Word等文本编辑中的文本查找)，抑或字符串匹配算法是系统性能瓶颈时，我们就应该选择KMP算法。而KMP算法本身具有逻辑复杂、实现难度大和可读性差特点，因此，使用复杂的算法解决复杂的问题，并不违反KISS原则。

        不过，平时的项目开发涉及的字符串匹配问题大多针对较小的文本，在这种情况下，直接调用编程语言提高的现成的字符串匹配函数即可。如果是KMP算法实现较小文本的字符串匹配，就违反KISS原则了。也就是说，对于同一段代码，在某个应用场景下满足KISS原则，换一个应用场景后可能就不满足 KISS 原则了。

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

        关于如何写出满足 KISS 原则的代码，前面已经讲了一些方法，这里总结一下。

        1)慎重使用过于复杂的技术来实现代码，如复杂的正则表达式、编程语言中过于高级的语法等。

        2)不要“重复造轮子”，首先考虑使用已有类库。根据作者的经验，如果自己实现类库那么产生 bug 的概率更高，维护成本也更高。

        3)不要过度优化。尽量避免使用一些“奇技淫巧”(如使用位运算代替算术运算、使用复杂的条件语句代替 if-else 等)来优化代码。

5.YAGNI原则和 KISS 原则的区别

        当YAGNI(You Ain’t Gonna Need It)原则用在软件开发时，其含义是: 不要去设计当前用不到的功能;不要去编写当前用不到的代码。实际上，这条原则的核心思想是:不要过度设计。和 KISS 原则一样，YAGNI原则也称得上“万金油”一样的设计原则。

        例如，某系统暂时只使用 Redis来存储配置信息，以后可能会用到ZooKeeper。根据 YAGNI原则，在未用到ZooKeeper之前，我们没必要提前编写这部分代码。当然，这并不是说就不需要考虑代码的扩展性了。我们还是有必要预留扩展点，在需要引入ZooKeeper时，能够在不改太多代码的情况下完成扩展。

        又如，不要在项目中提前引入不需要依赖的开发包。Java程序员经常使用Maven或Grade 管理项目依赖的类库，我们发现，有些程序员为了避免开发中类库的缺失而频繁地修改Maven或 Gradle 配置文件，提前向项目里引入大量常用的类库。实际上，这种做法违反YAGNI原则。

        从刚才的分析可以看出，YAGNI原则与KISS原则并非一回事。KISS原则讲的是“如何做(尽量保持简单)，而 YAGNI原则讲的是“要不要做”(当前不需要的，就不要做)。