Clean Code - Acto social

Cuántas veces como programadores nos hemos sentido percibidos como gente solitaria que está frente a un computador, quizás algunas veces aceptamos eso porque nuestro código es algo que podemos crear solos o buscando recursos desde la Internet. Nada más lejos de la realidad cuando se trabaja en equipo.

El acto de programar

El programador crea o modifica otro código existente, así adapta la funcionalidad que va a implementar. Él piensa en la mejor forma de hacer entendible su código, así alguien más va a reconocer rápidamente lo que hace y sus cambios serán más certeros. El programador no es un ente solitario, el trabaja con código de otras personas. Programar es un acto social. Así es presentado el arte de programar en el libro Clean Code.

Comunicar

El libro, o biblia de la programación para otros, se centra en facilitar la comunicación de la intención del código, con sus funciones, clases, variables, etc., ¿Por qué eso es tan importante? pues porque nada asegura que el mismo programador trabaje en la misma pieza de código, éste puede tener asignadas otras tareas o ya no es parte de la empresa. En el Software, el código es una de las mejores documentaciones que se puede dejar y éste tiene un propósito, una razón para existir, y es mejor comunicarlo fácilmente siendo coherente.

Fundamentos

El libro recomienda como tiene que formarse una clase, las mejores opciones de nombres, variables, tamaño de las funciones, niveles de abstracción, principios de responsabilidad, entre otros. Explica porque lo pequeño es mejor, ayuda a elegir nombres adecuados, la importancia de proporcionarle un formato común al código, el autor hace fuertes críticas de los comentarios de código que explican algo que no puede hacerlo por sí mismo, además de entregar un montón de heurísticas que sirven como guía al momento de codificar.

Recomendaciones

El autor no pasa por alto el diseño. Agregar o cambiar código, por mínimos que sea, tiene un grado de impacto en el diseño del sistema y condiciona su evolución. El autor abarca principios que ayudan a hacer un trabajo de programador profesional, algo serio que proporciona valor y que todos nuestros compañeros de trabajo seguramente agradecerán porque no será un dolor de cabeza leer ese compás de líneas que sigue un ritmo idéntico al que tiene el programador que lo lee. No hay que olvidar que estamos frente a recomendaciones y varios de éstas son discutibles o incluso abiertas a mejoras, aplicables según criterio.

El libro sigue la premisa de que el Software codificado va evolucionando, su complejidad aumenta y a menos que seas el primero en escribir código, siempre vas a tener que entender lo que hace el código existente, y eso toma tiempo. Programar es conversar contigo mismo y con otros desarrolladores, el idioma en común, así como las convenciones y fluidez son fundamentales para lograr una buena comunicación.

La atracción de JSON

Cuando algo se está volviendo cada vez más complejo y se encuentra que está realizando más cosas de las que necesita hacer, entonces eso comienza a desperdiciar el tiempo de la gente, las comunicaciones a los desarrolladores.

A las personas les gustan los formatos simples, estos son más fáciles de entender y tienen solamente las cosas necesarias para hacer lo que realmente necesitan hacer.

La llegada de XML

Algo como esto ha sucedido con XML y JSON, primero llegó XML  a nuestro mundo para satisfacer la necesidad de tener un estándar independiente del lenguaje de programación para intercambiar datos entre diferentes plataformas, y eso fue resuelto en una elegante forma. Así, cada vez que se necesitaba intercambiar datos entre dos diferentes plataformas sin considerar el lenguaje de programación en que estos fueron implementados fue usado XML. Los datos usaban XML, las bases de datos estaban enviando datos usándolo, los Servicios Web SOAP también lo usaban, etc. Era la única opción.

La llegada de JSON

Entonces  llegaron algunas alternativas, una de ellas fue JSON que estaba alcanzando los mismos objetivos de XML con diferencias que hacían algunas cosas más fáciles y otras más difíciles. Los desarrolladores tienen más opciones y ellos pueden adaptarse mejor a las necesidades de sus plataformas. JSON llegó con la promesa de ser más rápido con su formato liviano que tenía menos complejidad que su antecesor.

