lunes, 28 de noviembre de 2016

Clean Code Capítulo 2 Nombres con Sentido (2/2)



Continuando con la segunda parte del capítulo 2, vamos a seguir viendo aquellas reglas para crear nombres correctos. Si aún no has visto la primera parte te invito para que la veas.

Nombres de clases: Los nombre de clases no deben ser verbos. Los nombres deben proporcionar de manera clara el propósito de la clase, por lo general debe ser un sustantivo, evitando nombres genéricos. Algunos ejemplos de nombres correctos serían: Persona, Direccion, Cliente. Algunos nombres incorrectos de clases podrían ser: Info, Procesador, CalcularNomina.

Nombre de métodos: Debe ser un verbo como por ejemplo, eliminar, agregar, guardar. Los métodos de acceso, modificación deben tener como nombre su valor y usar como prefijo get, set e is. Como recomendación el autor dice, que “Al sobrecargar constructores use métodos de factoría estáticos con nombres que describan los argumentos

No se exceda con el atractivo: Esta regla hace referencia a no utilizar nombres provenientes de formas coloquiales de decir las cosas o de jergas, dejando a un lado la claridad, ya que, si llega un nuevo programador que no conozca estas formas de decir las cosas, se llenará de desinformación. 

Un nombre por concepto: Es simple, cuando nos decidimos por una palabra para representar un concepto, esta debe ser constante por todo el código y no utilizarse en unos lados y en otros no. Por ejemplo, no es conveniente utilizar en algunos nombres de métodos la palabra get y en otros retrieve. 

No haga juego de palabras: Se refiere a no utilizar una palabra con dos fines distintos, por ejemplo, digamos que en nuestro código hemos venido utilizando la palabra remove para nombrar métodos que inactivan, y en algún momento somos tentados a utilizar remove para hacer referencia a un método que elimina, en este caso sería mejor utilizar el nombre delete para el método en cuestión.

Usar nombres de dominio de soluciones: No es necesario que todos los nombres utilizados sean extraídos del dominio del problema, ya que, los lectores del código son programadores y ellos conocen o están familiarizados con términos informáticos, de patrones, y demás. Por ejemplo para un programador va a tener mucho sentido si una clase tiene el nombre de ListAdapter.

Usar nombre de dominios de problema: Cuando no se pueda cumplir la regla anterior porque no existe un término en el ámbito de programación, se debe recurrir a un nombre del dominio del problema. El autor nos dice “Separar los conceptos de dominio de soluciones y de problemas es parte del trabajo de un buen programador y diseñador”.

Añadir contexto con sentido: Cuando los nombres no tiene sentido por sí mismo, es necesario crearle un contexto que enriquezca dicho nombre, esto puede hacerse convirtiendo variables en parte de un concepto mayor, es decir, extraer una clase de la cual hagan parte o en una función o método que aporte un contexto. Como última instancia usar prefijos.

No añadir contextos innecesarios: Se refiere a no agregar en los nombres más información de la necesaria. Imagine una clase llamada DireccionResidencia y otra DireccionTrabajo, estos nombres no son realmente adecuados para una clase, lo mejor sería una clase Direccion y estos nombres serían ideales para nombre de instancias. Otro caso es agregar prefijo al nombre de las clases.


Como hemos visto en estos dos post acerca de nombres con sentido, el elegir un nombre adecuado para cada parte del código es fundamental, tanto para la legibilidad como para entender qué se hizo o qué se va a hacer. Para dar un nombre adecuado es necesario emplear habilidad descriptiva, gran vocabulario, conocimiento técnico y dejar los miedos, es momento de empezar a buscar mejores nombres, agregar o quitar el exceso de contexto, refactorizar el código, cambiando los nombres que no sean adecuados en el código existente.

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

viernes, 25 de noviembre de 2016

Clean Code Capítulo 2 Nombres con Sentido 1/2


A medida que escribimos código es inevitable enfrentarnos a la tarea que aunque parece trivial no lo es, de asignar nombre a una variable, clase, paquete, archivo etc. Cuando digo que no es trivial, quiero hacer énfasis a su importancia y a que al poner un nombre se debe hacer con responsabilidad y profesionalismo (lógica, coherencia y mucho sentido), puesto que estos nombres empezarán a dotar de sentido al código mismo, y de eso nos daremos cuenta al momento que otros programados lo lean o hasta nosotros mismos cuando con el tiempo debamos realizar mantenimiento sobre este. El autor de Clean Code sabe esto, por tal motivo nos proporciona una serie de reglas básicas para crear nombres correctos.

