Andorid|java 设计模式之--KISS

The Kiss Principle

KISS代表什么

KISS是Keep It Stupid Simple 或者 Keep It Simple ,Stupid的简写

KISS是什么

KISS的原则已经成为这些年我作为软件工程师成功的关键，一个普遍的问题是，今天的软件工程师和开发者们倾向于以更复杂的方式来处理问题（但是他们并不是故意这样做的）

通常当开发者遇到问题时，他们会把问题分解的更小的他们容易理解的问题，然后他们开始编码来解决问题，我要说的是在10个开发者中，有8个或者9个犯了错误，他们并没有将问题拆分的足够小或者拆分成小到足够容易理解，结果就是处理每一个小问题都变得非常复杂，另一方面是写出“spagetthi code”(面条式代码，代码结构复杂，结构混乱，难以理解)，我们认为只有BASIC会使用 *goto语句*，但是在java中，这会造成一个类会达到500-1000行代码，每个方法都有几百行代码

混乱的代码结构是原先的代码解决方案带来的意外，如果开发者把问题进一步分解，就可以解决

我将从KISS中获得什么好处

可以更快的解决更多的问题.
用较少的代码解决复杂的问题.
写出更高质量的代码.
可以创建更大的系统工程，更易于维护.
你的代码更有弹性，更容易扩展和修改，当有新的需求进来时，更容易重构.
你会因此得到更多好处比你想象中的还要多.
如果你的代码足够***简单***，你就可以开始在大型项目和大型团队中工作.

在工作中，我如何运用KISS 原则

采取下面的这些方法，非常简单但是可能充满挑战。就像这个原则听起来的那么容易，尽量保持简单，其实大多时候就是耐心而已。

      请谦卑，不要认为自己是个超级天才，你犯的第一个错误就是，你认为保持谦卑最终你就会变成天才。即使你不这么认为，谁在乎呢！只要你让自己的代码简单，就不必非要用天才的标准来束缚自己。
      将你的任务分解成子任务，直到你认为每个子任务只需要4-12个小时的编码就可以完成
      把你的问题分解成许多小问题，其中的每个小问题都可以用一个或者几个类就可以解决
      使方法尽可能的小，每个方法不超过30-40行，每个方法只应该解决一个小问题，不要在方法中过多的使用条件语句，把他们分解到更小的方法中去，这样做不仅更易于阅读和维护，而且找bug会更快，在你的编辑器中你会爱上 Right Click+Refactor
      保持类的简短，同样的也适用于方法
      解决问题，马上开始编码，而不是这样：当他们一边编码，一边解决问题，这看上去并没有错。事实上，你可以照着上面说的做。如果你能力将问题拆分成更小颗粒度的问题，那么就想尽办法去做。不要害怕一遍又一遍的重构你的代码。行数和代码数的多少不是测量标准，当然如果你可以让代码变得更少也不错！
     不要害怕抛弃代码，重构和重写是两种重要的方式，当需求不存在，或者当你编码时并没有意识到，但是后来发现有更好的解决方案。如果你按照上面的建议，需要重写的代码应该是最小的，如果你没有按照上面说的做，代码也应该被重写。
     对于所有其他场景而言，尽量保持简单，这是最难适应的行为模式，但是一旦你适应了，你就会发现并且反问自己，我真的无法想想我以前是怎么工作的！

有Kiss 原则的使用实例吗

有很多这样的例子，稍后我会附上找一个非常了不起的示例，但是请思考我下面说的：
某些最伟大的算法总是用最少的代码实现的。当我们阅读这些代码时，理解起来很 容易。发明这些算法的人，他们把问题分解，直到他们更容易理解这些问题，从而解决问题。

很多优秀的问题解决者，他们不是伟大的程序员，但是他们能编写出伟大的代码！

Kiss 原则只适用于java编码吗

当然不是，他可以应用于许多编程语言并且你可以把他拓展到你生活的许多其他领域.
那些Kiss原则不适用的领域包括：情感，爱以及至关重要的婚姻 ：）