Cualidades de JSON

Una de las ventajas de JSON es su relación con AJAX que necesita cargar rápidamente los datos y asincrónicamente sin retrasar la renderización de las páginas. Las páginas sociales necesitan refrescar su información una abundante cantidad de veces, pequeñas optimizaciones pueden tener un gran impacto en la eficiencia y performance de una aplicación Web. Por otro lado, las aplicaciones usando gran cantidad de información (Big Data) llegaron con sus propias necesidades, algunas de ellas eran el almacenamiento y manipulación de sus colosales datos, JSON provee una forma más rápida para usar esas gigantes bases de datos basadas en documentos.

JSON es un formato para intercambiar datos y se enfoca en una sencilla forma para permitir su validación y parseo que son implementados en el lenguaje que usa este formato, entregando una fácil forma de manipular sus elementos anidados. A diferencia, XML parsea los datos usando un DOM (Document Object Model) o un Schema por el lado del cliente que requiere una respuesta en XML.

Si se considera el tamaño de los documentos XML y los del JSON, debido a la complejidad del XML, ese usa una mayor banda ancha cuando se envían datos sobre la red. Si además consideramos que cada vez los dispositivos como iPhones y Tablets son más populares en la actualidad, semejante cantidad de datos en una red lenta causa tardanza en la carga de páginas y una peor experiencia de usuario. Actualmente XML es ampliamente usado y tiene sus propios beneficios, pero JSON ha llegado a ser el preferido para intercambiar datos en internet en los últimos años.

Spikes - Descubriendo mundos

Es común que los desarrolladores siempre estén enfrentando nuevos desafíos, muchos de ellos son pequeños o abordables y algunas personas ya han resuelto un problema parecido en el mismo equipo o en la Internet. En otras ocasiones ellos se enfrentan a desarrollos completamente nuevos y ellos no tienen idea de cómo abordarlos.

El riesgo puede ser muy grande y el tiempo de la implementación del nuevo requerimiento podría tomar días o hasta años. Después de codificar el requerimiento, si es que pueden, los desarrolladores tienen que testear como está funcionando todo el sistema y si se cumplieron las expectativas. Nada parece claro y es difícil ver tierra en el mar. Es necesario hacer algo más antes de estimar la dificultad, impacto y tiempo para implementar el requerimiento.

Spikes

Los Spikes son una invención de la metodología Extreme Programming (XP), desarrollar un Spike es hacer una implementación de algo relacionado a un potencial requerimiento. ¿Por qué es necesario hacer un Spike antes de un requerimiento?

Los Spikes son útiles cuando el requerimiento es hacer un cambio arquitectural, probar una nueva tecnología, añadir una gran funcionalidad o cambiar una actual implementación y revisar si eso es posible, también es útil para saber mejor el tiempo que tomará el desarrollo, cómo la implementación resulta afectada, y revisar si las funcionalidades tendrán el comportamiento esperado. Definitivamente, el requerimiento es demasiado inmaduro y necesita algo de trabajo para convertirse en un requerimiento con un alcance lograble. 

Además, ellos son usados para investigaciones, diseño, prototipados, o aumentar el conocimiento y reducir el riesgo de un alcance técnico.

Spikes emergiendo

Todos los requerimientos para construir una funcionalidad tienen un riesgo, esta información desconocida puede ser descubierta mientras el requerimiento esta construyéndose, en una conversación de equipo, usando el criterio del desarrollador, discutiendo, colaborando, negociando, etc. El equipo determina hacer un Spike cuando el riesgo es muy algo o ellos realmente necesitan saber más sobre un requerimiento que puede ser demasiado grande. Usando Spikes el equipo obtendrá la información con datos convincentes, entonces los miembros del equipo pueden ver y tomar mejores decisiones.

Cuando el equipo o el Product Owner determina que hay que hacer un Spike, este puede ser estimado y priorizado tal como los otros requerimientos. El mayor valor de un Spike es la información obtenida, no el código desarrollado.

Como enfrentar un Spike

