¿Qué tan importante es la arquitectura de un sistema?

¿Qué ocurre “normalmente”?

Me gustaría empezar aclarando lo que posiblemente muchos hemos vivido en nuestros proyectos. Un sistema se construye con o sin una arquitectura definida. La realidad indica que quieras o no, el sistema se construirá pues así lo determina el negocio. En resumen, tenemos que responder a una necesidad.

Si el sistema ya está en producción y no está claro si hubo un trabajo de arquitectura, más que tomar una posición al respecto, lo que debemos hacer es evaluar y fundamentar con evidencias, el comportamiento del software desde su primera liberación al usuario.

Fuente: [Clean Code]

Si el sistema no ha presentado problemas a consecuencia de cambios constantes en el negocio, podremos concluir de que la decisión tomada fue la mejor para esa realidad. Claro está, que eso no implica que dicha formula funcione para otras realidades.

Ahora, si es que está en nuestras manos incluir este tipo de trabajos (es decir, los de arquitectura), pues tenemos que hacerlo sin dudar siquiera un segundo 🙂

¿Cuál es el impacto “mínimo” de una arquitectura?

En este tipo de situaciones considero poco profesional que nos basemos en supuestos, puntos de vista, corazonadas o peor aún en feelings, pues lamentáblemente estos no nos servirán en momentos que llegan gracias a los clásicos y no tan queridos “cambios de última hora”. Es por ello que en vez de feelings, lo mejor es que tengamos a la mano hechos concretos:

  1. Impacto en el proyecto: Un caso –muy gráfico– se remonta a un hecho ocurrido en USA en 1940. Si no conocían [la caída del puente Tacoma Narrows], les comento que hay [estudios al respecto] y que todo indica que el diseño inicial omitió consideraciones como por ejemplo, el efecto que tendría el viento sobre la estructura del puente ¿Servirá de algo compartir este tipo de experiencias? Esto lo dejo a su elección, pero vale la pena mencionar que para esa época, USD 6MM fue la cantidad de dinero que literalmente “se fue al agua”
  1. Rapidez de implementación: Podría sonar lógico escuchar que una buena práctica incrementa la rapidez del desarrollo, pero es mejor mostrar un caso en el que, por ejemplo, TDD genera una mejora de al menos 30% del tiempo esperado bajo “condiciones normales”
  1. Costos de mantenimiento: Si bien es cierto este estudio se hizo hace más de veinte años, estoy seguro de que se han encontrado con problemas que son complicados de resolver, pues la solución implicaba “cambiar muchas cosas”. Aquí un gráfico que refleja lo encontrado luego de analizar proyectos en empresas como HP o IBM, el cual en resumen indica que si hemos avanzado mucho en el trabajo y nos encontramos con un error, corregirlo será muy costoso.
Fuente: [Code Complete]

¿Qué consideraciones debe incluir nuestra arquitectura?

La “respuesta corta” es, tenemos que implementar nuestro sistema considerando una arquitectura que soportará las necesidades del negocio.

La “respuesta larga” incluye estas consideraciones:

  1. Estamos en la época en la que gracias a la agilidad, podemos confirmar en plazos cortos si nuestro producto (o parte de este) es útil. De aquí es donde se desprende el concepto de valor.
  1. El valor se asocia a la utilidad desde el punto de vista el usuario, y eso es bueno, pero lo que no debemos olvidar es que el usuario final no es ni será el único usuario del sistema. Pues de alguna u otra manera, los desarrolladores y resto del equipo técnico son usuarios. Por consiguiente, el valor también se debe visualizar desde una perspectiva técnica.
  1. Este “valor técnico” muchas veces es confundido con una necesidad que podría estar en una prioridad distinta a la requerida por el usuario final. Y es lo que comúnmente ocurre, pues “eso es transparente para el usuario”
  1. Esta nueva restricción podría basarse en la experiencia del equipo, pero lo recomendable es incluir criterios de calidad probados por el mercado. Para esto hay muchos modelos, pero creo que una base muy entendible es [la propuesta de Jim McCall]:
  1. Cubrir los criterios de cada perspectiva, requerirá contar con una arquitectura que las soporte y un conjunto de prácticas que no necesariamente se verán reflejadas en el diseño, pero sí en la implementación del mismo. Es aquí donde entran a tallar el uso de estándares de programación o de prácticas como la de TDD o incluso prácticas de DevOps (y la lista podría ser muy larga)

¿Dónde está el código?