Usar nombre que revelen las intenciones: Cuántas veces hemos encontrado una variable con nombre así: int a; ¿Esto te dice algo?, ¿Sabes para qué sirve la variable a o que significado tiene?, precisamente de eso se trata esta regla, dotar de significado y sentido a través de su nombre, por ello el autor nos dice “El nombre de una variable, función o clase debe responder una serie de cuestiones básicas. Debe indicar por qué existe, qué hace, y cómo se usa”. Veamos un ejemplo tomado de Clean Code.

Incorrecto
public List<int[]> getThem(){
List<int[]> list1 = new ArrayList<int[]>();
for(int[] x : theList)
if(x[0] == 4)
  list1.add(x);
return list1;
}

Correcto
public List<int[]> getFlaggedCells(){
List<int[]> flaggedCells = new ArrayList<int[]>();
for(int[] cell : gameBoard)
if(cell[STATUS_VALUE] == FLAGGED)
  flaggedCells.add(cell);
return flaggedCells;
}

Evitar la desinformación: En ocasiones damos nombre ambiguos o que pueden más que informar, desinformar, ya que, da pistas erróneas de lo que en realidad hace una función, variable o clase. En otras oportunidades tenemos variables casi con el mismo nombre donde solo las diferencia una pocas letras o una pequeña palabra, es decir, nombre con variaciones mínimas. Estos casos nos dificultan la lectura del código, razón por la que debemos mejorar en dicho aspecto. Veamos unos ejemplos.

Incorrecto
Correcto
Explicación
tmp
temperatura
Algunos pensaran que tmp, hace referencia a temporal o tiempo
lugarXCoordenadas
lugarYCoordenadas
coordenadasOrigen
corrdenadasDestino
los nombres tienen forma similar
o
-
Nombrar una variable como o puede hacer que se confunda con el cero, al igual que no brinda ninguna información

Realizar distinciones con sentido: Esta regla va de la mano con la anterior cuando se habla de no tener nombre con variaciones mínimas, debido a que esta regla propone que a dichos nombres se le agregue aparte de una notable variación, sentido, como lo dice el autor “Si los nombres tienen que ser distintos, también deben tener un significado diferente”. Imaginemos que tenemos en una función que recibe dos variables num1, num2, lo primero que notamos es que en sus nombres no tienen una gran diferencia y segundo no da mucha información, ahora, si esta función lo que hace es dividir el primer parámetro (num1) con respecto al segundo (num2), tendría mas sentido llamarlos dividendo y divisor respectivamente.

Usar nombres que se puedan pronunciar: Cuántas veces haciendo mantenimiento al código tienes que dirigirte a un colega para alguna explicación o aclaración, cómo le dirías, o mejor, cómo pronunciarías la variable llamada genymdhms (fecha de generación, año, mes, día, hora, minuto y segundo), ¿no crees que es mejor generationTimestamp? - Ejemplo tomado del libro Clean Code -. Quizás tu colega no te entienda o tenga que ver con sus propios ojos de que le estás hablando, de ahí la importancia de colocar nombres que puedas pronunciar; la programación es una actividad social.

Usar Nombres que se puedan buscar: Aunque es una regla muy lógica, solemos pasar por alto y cuando debemos buscar una variable llamada t, en todo un proyecto o solo en una clase de muchas líneas obtendremos muchos falsos positivos, no sería más fácil buscar una variable llamada TEMPERATURA_MAXIMA_PERMIDA, siendo esta una constante.

Evitar codificaciones: Crear codificaciones para nombre supone una carga extra que debemos aprender y por lo general son difíciles de pronunciar lo que estaría rompiendo la regla de Usar nombres que se puedan pronunciar.

Notación húngara: El autor nos quiere decir que este tipo de notación o codificación en la actualidad no es necesaria y lo que genera son obstáculos que dificultan la lectura del código. Pero, ¿qué es la notación húngara?, es un sistema utilizado para crear los nombres de las variables, este sistema utiliza prefijos para indicar el tipo de dichas variables, por ejemplo, se utiliza el prefijo b para las variables booleanas (bIsCanceled).

