是什么
KISS 是 Keep It Stupid Simple 或者 Keep It Simple, Stupid 的缩写
究竟是什么
这项原则已经成为了我软件开发生涯中的制胜宝典。软件工程师和开发者们当今普遍存在的一个问题，是倾向于使问题过度复杂化。
一个典型的例子，当一个开发者面对一个问题的时候，如果他们把这个问题分解成多个他们能理解的小问题，他们就能够尝试编写代码来实现解决方案。我敢打赌，把一个问题分解得不够细或者不够易于理解，是开发者们十有八九都会犯的错误。这样就会导致，即使是最简单的问题，还是使了用非常复杂的实现方法。除此之外，还会出现那种我们认为只会在 BASIC 的 goto 语句使用的“代码大杂烩”，但这放在 Java 中就会造成类文件中含有500 - 1000行的代码，每个方法都包含了上百行的代码。 当开发者在编写代码的时候意识到他的原始解决方案中出现了异常情况将会产生代码混乱的结果。如果开发者有将问题进一步细化的话，这些异常情况也将会得到解决。
KISS 原则带来的好处
- 你将能够更快地解决更多的问题
- 你将能够使用更少的代码解决复杂的问题
- 你将能够编写更高质量的代码
- 你将能够构建更大却更易于维护的系统
- 你的代码库将会变得更加灵活和易于扩展、修改或者重构来应对新的需求
- 你将能够实现比你想象的更多
- 在所有的代码变得足够的简单之后，你将能够胜任在一个大的开发团队和大的项目组的工作
如何将 KISS 原则应用到自己的工作中
接下来有几个步骤需要执行，炒鸡简单，但对一些人来说会具有挑战性。就像听起来那么容易，保持简单，对自己来说只是一个关于耐心的问题。
- 谦逊点，不要以为自己是个大天才，这才是你对自己最根本的误解。 保持谦逊将会使你最后达到大天才的状态，若非如此，谁又会在乎呢！你的代码已经简单得够蠢的了，你就算不是天才也能够理解它。
- 将你的任务分解成每个编程时间不超过 4 - 12 小时的子任务
- 将你的问题细分为多个子问题，确保每个子问题用一个或少量的类就能解决掉
- 保持方法函数的精简，每个方法都绝不超过 30 - 40 行代码，每个方法只针对一个问题，而不是多个用例。如果你的一个方法中含有多种情况的处理，你就要继续将它分成一个个更小的方法。这样不但可以提高可读性和利于维护，而且可以大大地提升定位 bug 的速度。（你会学习爱上在编辑器中使用
右击 → 重构） - 保持类文件的精简，就像对付方法函数一样。
- 先解决问题，再去编写代码。千万不要反着来。 很多开发者是一边编写代码一边解决问题的，这样做没有错。事实上，你可以这样做，同时还遵循着上面的方法论。 如果你有在内心把事情分解成又多个很小部分组成的习惯，那就尽量把这种习惯用在你编写代码这件事情上。不要害怕一次次的重构代码。代码的数量和行数不是最终衡量的结果，除非你认同它们越少才是越好这种观点。
- 不要害怕丢弃你的代码，重构和重写是两个非常重要的领域。当你遇到尚未出现的需求，或者在你最开始编程的时候没有意识到可以使用一个更好的方案来解决新的或旧的问题。 如果你已经按照了上面的方法去做，那么就可以实现将需要重写的代码量最少化，如果你没有遵循上面的方法，那么无论如何应该都要重写代码了
- 对于所有其他情景来说，令它们变得尽可能的简单，这也是所应用到的最困难的一种行为模式，然而一旦你掌握了这种方法，当你回首往事的时候会感叹：我TM的当初是怎么过来的。
有没有与 KISS 相关的例子
数不胜数，我会找一些真正优秀的范例上传到这里，但是我将以下的想法分享给你：
在全世界最美妙的算法当中，总是会有一部分是通过少量的代码就能实现的，而且，当我们仔细观察这些代码的时候，我们很容易就会弄清楚他们的含义。这些算法的创新者，会把问题分解直到他们可以很容易地理解以至于可以实现的程度。 很多优秀的问题都是被一些不是那么优秀的程序员解决掉的，但这并不影响他们产出优秀的代码！
KISS 原则只适用于 Java 编程吗？
当然不是，它适用于很多其他编程语言，甚至还能扩展到你生活中的其他领域。KISS 原则不适用的范围有：情感，爱情，还有一样最重要的，就是你的婚姻。