La recomendación es implementar un Spike con un pequeño programa. Es importante investigar y leer, pero es aún más importante escribir código para experimentar, no profundizar solamente en la teoría. Lo complejo tiene que ser ignorado, solo hay que enfocarse en obtener algo funcionando, no importa si el código no es reusable porque éste es un experimento. Documentar y mostrar los resultados a los compañeros es imprescindible. Evitar el código de producción cuando es posible, si no lo es, entonces hay que usarlo, pero no se puede comitear.

Durante un Spike, los desarrolladores no pueden comenzar profundizando porque los Spikes no se encuentran bien definidos. El que investiga en esa niebla puede perderse en el mar de información o intentando hacer muchas cosas al mismo tiempo. También, es importante tener en mente que los Spikes no entregan valor al usuario directamente, por lo tanto, ellos deben ser usados con precaución.

Finalmente, Spikes pueden ser útiles algunas veces, pero la mayoría de los requerimientos no necesitan usar este tipo de desarrollos. Es importante tomarse un tiempo y decidir si es necesario el Spike y esa decisión puede ser crítica en algunos casos para el futuro del proyecto.

Servidores - Computadores como servicios

¿Tú eres alguien conocido? ¿Cómo vas a ser conocido si nadie puede comunicarse contigo? Estás solitario(a) y hablas con nadie más que una persona a la vez. Mañana doscientas personas requerirán hablar contigo, después de mañana mil, y la cantidad puede continuar incrementando. ¿Cómo vas a llevar eso? ¿Qué tienes tú que es muy importante para ellos y para ti?

¿Qué es un servidor?

Un servidor es un computador que provee servicios para otros computadores en una red, es claro que esta es una básica definición para un servidor. Todos los computadores pueden ser un servidor, no es necesario tener un sistema operativo especial instalado para hacer eso.

Los verdaderos servidores son computadores que trabajan las 24 horas, 7 días a la semana, ellos son estables, se recuperan de fallas, etc. Un servidor puede ser sólo un computador o un computador unido con otros computadores o artefactos electrónicos que trabajan juntos.

Un servidor puede proveer archivos compartidos, una impresora compartida, aplicaciones compartidas, administración de clientes, un servidor de base de datos y más. Así, en el caso de archivos compartidos, este tiene la habilidad de almacenar carpetas y archivos en una parte y los usuarios pueden acceder y actualizarlos. En un servidor Web, los usuarios pueden acceder a la información con un Browser  (Chrome, Firefox, IE, etc.) e interactuar con lo proveído en páginas como Google, Facebook, tú propio blog, sitio Web de tu compañía, etc.

Sistema operativo de un servidor

Un sistema operativo (OS, Operative System) para un servidor es una alternativa cuando es necesario más poder. Estos OS son más robustos, seguros, estables y caros que los OS comunes. Estos pueden soportar miles de usuarios, pero en estos OS es más difícil tener el mismo software instalado en un computador personal stándar. La autenticación también es más fuerte, a nadie le gustaría que hackers usen bugs para acceder a la información sensible de una compañía y los servidores están expuestos.

Hardware del Servidor

Parecido al caso del OS del servidor, si se necesita un comportamiento especial para el servidor, entonces es necesario un hardware especial. El hardware puede ser más de una fuente de poder para mantener al servidor siempre proveyendo servicios, más de una disco duro, administración de redes, y más, hay muchos tipos de hardware para servidores. El procesador y la memoria también son importantes para soportar muchas solicitudes y aplicaciones.

El hardware también intenta asegurar que el servidor esta siempre funcionando y proveyendo sus servicios, este nunca debería apagarse.

Las empresas pueden mejorar cuando usan servidores, sus procesos pueden moverse más ágilmente y ser más poderosos. Los productos de la compañía pueden trabajar usando servidores con servicios específicos y los potenciales clientes pueden conocer mejor a la compañía a través de un sitio Web. Es necesario recordar que el servidor es una cosa y éste trabaja con software que provee sitios Web, servicios Web, u otras aplicaciones para asegurar el futuro de la empresa.

Rule Engines - Software tomando decisiones

