The Kiss Principle
什么是KISS原则？
KISS是“Keep It Stupid Simple”或者“Keep It Simple, Stupid”的缩写。
KISS原则有什么意义？
这个原则是我多年软件工程中获得成功的一个关键。当今软件工程师和开发人员面临的一个普遍问题是，他们倾向于使问题复杂化。
通常情况下，当一个开发者遇到问题时，他会将这个问题分解成自己能够理解的更为细小的问题，然后才会去进行编码实现这个问题。但我想说百分之八九十的开发者都会犯这样一个错：他们并没有将问题分解的足够小或者说足够容易理解。这导致了一方面可能需要用非常复杂的实现去解决一个非常简单的问题，另一方面就是代码写的像意大利面一样，代码非常臃肿混乱，在BASIC中一个goto就可以搞定的事，同样在Java中可能需要数百行代码才可以搞定。
这些混乱的代码之所以存在，就是因为直到开发者开始编码时才发现之前的解决方案还存在各种异常情况没考虑到。如果开发者在设计解决方案时能够将问题分解的足够小，那么这些异常情况就不会被遗漏了。
我们能够从KISS原则中获得什么样的好处？
- 你将会以更快的速度解决更多的问题
- 你将会用很少的代码去解决复杂的问题
- 你将能够写出更高质量的代码
- 你将能够设计出更大的系统，并且能够更加容易的维护
- 当新需求来的时候，你的代码将能够更灵活，更容易的去扩展、修改以及重构
- 你将能够获得超出你想象的好处
- 因为代码写的非常简洁，你将能够在大型的开发团队、项目中如鱼得水
我如何才能将KISS原则应用到我的工作中？
这儿有几个非常简单的步骤可以遵循，对于有些人来说可能有点挑战。听起来非常容易，保持简单(keeping it simple)，这是一个耐心的问题，容易与否完全取决于你自己。
- 保持谦逊，不要认为自己是一个超级天才，否则这就是你犯得第一个错误。
相反保持谦逊，最后却一定能够让你变成一个超级天才=)，就算你不是天才，也没关系。只要你的代码写的足够简洁，就算你不是天才也能够胜任它。（只要代码写的足够简洁，傻子也能理解） - 把你的任务分解成足够细小的子任务，原则上来讲，这些子任务的的编码时间不应该超过4-12小时。
- 把你的问题分析成许多足够小得问题。每一个小问题应该在一个类或者极少的几个类里解决掉。
- 保持的方法足够小，每一个方法原则上不应该超过30-40行代码。每一个方法应该只解决一个小问题，而不应该包含多种使用情况。
如果你的方法中有许多条件分支，那么就把他们移除这个方法作为更小的方法。
这样做不仅让代码更容易阅读和维护，也会让你能够更快的定位bug。
你要学会去喜欢重构你的代码。 - 保持你的类足够小。在方法中描述的方法同样适用在这里。
- 先想好解决问题的办法，然后再进行编码，而不是相反。
很多开发者喜欢一边编码一边解决问题，当然这也没没错。事实上，你也可以这样做，并坚持编码和解决问题同时进行。
如果你能在编码的同时，依然有能力把问题进行分解，那你就这样做。不要害怕重构你的代码。最终结果才是重要的，代码行数并不是一个测量标准，当然了代码行数越少越好。 - 不要害怕删除代码。重构代码和二次编码是非常重要的两个部分。当你遇到一个之前不存在的需求时，或者这个需求在你开始编码时并没有被意识到，你可能会想到一个更好的办法来解决这些问题。
如果你一直遵循上面的这些建议，那么重新编写的代码量可能非常小。相反，如果你并没有遵循这些建议，那么你的代码可能处处都需要重新编写了。 - 对于其它所有场景，一样尽可能的保持简单，这样做可能会很难，但是一旦你做到了，等你回顾的时候，你将会对你取得的成果大吃一惊。
是否有一些KISS原则的例子？
有非常多，我将会找一些真正非常棒的例子放在这儿。但是现在我想让你们思考下面这几句话。
世界上最牛逼的算法一般都是代码行数最少的。当阅读这些代码时，我们能够非常容易的理解它们。这些算法的创新者，在进行编码前会将这些问题进行充分分解，直到这些问题能够被非常容易的理解与实现。
许多伟大问题的解决者并不是一个伟大的程序员，但他们依然能够写出伟大的代码。
KISS原则只适用Java编码吗？
很显然并不是，它适用于其它许多的编程语言，并且可以扩展到你的生活方方面面。
KISS原则不适用的领域有：情感、爱，当然最重要的，不要把它应用到你的婚姻中:)