Prefijo de miembros: Ya no es necesario utilizar esa práctica que aconsejaba agregar el prefijo m_ a los nombre de variables, los entornos actuales nos permite identificar los miembros ya sea que los resalta o les cambia el color.

Interfaces e implementaciones: Agregar adornos a los nombre de las interfaces (por ejemplo una I inicio del nombre), es agregar más información de lo necesario, y en caso de necesitar implementar dicha interfaz se puede agregar el sufijo Impl, por ejemplo, si tenemos la Interfaz Presenter (note que no la llame IPresenter) su implementación podría llamarse PresenterImpl.

Evitar asignaciones mentales: La asignación mental ocurre cuando el nombre de una variable debe ser traducido mentalmente por quien lee el código para relacionar con algún término del dominio, este problema es habitual con nombres de variables de una sola letra.


Nota: Como el post se está haciendo muy extenso y no quiero cansarte, he decidido tomar aquel consejo de "divide y vencerás". Por tal razón terminaré de contarles acerca del capítulo 2 de Clean Code en el siguiente post (Clean Code Capítulo 2 Nombres con Sentido (2/2)). Para más artículos relacionados ver Clean Code

martes, 22 de noviembre de 2016

Clean Code Capítulo 1 Código Limpio


El capítulo 1 trata brevemente distintos puntos partiendo del código incorrecto, que no es más que código sin sentido, y que lastimosamente es el que más abunda en nuestras aplicaciones. Estamos hablando de código que a simple vista no deja ninguna pista de que hace o para qué sirve y por esa razón perdemos tiempo buscando su significado o buscandole sentido. Lamentablemente, estoy de acuerdo con el autor cuando dice que “Todos hemos sentido alivio de ver cómo un programa incorrecto funcionaba y hemos decidido que un mal programa que funciona es mejor que nada” y hemos postergado su solución (Ley de LeBlanc: Después es igual a nunca). Con el pasar del tiempo vemos como los problemas se van agravando y se reflejan en el costo, principalmente de tiempo (El equipo es menos productivo), pero todos sabemos que el tiempo es oro, por ende, este tiempo que nos cuesta mantener el código incorrecto (ningún cambio es trivial) se convierte en dinero y puede significar hasta la muerte de un proyecto. Por lo anterior, quiero citar al autor cuando dice “ya sabrá que dedicar tiempo a que el código sea correcto no solo es rentable, es una cuestión de supervivencia profesional”. En pocas palabras, nos llenamos de código incorrecto, pero ¿Porque ocurre esto? la respuesta está en el libro cuando declara que la culpa es nuestra, ya que, “No somos Profesionales” y no debemos descargar nuestra responsabilidad en los demás pues “Tampoco sería profesional que los programadores cedieron a la voluntad de los jefes que no entienden los riesgos de un posible desastre”. 


Seguidamente, profundiza en lo que es código limpio o de su concepto, mostrando una serie de definiciones dadas por grandes programadores como Bjarne Stroustrup, inventor de C++. Interiorizando todas estas definiciones, he llegado a la siguiente definición de código limpio:


Código con sentido, concreto, dotado de características como la simplicidad, eficiencia, legibilidad, sencillez, debe estar testeado, tener dependencias mínimas y hacer una cosa bien (este último tomado de la definición de Bjarne Stroustrup)


Por último, habla brevemente de la regla del Boy Scout, que en pocas palabras es entregar el código más limpio de lo que lo hemos recibido.


Este capítulo nos invita a que abramos nuestros ojos para ver la posible falta de profesionalismo que nos invade al momento de crear código y empecemos el cambio para escribir código limpio, buscando así ser profesionales en esta área. ¡Ya diste el primer paso!, que suele ser el más difícil. Sigue caminando.

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

lunes, 21 de noviembre de 2016

Clean Code - Código Limpio


El desarrollo de software es algo que me apasiona, particularmente la programación, lo que me ha llevado últimamente a querer dar un paso más hacia la profesionalización en este ámbito. Por tal motivo he empezado a estudiar sobre patrones de arquitectura y de diseño en lo que respecta al software, e indagar sobre el concepto de Código Limpio (Clean Code); por lo anterior inicié leyendo el libro Clean Code de Robert C. Martín, y me he animado a escribir sobre lo que voy conociendo con la lectura del mismo, una serie de artículos acerca de mis impresiones sobre el libro.


