编程思维:KISS原则

KISS原则

• 什么是KISS原则，为什么要遵守KISS原则
• 最简单的好处就是遵循这个原则能够使你的代码足够简洁，逻辑清晰。

原文如下：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 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 😃

简单翻译如下

KISS法则代表什么？

KISS法则是Keep It Stupid Simple或Keep It Simple，stupid的缩写

那是什么意思？

在我多年的软件工程生涯中，这个原则是一个关键，也是一个巨大的成功。当今软件工程师和开发人员的一个常见问题是，他们往往将问题过于复杂化。

通常，当开发人员面对一个问题时，他们会将问题分解成他们认为自己理解的小部分，然后尝试用代码实现解决方案。我认为10个开发人员中有8到9个会犯这样的错误：他们没有将问题分解成足够小或足够容易理解的部分。这会导致即使是最简单的问题也会导致非常复杂的实现，另一个副作用是spagetthi code，我们认为只有BASIC才可以用它的goto语句来实现，但是在Java中，这会导致类包含500-1000行代码，每个方法都有几百行代码。

这种代码混乱是由于开发人员在输入代码时发现了原始解决方案的异常情况。如果开发人员进一步分解问题，这些异常情况就会得到解决。

KISS法则对我们有什么好处

你将能够更快地解决更多的问题。

您将能够用更少的代码行生成解决复杂问题的代码

你将能够产生更高质量的代码

你将能够建立更大的系统，更容易维护

当新的需求到来时，你的代码库将更加灵活，更容易扩展、修改或重构

你将能够取得比你想象中更多的成就

你将能够在大型开发小组和大型项目中工作，因为所有的代码都是愚蠢的简单

我怎样才能把接吻原则应用到我的工作中呢

有几个步骤要做，非常简单，但可能对一些人来说是挑战。听起来很简单，保持简单就是一个耐心的问题，主要是对你自己。

谦虚一点，别把自己当成超级天才，这是你的第一个错误

谦虚，你最终会进入一个超级天才的状态，即使你不谦虚，那又有什么关系呢！你的代码是如此简单，所以你没必要成为天才才能看懂并且使用。

把你的任务分解成你认为不超过4-12小时的子任务

把你的问题分解成许多小问题。每一个问题都应该能够在一个或几个类中解决

保持你的方法小，每个方法永远不要超过30-40行。每种方法只解决一个小问题，而不是多个用例

如果你的方法中有很多条件，把它们分解成更小的方法。

这不仅更易于阅读和维护，而且您会更快地发现bug。

你将学会喜欢在编辑器中使用右键单击+重构。

保持你的类很小，这里应用的方法和我们描述的方法相同。

解决问题，然后编码。不是相反

许多开发人员在编写代码时解决了他们的问题，这样做没有错。事实上，你可以做到这一点，但仍然坚持上述说法。

如果你有能力在精神上把事情分解成很小的部分，那么无论如何，在你编写代码的时候也要这么做。但是不要害怕一次又一次地重构代码。它的最终结果是有价值的，线的数量不是一个测量，除非你测量的更少当然是更好的。

不要害怕扔掉代码。重构和重新编码是两个非常重要的领域。当您遇到不存在的需求时，或者您不知道什么时候开始编写代码时，您可能能够用更好的解决方案来解决新旧问题。

如果您遵循了上面的建议，那么要重写的代码量将是最小的，如果您没有遵循上面的建议，那么代码可能无论如何都应该重写。

对于所有其他场景，尽量保持简单，这是最难应用的行为模式，但是一旦你有了它，你会回头说，我无法想象我以前是怎么工作的。

• 有没有KISS原则的例子：

  有很多，我会寻找一些真正伟大的张贴在这里。但我会带着以下内容离开：

​ 世界上一些最伟大的算法总是使用最少的代码行。当我们浏览代码行时，我们可以很容易地理解它们。那个算法的创新者，把这个问题分解了，直到它很容易理解，他/她可以实现它。

许多伟大的问题解决者并不是伟大的程序员，但他们却产生了伟大的代码！

• KISS只适用于java编码吗？

  绝对不是，它适用于许多其他编程语言，并扩展到您生活中的许多其他领域。

  这个原则不适用的领域是：情感，爱情，最重要的是你的婚姻：）