Si bien es cierto soy partidario de hablar con código en mano, este es un caso en que necesitamos aceptar que el código llegará luego de entender con claridad los criterios mencionados por el Modelo de McCall. La mala noticia es que no hay magia en este trabajo, si queremos empezar y no sabemos por dónde, pues podríamos tener en cuenta lo siguiente:

  1. Hace poco escribí sobre [10 aspectos a considerar si les interesa la arquitectura]. Si es que ya se sienten listos para empezar con la parte técnica, pues les sugiero revisar los puntos 3 y 7 (Conceptualizar y Estudiar y poner en práctica).
  1. Si bien es cierto [mi post] lo menciona, es posible que no esté claro cómo empezar con lo que denomino “conceptualización” ¿Cómo podrían empezar con esto? Pues este gráfico de niveles de diseño, les dará una idea de lo que a algunos les podría parecer obvio, pero que a pesar de ello he notado que muchas veces no se hace bien, debido a la necesidad de escribir código lo más pronto posible.
Fuente: [Code Complete]
  1. Este tipo de razonamiento se debe complementar con conceptos de diseño como [acoplamiento / cohesión] y claro, de [SOLID]. De este último he encontrado un [video que lo explica muy bien] y que además muestra ejemplos de código.

Conclusiones

Creo que sobran argumentos sobre la importancia de la arquitectura de un sistema, pero esto no sirve de mucho si no aceptamos que la arquitectura es solo una parte del trabajo que debemos realizar.

Líneas arriba mencioné la relación que existe entre la arquitectura y las prácticas como TDD, DevOps y aquí podría agregar los estilos de arquitectura, el uso de patrones de diseño, automatización de pruebas y herramientas que nos permitan acelerar de manera eficiente el trabajo del equipo de desarrollo. Sin olvidar claro, el concepto de valor.

Por otra parte, lo que no debemos hacer es separar el concepto de valor en más de una vertiente. Mi explicación del “valor técnico” fue hecha por la necesidad de demostrar de que el “valor” incluye otros factores, y que en primera instancia estos son transparentes para el usuario, pero con una correcta asesoria este comprenderá la necesidad de incluir estos alcances a lo largo del proyecto.

Me gustaría agregar que la entrega de valor debe estar equibilibrada bajo la premisa de que no hay un solo tipo de usuario. Esta es muchas veces una línea delgada con alto riesgo de ser confundida u omitida.

Un abrazo,

Un libro de JavaScript que no debes dejar pasar

Espero ser breve pero les cuento que creo haber encontrado un excelente libro de JavaScript 😀

Estoy contento con [Eloquent JavaScript] (Marijn Haverbeke, 2018) pues además de tener [buenos reviews], estar actualizado (pues incluye información sobre [Node.js], lo cual ya es bastante) y ser gratuito, incluye código de ejemplo que puedes ejecutar mientras vas estudiando o por medio de la sección [code sandbox] ¿Qué más puedes pedir?

Fuente: Archivo personal

Pues claro, aquí tienes [la web del libro] También te dejo el link para que te descargues el [PDF], [ePUB],o el [MOBI] y claro, si quieres comprarlo, también [puedes hacerlo] 🙂

Solo le he dado una revisada general, espero que ustedes lo puedan aprovechar y claro, una vez más confirmo de que excusas pueden sobrar pero [material para estudiar], hay de sobra.

Un abrazo,

Cómo aprender JavaScript y no morir en el intento

Mientrás más pasa el tiempo, más creo que JavaScript es un lenguaje amado y odiado por muchos.

Eso no quita que piense en lo interesante que es, gracias a la cantidad de cosas que puedes hacer tanto en el cliente como en el servidor. Y con esto último no solo estoy hablando de [Node.js]

Estos meses me he propuesto reforzar mis conocimientos en JavaScript, así que decidí escribir este post a manera de resumen de lo que voy encontrando. Espero que sea algo así como un punto de partida para todos aquellos que no nos consideramos expertos en el lenguaje.

Pues bien, aquí las preguntas que tenemos que hacernos antes de entrar a este nuevo mundo:

  1. ¿De qué trata JavaScript? [Este video de casi veinte minutos] lo explica muy bien y está en español-humano :D. Con esto quiero decir que no hay ningún requisito para entenderlo y lo más importante; incluye teoría y ejemplos con código en vivo. Mi recomendación aquí es que le dediques mucha atención y si gustas, podrías seguir paso a paso [las instrucciones que van indicando]
  1. ¿Puedo aprender de manera interactiva? Hasta el momento he encontrado tres lugares con esta metodología de enseñanza. Yo sugiero practicar en al menos dos de estas:
Workshopper (tutorial interactivo de nodeschool). Fuente: Archivo personal
  1. ¿Con qué libro debo empezar? Si quieres contar con un libro de cabecera, te recomiendo que busques [JavaScript: The Good Parts] (Douglas Crockford, 2008). Si bien es cierto no lo he terminado –y para algunos es algo viejo–, hasta el momento me ha sorprendido. Entiendo que hace poco el autor publicó [How JavaScript Works] (2018) pero no lo he revisado. Sinceramente no me sorprendería que sea tan bueno como la primera publicación.
Fuente: [Amazon]
  1. (Bonus) ¿Qué más podemos hacer? Sin ánimo de caer en un posible ataque de [infoxicación], he encontrado material muy interesante que dejaré a su elección:
    • Este [video] de los amigos de FreeCodeCamp es de 3 horas (y no terminé de verlo) pero explica paso a paso el tutorial ofrecido en su web.
    • Este [tutorial de JavaScript], siempre y cuando busques una –extensa– referencia adicional.
    • Estos videos del buen Douglas Crockford en los que habla de [The good parts], [The better parts] y claro, un link a [la sección de videos] que tiene registrados en su blog.
    • Por último (y no menos importante) consideren la opción de buscar ayuda o mejor aún, aprender en conjunto. Para esto les comento que los amigos de NodeSchool brindan esa opción y aquí en Lima hay una reunión una vez al mes. Aquí [la cuenta de twitter] por si están interesados en los próximos eventos 🙂

Como podrán notar hay mucho por estudiar, pero gracias a la cantidad de recursos disponibles, cada vez es más fácil poner en práctica nuestros conocimientos.

Les sugiero que no pierdan las ganas con este lenguaje, pues tiene mucho potencial a pesar claro, de la relación amor-odio que les comenté al iniciar esta publicación. Esto lo comprenderán con el paso de las líneas de código que vayan escribiendo 🙂

Un abrazo,

3 recursos para aprender Docker

Si bien es cierto esta tecnología lleva [más de cinco años en el mercado], he notado que todavía es novedad para muchos desarrolladores de software. Yo creo que no tendría sentido crear contenido explicando a dealle [¿qué es Docker?] o [en qué se diferencia con tecnologías de máquinas virtuales], pues ya hay mucho de ellos en la red. En vez de eso podríamos reflexionar y hacernos las siguientes preguntas:

  • ¿Tenemos problemas para preparar un nuevo ambiente de desarrollo? Quizá esto se puede hacer pero requiere mucho tiempo y revisar un manual que pocos logramos comprender.
  • ¿Tenemos un programa que solo funciona en la máquina de un desarrollador? Es decir, ni siquiera en la máquina de otro desarrollador.
Fuente: [Geek Republic]
  • ¿Tenemos problemas de instalación por las dependencias entre aplicaciones o versiones de librerías?

Si hemos tenido al menos uno de estos casos, quizá le tenemos que dar una oportunidad a Docker, tecnología que nos permite aislar nuestro entorno de trabajo de nuestras máquinas, haciendo que nuestros desarrollos sean más portables.

Arquitectura Docker, fuente: [XenonStack]

Debido a que hay muchos caminos para aprender esto sugiero que nuestro punto de inicio considere lo siguiente:

  1. Este [video de 12 minutos], que si bien es cierto está en inglés, lo explica todo de una forma tan sencilla que hasta te da ganas de entrar a la línea de comandos y empezar a trabajar 🙂
  1. Este [tutorial que explica paso a paso] lo mínimo indispensable de Docker y este [con una explicación sencilla] de cómo crear una aplicación real 🙂
  1. La [documentación oficial], si bien es cierto fue una de las primeras cosas que revisé cuando empecé a experimentar con Docker, les recomiendo que primero revisen los dos puntos anteriores luego de jugar un poco sigan los ejemplos recomendados en su sección [get-started]
  1. (Bonus) Si por algún motivo, razón o circunstancia (jaja, esa frase es lo máximo) no pueden instalar Docker en sus máquinas, pueden practicar en [este lab]. Para ello solo necesitan una cuenta en Docker y listo 🙂
Play with docker, fuente: archivo personal

Espero que estos recursos sean de utilidad, por mi parte pondré en mis pendientes traducir los tutoriales del punto #2, me parecen muy buenos y creo que con eso eliminaríamos la barrera del lenguaje. Ahora, si alguno ya empezó o se anima a hacerlo, bienvenido sea!

Un abrazo,

10 aspectos a considerar si te interesa la arquitectura de software

Hace mucho que esta idea ronda por mi cabeza:

¿Qué necesito para ser un arquitecto?

Creo que es la consecuencia de tantas conversaciones con mis amigos o conocidos en eventos de tecnología.