Por ahora quiero citar una frase que he visto que relacionan con este libro y es que “Todo programador debe leerlo”, cuando leí por primera vez esta frase fui un poco escéptico, pero al ir devorando cada una de las páginas e ir interiorizando poco a poco sus conceptos me ha convencido, por eso inició invitandote a leer este libro, lleno de pequeños y simples detalles que hacen grandes cambios, apoyado en lo escrito por James O. Coplien en el prólogo “Que dichas acciones sean simples no significan que sean simplistas, y mucho menos que sean sencillas”.  


Manos a la obra, tienes mucho que leer, interiorizar, cambiar y ajustar. El camino es largo pero interesante y muy gratificante en cuanto empiezas a ver los resultados. Muy pronto, a medida que vaya leyendo más sobre este grandioso libro, estaré publicando al respecto y actualizando este post con los enlaces a los respectivos artículos.

Artículos Relacionados

Te dejo acá una referencia en donde puedes comprar la versión en español o lo puedes mirar acá en Amazon.

sábado, 12 de noviembre de 2016

Agilismo: Una Historia de Otro Planeta


Qué mejor que explicarlo con una breve historia.


Había una vez, en una galaxia no muy lejana, un planeta llamado Software en donde sus habitantes practicaban una extraña magia de conjuros, códigos misteriosos y algoritmos, los cuales daban vida desde los más simples hasta los más locos, atrevidos e innovadores sueños. A la gente de este planeta se les llamaba programadores. Con el pasar de los años las prácticas y métodos utilizados por estos hechiceros y magos para construir aplicaciones (así se le llamaba al producto de la magia que ahí se practicaba) fueron generando descontento e infelicidad en algunas latitudes del planeta Software parcializando a su población, por un lado los que apoyaban las antiguas prácticas y por otro los que querían buscar nuevas formas de hacer las cosas. De este grupo de los que querían buscar nuevas formas de hacer las cosas a través de la experimentación de nuevos e innovadores métodos surge un grupo de grandes hechiceros que se reunieron para consolidar su legado en un manifiesto que proclamaron como el Manifiesto Ágil, escrito lleno de principios sabios que hablan de colaboración, flexibilidad, calidad y motivación, y resumido en cuatro valores que dieron vida  a una nueva magia, poderosa, envolvente y sobre toda llena de felicidad. Lo que desconocían estos grandes hechiceros es que eso que hicieron ese día, daría origen a una importante hermandad (Agilismo) conformada por nuevos y viejos hechiceros, programadores (Agilistas) motivados, con deseos de experimentar, de colaborar creando y utilizando métodos de nombres místicos como Scrum, Kanban, Lean y lean Startup, para construir aplicaciones. De esta manera en el planeta Software todos fueron felices, puesto que nació el agilismo como un nuevo estilo de vida, una filosofía, una actitud, un movimiento, una hermandad de hechiceros que adoptaron los principios y valores del Manifiesto Ágil que los ayuda a construir un software que aporte valor y competitividad, y sobre todo que los hace feliz. Para terminar esta historia espacial debo decir que fue tan poderosa esta filosofía que traspasó los límites del planeta Software llegando hasta otros planetas como el Financiero, donde nadie nunca pensó que llegaría, pero así fue y cada uno de estos planetas fueron dejándose envolver por su poder generador de un cambio orgánico desde su estructura hasta su visión y por su magia de cambiar a las personas haciéndolas más productivas, colaboradoras, flexibles, amables y felices.

Si después de esta historia te preguntas qué dicen esos cuatro valores y en general el Manifiesto Ágil te lo dejo a continuación: “aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.” Los valores son:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

Los doce principios del Manifiesto Ágil son los siguientes:

  1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
  2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
  3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
  4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
  5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 
  6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
  7. El software funcionando es la medida principal de progreso.
  8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
  10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
  12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