Piensa cómo tomas las decisiones en tu vida. Cuáles criterios usas para seleccionar tú trabajo, mascotas, casa o una escuela para tus niños. Tú sabes que algunas decisiones son más importantes que otras, el resto de tu vida puede depender de algunas de ellas. No pases por alto las decisiones clave.

¿Te gustaría tener la información para tomar mejores decisiones? Las decisiones están basadas en hechos y la experiencia previa. ¿Existen algunas reglas que pueden guiarte para tener lo que quieres?

Automatizando decisiones

Un sistema puede tener la capacidad para tomar decisiones usando su conocimiento base. Su base de conocimiento es nada más que condiciones y acciones. Si las condiciones son cumplidas, entonces el sistema decide acciones a tomar

Por otra parte, las condiciones y acciones no son seleccionadas aleatoriamente, hay expertos en un dominio específico que tienen el conocimiento para recomendar la mejor decisión dependiendo de los hechos que se han cumplido. Un sistema, además tiene la capacidad de automatizar las decisiones, los expertos solamente determinan en qué condiciones la compañía tiene que tomar las acciones. En otras palabras, si las condiciones son ciertas, las acciones son ejecutadas..

Motor de reglas

El Rule Engine es quién examina las reglas con el Inference Engine, es decir, es un Software que ayuda a administrar las reglas del sistema.

El Rule Engine es código que trabaja separado del código de implementación y tiene la posibilidad de cambiar sin tener que pedir ayuda a los programadores. Los expertos del dominio pueden adherir nuevas reglas y hacer los cambios cuando quieran.

Un Rule Engine estándar puede incluir: un Business Rule Repository que es una base de datos para almacenar las reglas del negocio, un Rule Engine Execution Code que tiene el actual código programado para reforzar las reglas y un Business Rule Editor que es una interfaz de usuario intuitiva para definir, editar, documentar y diseñar reglas.

Usuarios del negocio pueden definir las reglas

Con verbalizaciones, los usuarios pueden definir las reglas usando su propio lenguaje. Naturalmente, ellos definen las condiciones y acciones a tomar sin cambiar el código del programa, separando el trabajo del programador y las definiciones de los analistas del negocio.

Verbalizaciones pueden ser soportadas por diferentes sentencias, muchas de ellas pueden significar lo mismo, enfocándose en la expresividad, claridad y formalidad.

Variedades de Rule Engines

Hay muchos tipos de motor de reglas, esos pueden tener reglas de inferencia u otros tipos, usar código Java, C++, u otros, ser Open Source o no. Algunos de ellos tienen características adicionales como arboles de decisión, flujos de reglas, versionamiento de despliegues, simulaciones, reportes, etc.

El Rule Engine te ayuda a decidir "qué hacer", pero no "cómo hacerlo", así separa los objetos del dominio con la lógica que está en las reglas, minimizando los cambios futuros. También provee una aplicación con buenos diseños cuando es usado adecuadamente.

Maven - Administrando tu vida

Piensa en un mundo en el cual estás solo, tú no estás dependiendo de nadie, no necesitas nada más que a ti mismo. Tú puedes realizar tus tareas y sobrevivir sólo por tu propia cuenta. Si te gusta eso, entonces puedes hacer pocas cosas en tu vida.

Un proyecto Java no está solitario

Construir un proyecto Java puede parecer simple, se necesita compilar las clases java y obtener la funcionalidad en un .jar. No obstante, en otros casos, un proyecto Java es más grande, el cual está usando una gran cantidad de proyectos diferentes de los que depende, es algo más difícil de manejar porque esos proyectos tienen sus propias versiones. Si hay muchos proyectos trabajando juntos, cada uno con sus versiones y cadena de dependencias, entonces es necesario automatizar eso. El tiempo no puede ser desperdiciado en tareas repetitivas, la preocupación está en escribir código. Y se necesita buen código.

¿Los proyectos Java unidos son más fuertes?

Alguien puede decir "Para administrar mi proyecto sin depender de nadie, colocaré todas las clases Java en un único proyecto". Alguien puede hacer esto, y puede hacer lo que quiera, pero violará todas las buenas prácticas y recomendaciones de diseño. Se tendrá un complicado proyecto que nadie será capaz de mantener porque este único proyecto no se encuentra separado en componentes con diferentes propósitos.

