KISS

KISS

Share it!Share on FacebookTweet about this on TwitterGoogle+Share on LinkedInEmail to someone
I always thought that in order of being a good programmer when developing the work, some principles must be followed. Principles that at the end of the process make the difference between an application well programmed and a wrong one. In this article I am going to talk about one of them, my favourite: The Kiss principle …

I always thought that in order of being a good programmer when developing the work, some principles must be followed. Principles that at the end of the process make the difference between an application well programmed and a wrong one. In this article I am going to talk about one of them, my favourite: The Kiss principle.
KISS

KISS is the acronym for “Keep it simple, stupid!”

A very common problem among software engineers and developers is that we tend to over complicate problems when we search for solutions. The large majority of developers make the mistake of not breaking down problems into subproblems. This involves obtaining pieces of code very complex, and leads us to make some exceptional cases while we write the program code. If the problem is broken down into smaller problems, these cases are solved. The benefits of applying this principle

  • To solve more problems, faster.
  • To solve problems in fewer lines of code.
  • To produce higher quality code.
  • To build larger systems, easier to maintain
  • To get a software more flexible when extending or refactoring.

How can I apply this principle to my work As easy as it sounds, keeping it simple. There are several considerations to take into account:

  • Don’t think of yourself as a super genius. This is the first mistake By being humble, you will achieve super genius status. And even if you don’t succeed, the code is simple, so you don’t have to be a genius to work with it.
  • Break down tasks into subtasks. They should be solved within one or very few classes that take no longer than 4-12 hours to code.
  • Keep methods small. Each method should never be more than 10-20 lines, and should only solve one problem. This makes it more readable and maintainable, and bugs will be found faster.
  • Keep your classes small.
  • Solve the problems, and then code it. Not the other way around.
  • Don’t be afraid to throw away the code. Refactoring and recoding is very important. When you come across new requirements you might be able to solve the old and the new problems with an even better solution.

Although seemingly paradoxical, this is the hardest principle to apply to, but once you have it, you look back and say: “how I was doing work before?” Conclusion The greatest algorithms in the world are often the ones with the fewest lines of code. And when we go through it, they are easily understandable. The creators broke down the problem until it was so easy that it could implement it. In addition, there are other principles very interesting, such as YAGNI (“You Aren’t Gonna Need It”), DRY (“Don’t repeat yourself”), Navaja de Occam (“On an equal basis, the easier explanation is often the correct one”)… All of them share the same goal: the maintainable, scalable and readable software development. And EASY TO UNDERSTAND BY THEIR HEIRS to understand each other.

Note: “the good, if brief, is twice as good. And the bad, if little, no so bad. ”

 

 


 

Use of cookies

This site uses cookies for you to have the best user experience. By continuing to browse this website you accept their use and agree to our cookies policy. Learn more about our cookies, following this link

ACEPTAR