Mostrando entradas con la etiqueta metodología. Mostrar todas las entradas
Mostrando entradas con la etiqueta metodología. Mostrar todas las entradas

Principio K.I.S.S. ( parte II )

0 comentarios
Habiendo desarrollado en la última entrada de este blog el concepto del principio K.I.S.S. y sus beneficios, veremos a continuación la segunda y última entrega de este principio.


Cómo aplicarlo al trabajo diario
Son muchos pasos los que se deben llevar a cabo, muy simples, pero pueden resultar un reto para algunos.
Tan fácil como suena, mantenerlo simple, es sólo cuestión de paciencia. Sobretodo, con uno mismo.
A continuación, veremos los puntos a tener en cuenta para llevarlo a cabo:

  • Ser humilde. No pensar en uno mismo como un super genio. Este es el primer error. Siendo humilde, es muy posible alcanzar el estatus de super genio. Pero, aunque así no se lograse, a quién le importa?! El código es simple y estúpido, por lo que no hay que ser un genio para trabajar con él.
  • Dividir las tareas en subtareas que, en principio, no deben llevar más de 4-12 horas de codificación.
  • Dividir los problemas en pequeños problemas. Cada problema se debe poder resolver dentro de una o muy pocas clases.
  • 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 (y sólo un) problema. Si contiene muchas condiciones, hay que dividirlo en métodos más pequeños. (Esto no sólo los hace más legibles y mantenibles, sino que además, encontrar errores es mucho más rápido.
  • Mantener las clases pequeñas. Aplicar la misma metodología que con los métodos.

Principio K.I.S.S. ( parte I )

0 comentarios
K.I.S.S. es la abreviatura de Keep It Simple, Stupid (mantenlo simple, estúpido).
Un problema común entre los ingenieros y desarrolladores de software hoy en día, es que tendemos a complicar más los problemas.
Normalmente, cuando nos enfrentamos a un problema, dividimos en trozos más pequeños que pensamos que entendemos y luego tratamos de implementar la solución en el código. Yo diría que 8 o 9 de cada 10 desarrolladores cometemos el error de no descomponer el problema en trozos suficientemente pequeños o suficientementes comprensibles. Esto se traduce en implementaciones muy complejas de los problemas más simples.
Otro efecto secundario es el llamado: código spagetthi. Algo que creíamos que sólo en BASIC podía hacerse con sus sentencias GOTO. Pero no, en lenguajes modernos como C# o Java, se traduce en clases de 500-1000 líneas de código (decenas de métodos con decenas de líneas).
Este desorden de código es el resultado de la realización de casos de excepción, por parte nuestra, a la solución original mientras que se está escribiendo el código.
Dichos casos se hubieran resuelto si hubiéramos descompuesto aún más el problema.

Beneficios 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.
  • Lograr un framework propio más flexible y más fácil de ampliar, modificar o refactorizar cuando lleguen nuevos requerimientos.
  • Se podrá trabajar en grandes equipos de desarrollo y grandes proyectos ya que el código será simple y estúpido.
Fuente: The Kiss principle (Grupo Apache)
 
Copyright 2009 Programación SOLIDa
BloggerTheme by BloggerThemes | Design by 9thsphere