Cuando un proyecto más listo es construido usando un poco de sentido común, este proyecto tendrá un propósito y este tiene una responsabilidad. En este caso, hay varios proyectos que trabajan juntos, cada uno sabe los proyectos que necesita para hacer su trabajo. Ellos no están trabajando solos y cuando se necesita arreglar algo o adherir una nueva funcionalidad, entonces será más fácil saber dónde empezar a codificar. Tu diseño tiene sentido ahora.

Controlando la vida de un projecto

Maven puede ayudar cuando hay un proyecto java y tareas repetitivas como el manejo de versiones y su manejo de dependencias, los cuales pueden convertirse en un dolor de cabeza. Los nombres de los proyectos y la versión solamente es especificada una vez, sólo una vez, y el equipo puede preocuparse de codificar u otras actividades más importantes. Así mismo, el proyecto codificado también tiene una versión, entonces puede ser referenciado por otros.

Maven trabaja con repositorios, los cuales contienen los proyectos .jar necesitados y descargados. También pueden existir otros repositorios donde el jar es deployado, los desarrolladores no están trabajando solos, y cada uno tiene que trabajar con la última versión de todos.

Maven usa comandos simples para construir todo un proyecto, esos son repetitivos y siguen  algunos estándares como estructura de las carpetas donde está el código, los test, recursos, etc., los problemas para manejar los proyectos son reducidos.

El código Java es usado para obtener la funcionalidad y el pom xml es usado para manejar el proyecto, ese archivo es lo que entiendo Maven, ese es el proyecto en sí mismo.

Y es más que eso

 Maven usa plugins con diferentes intenciones. Ellos pueden ser usados para correr test, deployar un proyecto en un servidor, generar reportes, etc., hay muchos de éstos y son añadidos más. Incluso es posible hacer tu propio plugin.

Los archetypes permiten construir un proyecto war, ear, o un jar, entre muchos otros, añadiendo Spring, JSF y muchas tecnologías más, solamente usando un comando sencillo. Empezar a codificar en un proyecto rápidamente, viendo sus resultados, es más fácil. En el caso que no se necesita seguir la misma estructura del archetype, es permitido hacer modificaciones en la estructura del proyecto porque el pom generado puede cambiar. 

Como los proyectos, Maven no está trabajando sólo

Existe una comunidad de código abierto que se encuentra integrando Maven con otras tecnologías como Hudson que necesita construir un proyecto y correr sus test automatizados. También usar plugins para deployar automáticamente un proyecto en un servidor y tiene mucho más por ofrecer.

Maven también tiene algunas desventajas, aquí hay algunas de ellas:

• El archivo pom puede ser muy grande. Si el proyecto usa muchas dependencias y plugins, entonces no hay forma de separar las partes. El archivo es más difícil de entender a medida que crece.
• Dos dependencias de un proyecto pueden necesitar la misma dependencia, pero con diferentes versiones. Las dependencias transitivas son más difíciles de manejar.
• Una dependencia que no compila puede necesitar otras dependencias (dependencias transitivas) y es necesario actualizar esta última y compilarla en el caso que se encuentre en construcción también.
• El ciclo de construcción de un proyecto puede ser lento, aunque sus pasos son necesarios. Éste necesita descargar todas las dependencias, compilar, correr los tests, instalar y deployar. Se puede especificar si se quiere ignorar algún paso.

Maven administra la vida de un proyecto. Tiene algunas deficiencias, pero hace su trabajo y lo hace bien.

Retrospectivas ágiles

Los equipos que usan Scrum, o algún derivado de éste, tiene un evento llamado Retrospectiva. La retrospectiva es un rito donde el equipo se reune al final de cada iteración y el  objetivo es mejorar, en la práctica se trata de detectar los puntos fuertes y débiles, luego deciden cómo y qué mejorar. La mejora continua se mantiene, lo que es una base para todo entorno ágil.

