大约在60年前，美国军方的软件开发开始遵循一个原则，叫KISS原则。他们希望武器系统中所用的每个指令都是极其简单和傻瓜式的。这个原则后来在编程领域中被广泛采用，如今好多著名的开源框架都是遵循这一原则来开发，并最终取得了巨大的成功。
在上一文中《Apache的架构师们遵循的30条设计原则》，第一个原则便是KISS原则，几年前简单的了解过这个原则，前几日又翻出来，仔细查看后，倍感震惊，这篇原文可以说道破了编程的天机。以下原文的翻译（原文链接请点击文末“原文阅读”）：
KISS表示的是什么？
KISS 是Keep It Stupid Simple 或 Keep It Simple,Stupid的缩写。
KISS的含义
该原则在我的多年的软件工程生涯中取得关键、巨大的成功。当今的软件工程师和开发者们有个共同的问题，那就是他们总是慢慢地使得问题复杂化。正确的做法应该是当开发者遇到一个问题后，把问题拆分成一个个能够明白的小块，然后进入编码阶段。但我会说，10个开发者中有8个或9个都没有把问题分解成足够小或可以理解的足够小的部分。这就导致了即使是一个非常简单的问题最后也变成了非常复杂的实现，另外一个副作用就是意大利面代码，在BASIC里只是一个goto语句的事情，在Java中却需要500到1000行代码，每个方法都有几百行代码。
你需要先想好问题的解决步骤一共分为几步，然后再进入编码。而不是拿到需求后，就开始一边写代码一边去满足需求。这样做的好处就是你的代码会变的足够容易理解和足够清晰。
我们能从KISS中获取到什么好处？
你可以更好地解决更多问题。
你将可以通过很少的几行代码去解决复杂的问题。
你将可以产出高质量的代码。
你将可以构建更大更易维护的系统。
当新的需求来了后，你的代码将会更加的灵活，易于扩展、易于修改和重构。
你将完成比你想象得更多的事情。
你将能够工作在一个大型开发团队和大型项目中，因为所有的代码都是stupid simple。
我如何把KISS原则用到我的工作中？
这里有几个简单的步骤可供执行，但有一定挑战。就像说起来的那么简单，keep it simple，主要是需要耐心，更多的靠你自己。
要谦虚，不要认为自己是个天才，这是你第一个误解。只有谦虚了，你才能真正达到超级天才的水平，即使不行，who cares！你的代码那么stupid simple，所以你不需要是个天才！
将你的任务分解为4-12小时的子任务。
把你的问题拆分成多个小问题。每个问题用一个或者很少的几个类来解决掉。
保持你的方法足够小，每个方法永远不要超过30-40行代码。 每个方法都应该只处理一个小小的问题，不要搞太多uses case进去。如果你的方法中有多个分支，尝试把他们拆分成多个小的方法。这样不仅容易阅读和维护，找bug也更快。慢慢的你将学会爱。
让你的类也小点，原则和上面的方法是一样的。
先解决问题，然后开始编码。不要一边编码，一边解决问题。这样做也没什么错，但你有能力提前把事情切分成多个小的块，然后开始编码可能是比较好的。但也请你不要害怕一遍遍重构你的代码。另外行数还不是为了衡量质量的标准，只是有个基本的尺子而已。
不要害怕干掉代码。重构和重做是两个非常重要的方面。如果你遵循上面的建议，重写代码的数量将会最小化，如果你不遵循，那么代码很可能会被重写。
其他的任何场景，都请你尝试尽可能的简单，simple，这也是最难的一步，但一旦你拥有了它，你再回头看，就会说，之前的事情就是一坨屎。
有没有一些KISS原则的例子
太多了，以后我会把一些不错的案例po到这里。但现在我想先给你一些我的观点和想法：
世界上的很多伟大的算法几乎总是有很少的数行代码。当我们去看这些的时候，会发现很容易理解。这些算法发明者，他们把问题拆分，直到容易理解的程度，然后去实现它。
Many great problem solvers were not great coders, but yet they produced great code!
许多伟大的问题解决者（problem solver）都曾不是伟大的程序员，但他们却产出了伟大的代码！
KISS只能用于java代码？
显然不是，它可以用于很多编程语言，并且甚至可用于你生活的其他的领域。当然不能用于你的感情、爱，更重要的是，不能用在你的婚姻上。
The Kiss Principle
原文来源：https://people.apache.org/~fhanik/kiss.html
What does KISS stand for?
The KISS is an abbreviation of Keep It Stupid Simple or Keep It Simple, Stupid
What does that mean?
This principle has been a key, and a huge success in my years of software engineering. A common problem among software engineers and developers today is that they tend to over complicate problems.
Typically when a developer is faced with a problem, they break it down into
smaller pieces that they think they understand and then try to implement the solution in code.
I would say 8 or 9 out of 10 developers make the mistake that they don't break down the problem into small enough
or understandable enough pieces. This results in very complex implementations of even the most simple problems,
another side effect is spagetthi code, something we tought only BASIC would do with its goto statements,
but in Java this results in classes with 500-1000 lines of code, methods that each have several hundreds of lines.
This code clutter is a result of the developer realizing exception cases to his original solution while he is typing in code.
These exception cases would have solved if the developer had broken down the problem further.
How will I benefit from KISS
- You will be able to solve more problems, faster.
- You will be able to produce code to solve complex problems in fewer lines of code
- You will be able to produce higher quality code
- You will be able to build larger systems, easier to maintain
- You're code base will be more flexible, easier to extend, modify or refactor when new requirements arrive
- You will be able to achieve more than you ever imagined
- You will be able to work in large development groups and large projects since all the code is stupid simple
How can I apply the KISS principle to my work
There are several steps to take, very simple, but could be challenging for some. As easy as it sounds, keeping it simple, is a matter of patience, mostly with yourself.
- Be Humble, don't think of yourself as a super genius, this is your first mistake
By being humble, you will eventually achieve super genius status =), and even if you don't, who cares! your code is stupid simple, so you don't have to be a genius to work with it. - Break down your tasks into sub tasks that you think should take no longer than 4-12 hours to code
- Break down your problems into many small problems. Each problem should be able to be solved within one or a very few classes
-
Keep your methods small, each method should never be more than 30-40 lines.
Each method should only solve one little problem, not many uses cases
If you have a lot of conditions in your method, break these out into smaller methods.
Not only will this be easier to read and maintain, but you will find bugs a lot faster.
You will learn to loveRight Click+Refactorin your editor. - Keep your classes small, same methodology applies here as we described for methods.
-
Solve the problem, then code it. Not the other way around
Many developers solve their problem while they are coding, and there is nothing wrong doing that. As a matter of fact, you can do that and still adhere to the above statement.
If you have the ability to mentally break down things into very small pieces, then by all means, do that while you are coding. But don't be afraid of refactor your code over and over and over and over again. Its the end result that counts, and number of lines is not a measurement, unless you measure that fewer is better of course. -
Don't be afraid to throw away code. Refactoring and recoding are two very important areas.
As you come across requirements that didn't exist, or you weren't aware of when you wrote the code to begin with
you might be able to solve the old and the new problems with an even better solution.
If you had followed the advice above, the amount of code to rewrite would have been minimal, and if you hadn't followed the advice above, then the code should probably be rewritten anyway. - And for all other scenarios, try to keep it as simple as possible, this is the hardest behavior pattern to apply to, but once you have it, you'll look back and will say, I can't imagine how I was doing work before.
Are there any examples of the KISS principle
There are many, and I will look for some really great one to post here. But I will leave you with the following thought:
Some of the world's greatest algorithms are always the ones with the fewest lines of code.
And when we go through the lines of code, we can easily understand them.
The innovator of that algorithm, broke down the problem until it
was so easy to understand that he/she could implement it.
Many great problem solvers were not great coders, but yet they produced great code!
Does KISS only apply to java coding
Absolutely not, it applies to many other programming languages and extends to many other areas in your life.
The areas that the principle doesn't apply to are: emotions, love and most importantly, your marriage :)