KISS

KISS

¡Compártelo!Share on FacebookTweet about this on TwitterGoogle+Share on LinkedInEmail to someone
Siempre he pensado que para ser un buen programador, en el momento de desarrollar el trabajo, se deben de seguir unos principios. Unos principios que, al final del proceso, crean la diferencia entre una aplicación bien programada y una aplicación mal programada. En este artículo, voy a hablar de uno de ellos, mi favorito: el principio KISS …

 

Siempre he pensado que para ser un buen programador, en el momento de desarrollar el trabajo, se deben de seguir unos principios. Unos principios que, al final del proceso, crean la diferencia entre una aplicación bien programada y una aplicación mal programada. En este artículo, voy a hablar de uno de ellos, mi favorito: “el principio KISS“.

KISS

KISS es la abreviatura de Keep It Simple, Stupid!

Un problema muy común entre los ingenieros y desarrolladores de software, es que tendemos a hacer más grandes los problemas cuando estamos buscando una solución a ellos.

La gran mayoría de los desarrolladores cometemos el error de no descomponer el problema en subproblemas, lo cual, se traduce en trozos de código muy complejos y, que nos llevan a la realización de casos de excepción, mientras que se está escribiendo el código.

Si el problema se descompone en varios problemas más pequeños, estos casos se resuelven. Ventajas de aplicar este principio

  • Resolver más problemas, más rápido.
  • Resolver problemas en pocas líneas de código.
  • Producir código de mejor calidad.
  • Construir sistemas muy grandes, fáciles de mantener.
  • Conseguir un software más flexible a la hora de ampliar o refactorizar.

Cómo aplicarlo al trabajo diario Tan fácil como su propio nombre indica, mantenerlo simple. A continuación, veremos algunos puntos a tener en cuenta para llevarlo a cabo:

  • No pensar que soy un genio. Este es el primer error. Siendo humilde, es muy posible alcanzar el estatus de súper genio. Pero, aunque así no se lograse, el código es simple, por lo que no hay que ser un genio para trabajar con él.
  • Dividir las tareas en subtareas que se puedan resolver dentro de una o muy pocas clases no lleven más de 4-12 horas de codificación.
  • Mantener los métodos pequeños. Cada método no debe tener nunca más de 10-20 líneas y sólo debe resolver un problema. Esto los hace más legibles, más mantenibles y los errores se encontrarán mucho más rápido.
  • Mantener las clases pequeñas.
  • Resolver los problemas y después codificarlos, no al revés.
  • No temer a desechar lo codificado. Refactorizar y recodificar, es muy importante. Cuando llegan nuevos requerimientos, se debe poder resolver los anteriores y los nuevos problemas con una solución aún mejor.

Aunque resulte paradójico, este principio es el más difícil de aplicar, pero una vez que se logra, cuando miramos hacia atrás, decimos: “Como podía trabajar antes?!”. Conclusión Los mejores algoritmos del mundo, suelen ser los que tienen el menor número de líneas de código y, al analizarlas, son fácilmente entendibles. Sus creadores, dividieron el problema hasta que fue tan fácil, que pudo implementarse. A parte de este principio hay otros muy interesantes como el YAGNI (“You Aren’t Gonna Need It”), DRY (“Don´t repeat yourself”), Navaja de Occam (“en igualdad de condiciones, la explicación más sencilla suele ser la correcta”)… Todos ellos tienen como objetivo, el desarrollo de software mantenible, escalable, legible y sobre todo y para entendernos… FÁCIL DE ENTENDER POR SUS HEREDEROS.

Nota: “Lo bueno, si breve, dos veces bueno. Y aun lo malo, si poco, no tan malo”

 


 

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies. Más información sobre nuestras cookies, siga este enlace

ACCEPT