KISS代表什么?

KISS是 Keep It Stupid Simple or Keep It Simple, Stupid 的缩写。

它有什么含义?

这个原则是我在多年软件工程中取得巨大成功的一个关键。今天的软件工程师和开发人员之间最普遍的一个问题是：他们更倾向于解决复杂的问题。

通常情况下，当一个开发者遇到一个问题，他们将问题分成更小的部分，他们认为自己理解并尝试在代码中实现解决方法。我想说的是十之八九的开发者会犯的错误：他们不能将问题分解的足够小，或者完全理解每个碎片。这将导致即使是一个极其简单的问题也会有非常复杂的实现，另一个副作用是spagetthi code(😂代码浓密)，一些我们认为只要基本的goto语句实现，但同样的结果在java类中需要500-1000行代码，每个方法都有几百行。

代码混乱的结果导致当开发者写代码的时候意识到他们原始解决方法的例外情况。如果开发者继续分解问题，这些例外情况将会被解决。

我如何从KISS中获益？

• 你能更快的解决更多问题。

• 你能够写出用几行代码解决复杂的问题的代码。

• 你能够生产高质量的代码。

• 你能够构建出容易维护的大型系统。

• 当有新的需求时，你的代码库将会非常灵活，易于扩展、修改和重构。

• 你可以达到超出你想象的目的。

• 既然所有的代码都如此愚蠢而又简单，那么你岂不是可以在大型团队和大型项目中工作。

我如何将KISS原则用到工作中

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.

有几个步骤，很简单，但对一些人来说是个挑战。像听起来那么容易，保持它的简单，准要对自己来说是一种耐心。

• 保持谦逊，不要认为自己是超级天才，这是你的第一个错误。通过谦卑，你最终会达到超级天才的状态，尽管你不能做到，谁关心啊！你的代码愚蠢又简单，所以你不必成为一个天才。

• 将你的任务分解成你认为编码不超过4-12小时的子任务。

• 将你的问题分解成很多的小问题。每个问题只用一个或非常少的类就能解决。

• 让你的方法小起来，每个方法不应该超过30-40行。每个方法只应该解决一个小问题而不是很多用例。
  如果你的方法中有很多条件，将它们分解到更小的方法中。
  不仅要让代码好读，易维护，更应该让找起bug来更快。
  你要学着爱上编辑器中的” 右键＋重构”

• 让你的类小起来，将同类方法放在一块。

• 先解决问题，然后再编码。而不是像许多开发者一样边编码边解决问题，这样并没有错。事实上，你也可以这么做但是保证以上声明。
  如果你有在心里将问题分成极小块的能力，你可以在编码的同时通过各种方法这样做。但是不要害怕一遍一遍又一遍一遍的重构你的代码。最终的结果才是最重要的，不能用行数测量，除非你衡量代码坚持越少越好的原则。

• 不要害怕丢弃代码。重构和重新编码是很重要的两个方面。当你接到一个新的需求，或者当你开始写代码时，你并没有意识到你也许可以用一个更好的方法解决旧的/新的问题。
  如果你遵循了以上建议，那么需要重写的代码量就会极小极小，但是如果你不遵循以上建议，那代码如论如何都得被重写。

• 其他情况下，保持代码尽可能的简单，这是最难应用的行为模式，可一旦你拥有了它，当某天，你回首往事的时候，你会说：I cant imagine how i was doing work before.

KISS原则的例子

简直不要太多，这里我将寻找真正的强者中的一个贴出来。给你个思考：

世界上一些伟大的算法只有极少的行。我们很容易就理解了那几行。算法的创新者，将问题分解到很容易理解的之后，然后去实现它。

很多伟大的问题解决的不是伟大的编码者，但却生产出了伟大的代码！😂

---

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 love Right Click+Refactor in 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 :)

---

原文地址

幼儿园水平翻译，慢慢来哈哈，哈，哈，哈，哈花轮同学~~~