学校网站建设会议讲话稿,成都食品网站开发,网站建设 食品,wordpress thegem前言
今天#xff0c;将两个设计原则#xff1a;KISS 原则和 YANGI 原则。其中#xff0c;KISS 原则比较经典#xff0c;耳熟能详#xff0c;但 YANGI 你可能没怎么听过#xff0c;不过它理解起来也不难。
理解这个两个原则的时候#xff0c;经常会有一个共同的问题将两个设计原则KISS 原则和 YANGI 原则。其中KISS 原则比较经典耳熟能详但 YANGI 你可能没怎么听过不过它理解起来也不难。
理解这个两个原则的时候经常会有一个共同的问题那就是看一眼就觉得懂了但深究的话又有很多细节不是很清楚。
怎么理解 KISS 原则中的 “简单” 什么代码才算 “简单”怎样的代码才算 “复杂”如何才能写出 “简单” 的代码YANGI 原则和 KISS 预原则说的是一回事吗 理解 KISS 原则
KISS 原则的意思是尽量保持简单。它的英文描述有好几个版本
keep it Simple and Stupid。keep it Short and Simple。keep it Simple and Straightforward。
我们知道代码的可读性和可维护性是衡量代码质量非常重要的两个标准。而 KISS 原则就是保持代码可读性和可维护性的重要手段。代码足够简单也意味着很容易读懂bug 难以隐藏。即使出现 bug修复起来也比较简单。
不过这条原则只是高速我们要保持代码简单但是并没有给出特别明确的方法论来指导如何开发出 “简单” 的代码。所以看着简单但是不能落地。
接下来为了能让这条原则落地来进一步进行讲解。
代码行数越少就越“简单”吗
我们先来看一个例子。下面的三段代码实现同一个功能检查输入字符串 ipAddress 是否是合法的 IP 地址。 合法的 IP 地址由四个数字组成并通过 “.” 进行分割。每组数字的取值范围是 0~255。第一组数字比较特殊不能为 0。 对比下面的代码你觉得哪段代码最符合 KISS 原则呢如果让你实现你选用哪种实现方式
// 第一种实现方式使用正则表达式
public boolean isValidIpAddress(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 isValidIpAddress2(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 isValidIpAddress3(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 ch ipChars[i];if (ch .) {if (ipUnitIntValue 0 || ipUnitIntValue 255) { return false; }if (isFirstUnit ipUnitIntValue 0) { return false; }if (isFirstUnit) { isFirstUnit false; }ipUnitIntValue -1;unitsCount;continue;}if (ch 0 || ch 9) { return false; }if (ipUnitIntValue -1) { ipUnitIntValue 0; }ipUnitIntValue ipUnitIntValue * 10 ch - 0;}if (ipUnitIntValue 0 || ipUnitIntValue 255) { return false; }if (unitsCount ! 3) { return false; }return true;
}第一种实现方式利用的是正则表达式只用三行代码就把这个问题搞定了。它的代码行数最少但是它不符合 KISS 原则。虽然代码行数少看似简单实际上去很复杂。
一方面正则表达式本身是比较复杂的写出完全没有 bug 的正则表达式本身就比较有挑战性另一方面并不是每个程序员都精通正则表达式。对于不怎么懂正则表达式的同时来说看懂并且维护这段正则表达式是比较困难的。
这种实现方式会导致代码的可读性和可维护性变差所以从 KISS 原则设计初衷上来讲这种实现方式并不符合 KISS 原则。
第二种实现方式利用了 StringUtils、Integer 类提供的一些现成的工具函数来处理 IP 地址字符串。这三种实现方式。第三种实现方式不使用任何工具函数而是通过逐一处理 IP 地址中的字符来判断是否合法。从代码行数上来说这两种实现方式差不多。但是第三种要比第二种更加有难度更容易写出 BUG。从可读性上来说第二种实现方式的代码逻辑更清晰、更好理解。所以在这两种实现方式中第二种实现方式更加 “简单”更加符合 KISS 原则。
你可能会说第三种实现方式虽然会有点复杂但是性能比第二种实现方式高。从性能角度来说选择第三章方式是不是更好些呢 第三种方式性能高的原因 一般来说工具类的功能都比较通用和全面所以在代码实现上需要考虑和处理更多的细节执行效率会有所影响。而第三种实现方式完全是自己操作底层字符串只针对 IP 地址这一种格式的数据输入来做处理没有太多多余的函数调用和其他不必要的处理逻辑所以在执行效率上这类定制化的处理代码方式肯定比通用的工具类要高些。 尽管第三章方式性能更高但是我还是倾向于第二种实现方式。因为第三种实现方式实际上是一种过度优化。除非 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]) { // 一直找到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表示模式串
public static int[] getNexts(char[] b, int m) {int[] next new int[m];next[0] -1;int k -1;for (int i 0; 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;
}这段代码完全符合我们提到的逻辑复杂、实现难度大、可读性差的特点但它不违反 KISS 原则。为什么这么说呢
KMP 算法以快速高效著称。当我们需要处理长文本字符串匹配问题几百 MB 大小文本内容的匹配或者字符串是某个产品的核心功能又或者字符串匹配算法是系统性能瓶颈的时候我们就应该选择尽可能搞下的 KMP 算法。而 KMP 算法本身具有逻辑复杂、实现难度大、可读性差的特点。本身就复杂的问题用复杂的方法解决并不违背 KISS 原则。
不过平时的项目开发中涉及的字符串匹配问题大部分都是针对比较小的文本。在这种情况下直接调用编程语言提供的现成的字符串匹配函数就足够了。如果非用 KMP 算法、BM 算法来实现字符串匹配那就真的违背 KISS 原则了。也就是说同样的代码在某个业务场景下符合 KISS 原则换一个应用场景可能就不满足了。
如何写出满足 KISS 原则的代码
实际上前面已经讲到了一些方法了。这里总结下
不要使用同时可能不懂的技术来实现代码。比如前面例子中的正则表达式还有一些编程语言中过于高级的语法等。不要重复造轮子要善于使用已有的工具类库。经验证明自己去实现这些类库出 BUG 的概率会高维护的成本更高。不要过度优化。不要过度使用一些奇技淫巧比如位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数来优化代码牺牲代码的可读性。
实际上代码是否足够简单是一个挺主观的评判。同样的代码有的人觉得简单有的人觉得不简单。所以评判代码是否简单还有一个很有效的间接方法那就是 code review。如果在 code review 的时候同事对你的代码有很多疑问那就说明你的代码有可能不够 “简单”需要优化啦。 我们在做开发的时候一定不要过度设计不要觉得简单的东西就没有技术含量。实际上越是能用简单的方法解决复杂的问题越能体现一个人的能力。 YAGNI 和 KISS 说的是一回事吗
YAGNI 原则的英文全称是You Ain’t Gonna Need It。翻译你不需要它。
在软件开发中它的意思是
不要去设计当前用不到的功能不要去编写当前用不到的代码。
这条原则的核心思想是不要过度设计。
比如我们的系统暂时只用 Redis 存储配置信息以后可能会用到 Zookeeper。根据 YAGNI 原则在未用到 Zookeeper 之前我们没必要提前编写这部分代码。当然这并不是说我们就不需要考虑代码的扩展性。我们还是要预留好扩展点等到需要的时候再去实现 Zookeeper 存储配置信息这部分代码。
还有我们不要在项目中提前引入不需要依赖的开发包。对于 Java 程序员来说经常使用 Maven 或者 Gradle 来管理类库。有些同时为了避免开发中 Library 包缺失而频繁地修改 Maven 或者 Gradle 配置文件提前往项目里引入大量常用的 library 包。实际上这样的做法是违背 YAGNI 原则的。
从刚刚的分析可以看出YAGNI 原则和 KISS 原则并非一回事。KISS 原则讲的是“如何做”的问题尽量保持简单而 YAGNI 原则说的是 “要不要做的问题”当前不需要的就不要做。
总结
KISS 原则是保持代码可读性和可维护性的重要手段。KISS 原则中的 “简单” 并不是以代码行数来考量的。代码行数越少并不代表代码越简单还需要考虑代码的复杂度、实现难度、代码的可读性等。而且本身就复杂的问题用复杂的方法解决并不违背 KISS 原则。除此之外同样的代码在某个业务场景下满足 KISS 原则换一个场景就可能不满足了。
对于 KISS 原则还总结了下面几条原则
不要使用同事可能不懂的技术来实现代码不要重复造轮子要善于使用已有的工具类库不要过度优化