El Agilismo es un camino que te invito a iniciar, es muy fácil de empezar, pues ya diste el primer paso al leer este post y conocer los valores y principios del Manifiesto Ágil, ahora da el siguiente investigando aún más sobre él, te darás cuenta que ya está en casi todas partes y cuando menos te des cuenta estarás caminando por sí solo hacia la adopción de sus valores y principios, que básicamente de eso se trata. Déjate atrapar por su magia que puede transformar a una persona en alguien mejor y lo mismo le ocurre a las organizaciones cuando se toma con seriedad, responsabilidad y compromiso el agilismos, haciéndolas más productivas, flexibles y competitivas. Lo mejor es que no importa de qué sector o industria sea, si en ella trabajan personas el agilismo es para ellas, la base del agilismo son las personas.

Para ir terminando debo decir que ya ha pasado cierto tiempo desde que el Manifiesto Ágil vio la luz del día por primera vez, las personas, las empresas y un par de cosas más han cambiado en especial el sector al que fue dirigido inicialmente el Manifiesto Ágil. No estoy intentando decir que ya es obsoleto o que no es aplicable en otros sectores, pues me contradiría, ya que, acabo de decir que el agilismo ha traspasado las fronteras del Software y que el conocimiento del mismo es el comienzo al agilismo. Lo que pretendo es hacer un preámbulo acerca de un nuevo enfoque que ha surgido a raíz de que el Manifiesto Ágil no fue elaborado pensando en las dimensiones que ha tomado hoy en día el agilismo.

Este nuevo enfoque que se ha denominado Agilidad Moderna. Este nuevo enfoque del agilismo cuyo padres es Joshua Kerievsky (@JoshuaKerievsky) y del cual escuche por primera vez en la primera Jornadas Nacionales de Metodologías Ágiles - Ágiles Colombia 2016 y que volví a escuchar en una excelente charla de Johnny Ordoñez (@JohnnyOrdonez) en Agiles 2016 en Quito Ecuador, no busca reemplazar el Manifiesto Ágil sino que busca potenciarlo y hacer las cosas más simples, según Joshua Kerievsky "Agilidad Moderna es una comunidad de personas interesadas en descubrir mejores maneras de conseguir resultados impresionantes. Se aprovecha la sabiduría de muchas industrias, es impulsado por principios y un marco de trabajo libre". Sus cuatro principios son:




Como ya me he extendido un poco en este post los invito a que profundicen más acerca de este tema en la página oficial de:

NOTA: Si no sabes que es Ágiles 2016 te cuento que “son conferencias sin fines de lucro organizadas por representantes de todas las comunidades ágiles latinoamericanas”, el próximo año Agiles 2017 se realizará en Chile, desde ya te invito.

viernes, 11 de noviembre de 2016

¡Me acabo de enterar del Agilismo! ¿A quien sigo?


Cuando uno empieza un camino, ya sea para aprender algún marco de trabajo, una metodología, un lenguaje de programación, nuevas recetas de cocina o sea lo que sea que se quiera aprender siempre es bueno empezar teniendo un punto de referencia, alguien a quien seguir para no perdernos en el camino, es por esto que en este documento que hace un poco empecé a elaborar y espero que ahora entre todos de forma colaborativa elaboremos, enriquezcamos y hagamos una fuente para aquellos que apenas empiezan, he agregado a usuarios de Twitter de algunos agilistas de Colombia, de latinoamérica y unas cuantas personas más del resto del mundo.

Es un buen comienzo para aquellos que empiezan a concocer el mundo del agilismo y que no saben a quién seguir, ya que, a partir de ahí pueden empezar a seguir a estos agilistas y a conocer a quienes siguen ellos con el fin de contactar a otros agilistas. También encontrarán links a documentos o páginas donde pueden empezar a leer sobre agilismo y sobre algunos framework como Scrum y por supuesto está el link de la página de Agiles Colombia así como la dirección de meetup de Ágiles Colombia y Ágiles Ocaña donde podrán encontrar personas dispuestas a colaborar. No olviden que una parte de la esencia del Manifiesto Ágil y por ende del agilismo es la Colaboración. Cabe recalcar que me pueden escribir y consultar o pedir cualquier ayuda que si yo directamente no les puedo ayudar me uniré a su causa en busca de aquella persona que pueda ayudarnos (recuerda me uní a tu causa).


Mira el Documento Acá
Ágiles Colombia
Meetup Ágiles Colombia
Meetup Ágiles Ocaña


No olviden que si quieren pueden hacer su aporte a este documento agregando la información que creas relevante para aquellos que empiezan el camino del agilismo. 

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 ...