lunes, 10 de abril de 2017

Clean Code Capítulo 5 Formato

Este capítulo se resumen en la necesidad que debemos tener de preocuparnos por el formato de nuestro código. Por lo anterior y si se trabaja en equipo el autor expresa que se “debe acordar una serie de reglas que todos los miembros deben cumplir”.

 Como la comunicación debe ser el pilar de un desarrollador profesional, el formato son esas reglas que utilizamos al escribir nuestro código, permitiendo comunicarnos mejor. El libro Clean Code nos menciona una serie de formatos o reglas a seguir.

 Formato Vertical: se refiere al tamaño o número de líneas que debe tener un archivo fuente, esto lo quiero resumir diciendo que no hay un tamaño vertical máximo, pero que un archivo pequeño es más fácil de entender que uno muy extenso, en este punto quiero mencionar la metáfora del periódico descrita en el libro:

 “Piense en un artículo de periódico bien escrito. En la parte superior espera un titular que indique de què se trata la historia y le permita determinar si quiere leerlo o no. El primer párrafo ofrece una sinopsis de la historia, oculta los detalles y muestra conceptos generales. Al avanzar la lectura, aumenta los detalles junto con toda las fechas, nombres, citas y otros elementos.

 Un archivo de código debe ser como un artículo de periódico. El nombre debe ser sencillo pero claro. Por sí mismo, debe bastar para indicarnos si estamos o no en el módulo correcto. Los elementos superiores del archivo deben proporcionar conceptos y algoritmos de nivel superior. Los detalles deben aumentar según avanzamos, hasta que en la parte final encontremos las funciones de nivel inferior del archivo.

 Un periódico se compone de varios artículos, algunos muy reducidos y otros de gran tamaño. No hay muchos que ocupen toda la página con texto, para que el periódico sea manejable. Si el periódico fuera un único y extenso texto con una aglomeración desorganizada de hechos, fechas y nombres, no lo leerìamos.”

 Apertura Vertical entre Conceptos: Por lo general colocamos una línea tras otra, las cuales  representan un concepto, estos conceptos se deben separar mediante líneas en blanco.

 package cedaniel200.com.ejemplo;

public class Ejemplo {

        private static final String AUTOR = “cedaniel200”;
        private String mensaje;

         public void setMensaje(String mensaje){
                 this.mensaje = mensaje;
        }

        public void imprimirMensaje(){
                System.out.println(AUTOR + ”: ” + this.mensaje);
        }

 }

 Distancia Vertical: Lo conceptos relacionados deben estar juntos verticalmente, es decir, uno seguido del otro.

 Declaración de Variables: Se aconseja declararlas cerca a su uso, así, las variables locales se debe declara al comienzo de cada método, las variables de control de bucles se deben declarar dentro de este, como hay excepciones, por ejemplo cuando la declaración es muy larga, esta se debe hacer en la parte superior de un bloque o antes del bucle.

Variables de Instancia: Deben declararse en la parte superior de cada clase.

 Funciones Dependientes: Si una función llama a otra estas deben estar lo más cerca posible, es decir, la función que invoca debe ir primero seguida de la función invocada.

 Afinidad Conceptual: Este punto se refiere a ubicar lo más próximo posible los conceptos similares, por ejemplo, existe una clase que tiene varias funciones que no se invocan entre sí, pero varias funciones realizan operaciones similares, estas deben estar próximas la una de la otra, es decir, una seguida de la otra.

 Formato Horizontal: trata de la cantidad de caracteres que debe tener una línea, el autor recomienda 120 caracteres como límite. Lo que sí es cierto es que tener que utilizar el scroll horizontal para ver toda la línea es algo molesto y que dificulta la legibilidad, entonces mi recomendación es que el tamaño de la línea no exceda al de la pantalla ocasionando la necesidad de utilizar es scroll horizontal.

 Apertura y Densidad Horizontal: Trata de la utilización de los espacios en blanco horizontales para destacar las partes que componen una línea, por ejemplo en una asignación se utiliza para acentuar la separación de sus dos partes:
 int numeroMaximoAlumnos  =  12;

 también se utiliza para separar argumentos en un método:

public void imprimirMensaje(String autor,  String mensaje){
        // implementación del método

 Separar los argumentos al invocar un método:

 imprimirMensaje(“cedaniel200”, “Hola Mundo”);

 También se utilizan los espacios para acentuar precedencia de los operadores:

  int resultado = c*c - 5*c + 3*c*b;

 Sangrado: Se debe sangrar cada línea dependiendo de su nivel, un sangrado por cada nivel desde el segundo, por ejemplo:

public class Persona { // Primer nivel por lo tanto no se sangra

        private String nombre; // Segundo nivel por eso tiene un sangrado
        public void setNombre(String nombre){
                this.nombre = nombre; // Tercer nivel por eso tiene dos sangrados
        } 
}

Nota: Para más artículos relacionados ver Clean Code.

martes, 24 de enero de 2017

Principio de Responsabilidad Única


Este principio es clave en la programación orientada a objetos, y nos dice que cada clase debe tener un solo motivo para cambiar, entendiendo como motivo la responsabilidad que tiene la clase, en otras palabras, para qué fue hecha o qué hace en específico. También se le puede llamar cohesión, entendiendo cohesión como la medida en que un componente (clase, paquete, método) se dedica a realizar solo la tarea para la cual fue creado.

¿Por qué es necesario aplicar este principio? Bueno, partamos de que tenemos una clase A que tiene dos responsabilidades, es decir, hace dos cosas; de ahora en adelante las llamaremos R1 y R2. En el cuerpo de la clase, esta tiene varios métodos, donde algunos de estos se utilizan tanto para llevar a cabo R1 como para R2. Al momento de la creación de la clase no hay ningún problema y todo funciona bien.

Un mes después ...

Es hora de mantener nuestra aplicación, debemos cambiar una clase. Espero hayas adivinado qué clase es, ¡sí, es la clase A!, resulta que R1 no está del todo bien y se debe corregir, entonces, empieza nuestra labor.

Tres días después, 500 tazas de café y pocas horas de sueño después ...

Creemos que hemos terminado y cuando se empiezan a realizar las pruebas... OOOOOH sorpresa, tú o el equipo de testing (o como se le llame en tu empresa) se dan cuenta que ahora R1 funciona bien, pero R2 no funciona. ¿Qué pasó?, recordemos algo: “Algunos de los métodos de la clase A se utilizan por R1 y R2”, entonces al modificar alguno de estos métodos, se corrige R1 pero genera errores en R2.

Es por lo anterior que se debería cumplir este principio, así cuando se haga un cambio tendremos la certeza que solo se afectará una responsabilidad. Otra justificación se hace evidente cuando ocurre un error y se detecta qué es, es fácil identificar la clase que tiene esa responsabilidad.

Si deseas ampliar más este tema te recomiendo el artículo The Single Responsibility Principle de Robert C. Martin.

Si deseas leer sobre los demás principios SOLID da click aquí.

miércoles, 18 de enero de 2017

Qué Método de Estimación Utilizar para mi Sprint?


Este artículo surge de un comentario que hice al artículo Planear sprints en horas y no por puntos de Lucho Salazar.

Estimar, según la RAE es “Calcular o determinar el valor de algo” o “Creer o considerar algo a partir de los datos que se tienen”, y como todos, en nuestra poca o mucha experiencia, sabemos que estimar no es algo trivial y aún más cuando estamos empezando en este mundo; ahora, con el paso del tiempo mezclamos las dos definiciones, ya que, calculamos con base en datos obtenidos con el paso de cada sprint; o al menos ese es el deseo, o, a mi consideración, lo que se debería hacer.

¿Qué método de estimación utilizar para planear mi sprint?, es la pregunta que muy seguramente nos surge cuando vamos a empezar, y según a quién se la formules te dará una respuesta con la cual, probablemente, muchos coinciden, debido a que unos métodos son más populares que otros.

Para responder esta pregunta, yo diría que todo método de estimación puede llegar a ser válido para un equipo, siempre y cuando este adquiera la madurez y la destreza en su utilización. Esto se consigue inicialmente a prueba y error, pasando por el punto en que se aprecia el avance en la utilización del método escogido, hasta conseguir dominarlo; en caso de no conseguir ningún avance es mejor cambiar y experimentar con otro método.

Para justificar mi postura, partamos de un método cualquiera (sea por horas, por puntos o puntos que equivalen tiempo o esfuerzo, u otro que hayas escuchado) y mi consejo es que te documentes muy bien al respecto antes de empezar. Comenzamos planificando los primeros sprint, los cual tenderán a errores (sobre o bajo la línea del Burndown) debido a la incertidumbre que conlleva iniciar con algo que, aunque esté documentado, se desconoce su comportamiento en la práctica; es con el tiempo (sprint tras sprint) en que este margen de error baja a su mínima expresión. Hay que tener en cuenta que se pueden obtener estadísticas como la velocidad promedio y las que creamos necesarias, con las cuales se puede predecir la estimación con base en datos y cada vez ser más acertados al planear el sprint.

Por lo anterior, estoy de acuerdo con Lucho cuando en su artículo expresa que "igual que con los puntos, estimar con horas no nos eximirá del error inherente a las estimaciones", para acuñar esta frase a este artículo he realizado unos pequeños cambios, quedando de la siguiente forma:

"estimar, independientemente del método utilizado, no nos eximirá del error inherente a las estimaciones"

Independientemente del método, la experiencia en su utilización te ayudará a obtener buenos resultados. Experimentar es fundamental para esto, puede que un método de estimación te dé mejores resultados que otro, y por lo tanto, sea el momento de realizar un cambio, ya sea de puntos a horas o de horas a puntos, o quizás algún método distinto a los aquí mencionados.

Instalación NodeJS

Ingresamos a la página oficial de NodeJS donde lo descargaremos  https://nodejs.org/en/download/ Escogemos el instalador que se ajuste a ...