Por mi parte –como apreciación personal– les comparto que he tenido la suerte de haber trabajado como arquitecto en más de un proyecto de tecnología y que este tipo de experiencias me ha ayudado a diferenciar entre las funciones que debería realizar un arquitecto y encontrarme con algunos malosentendidos a consecuencia del rol.

Consecuencias de una mala arquitectura
[Code Complete, Steve McConnell, 2004]

Con “malentendidos” me refiero a que me he topado con frases como “nuestro proyecto no necesita un arquitecto” o “ese rol no debería existir” o “los arquitectos no saben programar”, y la verdad es que, así como hay buenos profesionales, también los hay de aquellos que no saben hacer bien su trabajo y que por lo general son los responsables de muchos inconvenientes.

Lo bueno de estas experiencias es que –casi siempre– logramos conseguir –gracias a la apertura del equipo con el que estaba– que el trabajo se pueda realizar de manera exitosa.

En fin, desde mi perspectiva, creo que cada rol existe gracias a una necesidad en particular y de ser así, debería cumplir con algunos criterios fundamentales. El rol del arquitecto no es una excepción, así que he preparado algunos aspectos que me gustaría compartir con ustedes:

1. Saber programar: No hay que ser un experto en programación pero es importante contar con la experiencia suficiente para entender el código del equipo de trabajo, hablar su idioma y claro, participar en los code review.

2. Enseñar con el ejemplo: Si bien es cierto este es un criterio básico de liderazgo, aquí se debe reforzar a nivel técnico, pues todo diseño o presentación debe ir acompañado con código de ejemplo. Sí, con esto me refiero a “la demo” y claro está, no tiene que ser algo completamente funcional pero debe demostrar la factibilidad de nuestra propuesta.

3. Conceptualizar: Esta capacidad será complicada de adquirir si creemos que un arquitecto tiene que ser un programador con mucha experiencia. La clave para acortar el camino, es dejar dejar de pensar en líneas de programación para hacerle un espacio a los componentes y sus tipos de integración.

4. Ser estratégico: Lo “fácil” de esto, es diseñar soluciones flexibles (fáciles de modificar o extender). Lo complicado viene cuando olvidamos los objetivos del negocio y sus respectivas restricciones. Esto implica que tengamos la facilidad de conversar tanto técnicamente, como en términos del giro del negocio. Luego de superar esta barrera, debemos proyectar lo que podría ocurrir en el futuro.

5. Presentar efectivamente: Como regla general, toda propuesta de arquitectura debe ser concreta, de fácil entendimiento y claro, con una “demo” que evidencie la factibilidad de nuestro trabajo. Esto pasa a segundo plano cuando tenemos que enfocarnos en ser concretos y convincentes al momento de explicar nuestras ideas.

6. Ser humilde: Debemos eliminar cualquier tipo de barrera a consecuencia del “poder que llevas por tener este rol”. Una forma de acortar distancias es dejar el ego a un lado para escuchar sugerencias, aceptar nuestros errores y si se da el caso, pedir disculpas de la única forma en la que se deberían pedir, con honestidad y sin condiciones.

7. Estudiar y poner en práctica: Además de reforzar nuestros soft skills, necesitamos entender la importancia de la [construcción de software], la [programación orientada a objetos], los beneficios del [código limpio], comprender los [patrones de diseño], averiguar sobre los [tipos de arquitectura] que existen en el mercado, las [nuevas tendencias de arquitectura] y claro, debemos [programar] en nuestros ratos libres.

8. Leer: Los líbros técnicos tienen que ser algo normal en nuestras vidas, pero también debemos incluir cualquier otro tipo de lecturas. El tópico queda a nuestra elección.

9. Preguntarnos ¿qué más podríamos hacer? Esto aplica al diseño en el que estamos trabajando, pero tiene más sentido cuando lo revisamos en nuestra vida profesional (pues lo natural es que evolucionemos a arquitectos empresariales) y ¿por qué no? también deberíanos hacernos la pregunta a nivel personal.

10. Sentido común: Yo creo que esto es algo que se puede entrenar y que podría tomar más tiempo del que pensamos, no por algo dicen que termina siendo “el menos común de los sentidos”. Pero no nos desanimemos, tomemos un momento para respirar y revisar si estamos construyendo un [homeromóvil] cuando lo que realmente necesitamos es algo tan simple como un skate.

Desde un punto de vista netamente personal, creo que cada aspecto tiene muchos requisitos y restricciones que se deben ir superando en el camino y si llega el momento en el que te das cuenta de que no te estás divirtiendo, pues es posible que tengas revisar otra vez si te gusta lo que estás buscando, o mejor aún, no presionarte pues nadie es perfecto y menos, un excelente arquitecto.

Un abrazo, JD

new beta release in process