Así, los equipos se adaptan y cambian, sobreviviendo en esta industria que privilegia la velocidad y el software a tiempo, siendo las bases para que una empresa pueda mantenerse, superar a otras o encontrar nuevos nichos.

Sin embargo, no se trata de hacer retrospectivas solamente por cumplir con lo que establece Scrum. Algunas situaciones comunes son:

• ¿Qué pasa cuando proponemos cerca de 20 mejoras a realizar? No tengo dudas de que ninguna de esas mejoras se van a realizar, son muchas ideas y es un trabajo arduo medirlas. Son tantas que el equipo no se puede enfocar en alguna.
• ¿Qué hacemos durante la retrospectiva? Tampoco se trata de reunir al equipo y que mencionen lo bueno, lo malo, lo bonito y lo feo. Muchos de los participantes pueden estar pensando en lo que deben entregar, otros en la forma en que perdemos el tiempo, o hasta algunos agradecen estar lejos de su rutina diaria por unos minutos.

Las mencionadas y muchas otras situaciones acontecen durante las retrospectivas. Cuando el equipo siente que es una completa pérdida de tiempo, entonces es mejor no hacerlas. 

A continuación, voy a mencionar algunas bases e ideas para llevar a cabo una retrospectiva:

• Cada equipo tiene necesidades y situaciones diferentes. Algunos equipos tienen mala comunicación, a otros les falta coaching, aprender formas de programar, hacer mejor Stories, o automatizar tests. Las retrospectivas se guían según las necesidades actuales del equipo.
• Hay que tener una planificación de las actividades que se van a realizar, según la cantidad de personas y tiempo. Así como considerar las etapas que pueden ser: presentación, enfocar a las personas hacia la retrospectiva, recolectar datos y situaciones que han pasado durante la iteración, encontrar patrones, proponer ideas, y por último el cierre. El libro Agile Retrospectives (de Esther y Diana) menciona sus posibles fases y detalla varias de las actividades a realizar durante cada una.
• Durante las retrospectivas son sumamente importantes las dinámicas que se manejen. Gracias a ellas podemos encontrar los problemas, patrones y soluciones adecuadas.
• Cuando el equipo encuentra los puntos a mejorar, éste sabe cuáles son los más importantes. Por lo tanto, tiene que priorizarlos y escoger muy pocos (por ejemplo dos). Así, el equipo sabe lo que va y tiene que mejorar, estableciendo responsabilidades según el caso.
• En las retrospectivas trabajamos con personas, por ende, tenemos que considerar sus emociones, energías y actitudes.

Y por último, las retrospectivas pueden ser usadas en cualquier equipo que se dediqué al desarrollo de software u otro tipo de labor, no es requerido el uso de Scrum, sino la voluntad de hacer mejor el trabajo, de ser un mejor equipo.

Me quedo con algunas incognitas: ¿Cómo llevar una retrospectiva en línea? ¿Cómo hacer ver al líder del equipo que las retrospectivas deben ser guíadas de otra forma? ¿Qué actividades escoger según la situación de cada equipo?

Mi Motivación

El software no se puede tocar, pero se puede crear y observar. Algunas veces es apreciable, mientras que en otras dan ganas de gritar y salir corriendo.

El software es más allá de ceros y unos, es la combinación de éstos para crear algo mayor, algo complejo, algo que nadie ha imaginado. Los ceros y unos son algo más básico que los átomos que conforman las moléculas y a su vez, seres más complejos. Los binarios son el inicio y quizás el fin.

El software es visto como arte, es una creación del ser humano. Y sí, puede llegar a ser tan hermosa y hasta tener nada que envidiarle a las más grandes obras. El objetivo mayor es superarlas.

Los ceros y unos van más allá de lo que se ve, porque su creación puede ser realizada por muchas personas. La comunicación y relación entre personas tienen un potencial, y tiene que ser explotarlo.

En fin, los ceros y unos son como hijos. Por eso, ellos son nuestra responsabilidad, podríamos llorar de felicidad por una buena creación y sentirnos orgullosos por el trabajo bien realizado.

Me atrevo a admitirlo, es lo que me mueve.