miércoles, 15 de noviembre de 2017

30 Días de Diseño - Un Caso de Estudio de Marca

Hay varios aspectos importantes a tener en cuenta cuando se trabaja con clientes: cumplir las expectativas y los plazos, por mencionar sólo algunos. En algún momento de la carrera de cada diseñador vendrá un cliente que tiene una urgencia apremiante con su proyecto. Estos son los proyectos que enseñan el arte de cumplir con los plazos y lo loco que puede llegar a ser.
Normalmente hay dos tipos de proyectos que cada diseñador encontrará durante tu carrera profesional: “Necesito un diseño centrado en el usuario que se corresponda con mi proyecto, sin plazos estrictos. Sólo quiero la mejor solución”. Y ese es el sueño de todo diseñador, pero enfrentémoslo: en realidad las cosas siempre son más desafiantes.
“Quiero una solución innovadora, creativa y fuera de lo común: un buen UX, una interfaz de usuario realmente agradable…y la necesito ayer”.
Entonces, ¿qué sucede cuando te das cuenta de que hay 30 días para crear un logotipo y diseñar los principales elementos de la marca, un sitio web, interfaces de usuario móviles y anuncios o gráficos en las redes sociales?
Después de tener un pequeño ataque de pánico, te das cuenta de que trabajar de manera inteligente es la única manera de hacerlo. Elaborar un plan y pensar las cosas de antemano te ayudará con la productividad, la precisión y la calidad del diseño. Al igual que con cualquier esfuerzo exitoso, el trabajo arduo y las largas horas son algunas de las condiciones obligatorias para hacerlo realidad.
No importa qué, siempre hay estas preguntas insoportables:
  • ¿Vale la pena hacerlo con tales restricciones de tiempo?
  • ¿Las limitaciones de tiempo llevarán a una mala calidad de diseño?
  • ¿Haría un mejor trabajo si tuviera más tiempo?
¡Absolutamente, sí!
Al igual que con cualquier proyecto, siempre hay aspectos positivos, desventajosos y limitaciones que, como diseñadores, debemos encontrar un camino e incluso utilizar a nuestro favor para llegar a soluciones creativas.
Tener una idea clara de las tareas que se deben cumplir para completar con éxito el proyecto es clave, así como también diplomáticamente dejar que el cliente sepa que el breve plazo podría tener un impacto negativo en la calidad del diseño en general. Sin embargo, la presión de una fecha límite aplastante no es una excusa para no dar lo mejor de sí mismo en tu oficio, utilízalo para forzarte a entregar el mejor trabajo posible. Un estudio hecho por la Escuela de Negocios de Harvard sobre el trabajo creativo realizado bajo presión de tiempo concluyó que:
_ “Este estudio sugiere que los gerentes tomen medidas para proteger el tiempo para que los empleados participen en el procesamiento cognitivo creativo, particularmente aquellos empleados cuyo trabajo requiere un alto grado de creatividad. […] Es muy probable que las ideas creativas no ser producido en ausencia total de cualquier presión de tiempo, ya sea autoimpuesto o impuesto externamente “.
Estos hallazgos indican que un gran grado de presión puede funcionar en contra del trabajo creativo, pero al mismo tiempo, el estudio también sugiere que un nivel razonable de presión con respecto al trabajo creativo puede ser útil para ayudar a producir mejores diseños.
Siempre es un desafío hacer todo mientras trabajas como profesional independiente con múltiples proyectos activos, ¡pero es una gran oportunidad para ser diligente con tu agenda y hacer que tu tiempo limitado trabaje para ti! Hacer que el trabajo remoto funcione para ti es simple, pero no fácil. Combina esto con un plan sólido, y tendrás una receta para el éxito.

Día 1-3: Lo primero es lo primero — ¡Planifica!

El primer paso es dividir el proyecto en partes más pequeñas y calcular cuánto tiempo tomará terminar cada etapa del proyecto. Establecer metas aumenta la motivación y el logro. La ciencia del logro de los objetivosrecomienda desglosar tu gran objetivo en pasos de acción claros y definidos. Al hacerlo, obtendrás un gran ventaja en tus esfuerzos para lograrlo.
Con respecto al diseño de marca, una buena práctica es crear varias versiones del diseño para que el cliente tenga diferentes opciones para elegir. Mi preferencia personal es crear tres iteraciones de diseños de logotipos y elementos principales de la marca, como tipografía, paletas de colores, imágenes y conjuntos de iconos. Hacer esto primero te permitirá llevar el concepto y las ideas visuales al próximo paso.
Crear procesos de trabajo y seguirlos.
La creación de procesos de trabajo facilitará el flujo de trabajo y la responsabilidad que conlleva cada proyecto. El siguiente es mi enfoque habitual para un proyecto de diseño típico, ya sea diseño de marca o de interfaz de usuario:

Investigación

Descubre todo sobre el negocio de tu cliente:
  • ¿Cuál es el núcleo de su negocio y cuál es su principal actividad?
  • ¿Quién es su público objetivo y cuáles son sus necesidades?
  • ¿Cuáles son sus objetivos y qué problema debe ser resuelto mediante el diseño?
  • ¿Quién es la competencia y cómo puedes ser mejor?
Un cuestionario o resumen de diseño es una de las maneras más convenientes y eficientes de recopilar la información antes mencionada.

Crear un Mood board

Una de las cosas que puedes usar para crear un mood board es crear el concepto — una parte esencial de cualquier proyecto. Toma una perspectiva más amplia: toma toda tu investigación y ponla en un lienzo grande para que puedas ver todos los elementos que deberían incorporarse en los diseños. Hay varios herramientas gratis que lo ayudan a crear mood boards fácilmente.
Si no te gustan las herramientas en línea, usar Adobe Illustrator funciona bien ya que puede crear, agregar y mover elementos libremente. Piensa en ello como un collage — no te preocupes demasiado por el posicionamiento de los detalles, eres libre de organizar todo a tu gusto. El objetivo principal es ver cómo los colores, las fotos, los íconos, la tipografía, etc. trabajan entre sí visualmente y en la narración de historias.
Representación visual de un mood board
Los mood boards son muy fáciles de hacer y te ayudarán a mostrar tu idea.

Día 3: Crea un concepto de diseño

Crear un concepto es el siguiente paso después de completar tu mood board y es la base de todo tu futuro trabajo. Un concepto se produce como un modelo experimental para probar la viabilidad de las características de diseño.
Un mood board será útil para establecer una dirección visual temprana que corresponda a la audiencia a la que se dirige y los objetivos del negocio. El concepto será la base de tu dirección de UX y, por lo tanto, forma parte de Los 10 Mejores Entregables de UX .
Es necesario apreciar la importancia de este paso porque un concepto sólido ayuda a volver a contar una historia convincente, incluso durante las primeras etapas del proyecto. El enfoque principal debe tener en cuenta los sentimientos y las experiencias que los usuarios encuentran al tratar con los elementos visuales en lugar de los visuales en sí mismos.
Uno de los consultores de marketing más influyentes de la industria y oradores motivadores, Simon Sinek, dio una charla TED brillante sobre este tema.
El mood board puede ayudarte a crear algunos eslóganes cortos o tal vez a establecer estilos de iconos y fotografías en un concepto. Ya que es bueno tener una tipografía que se pueda leer rápidamente independientemente del medio, también es importante considerar la tipografía amigable con la impresión y la web. Este es un elemento clave del gran diseño y también es uno de los principios considerados por prácticas de diseño universales.

Día 4: Diseña los Visuales de Marca

El proceso de creación de marca puede volverse tedioso y lento si se lo detecta siguiendo el enfoque equivocado desde el principio. Comenzar creando iteraciones de logotipo se hace mejor una vez que tienes un concepto aprobado, y los archivos de guía visual están listos. Esto te dará la confianza de que te estás moviendo en la dirección correcta, y te permitirá abordar los desafíos de la marca de una manera inteligente y eficiente en el tiempo.
Es esencial hacer pequeños bocetos de lápiz y papel de tus ideas de diseño primero. Tomará menos tiempo si primero dibujas y luego avanzas a Illustrator, Sketch, etc. para trabajar en tu logotipo. Este paso me ha ayudado a diseñar tres propuestas de logotipo diferentes que están todas en la dirección visual elegida para la marca. Esto tomó algunos días para terminar:
Estudio de caso de marca: ejemplos de logotipo
Puede haber algunos cambios y ajustes adicionales en el diseño del logotipo, pero una vez que el cliente haya decidido el logotipo y aprobado otros elementos como colores, tipografía, iconos y estilo de fotografía, habrás terminado con los elementos de marca básicos.

Día 7-15: Diseño del sitio web

El desarrollo de la marca incluye más que solo el logotipo: cubre casi todos los aspectos del diseño, incluido el sitio web. Comenzar primero con el sitio web puede ser útil, ya que puedes agregar al concepto visual aplicando reglas visuales y viendo cómo funcionan juntas. Esto es particularmente cierto cuando estás creando un sitio web que tiene un objetivo final y elementos similares a la aplicación móvil.

Mapa del sitio

Un mapa del sitio es una lista de páginas de un sitio web al que pueden acceder los rastreadores o los usuarios. Puede ser un documento que se utiliza como una herramienta de planificación para el diseño web o una página que muestra las páginas de un sitio web de forma jerárquica.
Es una gran ayuda si un cliente ya tiene un mapa del sitio porque le da una vista clara de todas las páginas que pertenecen a un sitio web. Si se le adjudica un proyecto donde se necesita un mapa del sitio, tendrá que trabajar con el cliente para armar uno.
Esto podría significar hacerle algunas preguntas a tu cliente:
  • ¿Cuál es el número de páginas en el sitio web?
  • ¿Qué páginas son las más importantes?
  • ¿Hay alguna subpágina?
Esto te dará una idea clara de la estructura del sitio web y ofrecerá una buena idea del alcance del proyecto.

La información primero

Me resulta útil pedirle al cliente por adelantado que me brinde toda la información y el contenido que desea incluir en el sitio. Es una buena práctica hacer que el diseño funcione alrededor del contenido en lugar de crear primero la UI e intentar hacer que el contenido quepa después.
El primer enfoque de copia te ahorra a ti y a los desarrolladores mucho tiempo. Si vas al revés, podrías encontrar problemas. Si bien es útil a veces, el uso de texto ficticio puede afectar negativamente a un proyecto real, especialmente cuando el diseño se basa en gran medida en la tipografía y está diseñado en torno al contenido. Un diseño centrado en la copia no tiene inconvenientes y solo ayuda a realizar trabajos creativos de calidad excepcional.

Diseño de página de inicio

Al seguir todos los pasos anteriores, ya tienes pautas visuales generales, un mapa del sitio y copia. Ahora puede continuar diseñando las páginas para el sitio web.
La página de inicio es lo primero que ven los usuarios cuando visitan un sitio web y, por lo tanto, es la página más importante. Al aplicar el Principio de Pareto se demuestra que la página de inicio posee el 80% de la dirección de diseño (contexto, tipografía, colores, elementos repetibles, etc.) y el resto de las páginas un 20%.
Es una buena idea comenzar tu proceso agrupando y seleccionando secciones para la página de inicio. El contenido completo y la copia generalmente me ayudan a organizar toda la página y ver qué aspectos faltan, así como las secciones que se podrían agregar para maximizar el impacto e impulsar a los usuarios a comprar/usar el producto o servicio.
Representación visual de la página de inicio de un sitio web
Se valiente en tus sugerencias para el cliente. Explica que los plazos implican ciertas limitaciones.
Para enfatizar el servicio o producto, intente usar secciones prominentes de llamada a la acción. Son una excelente manera de publicitar y captar la atención de los usuarios para comprar un producto, suscribirse a un boletín informativo, registrarse, etc. Si la tecnología, el público objetivo y el tipo de negocio del cliente lo permiten, agregar un diseño de movimiento como GIF o animación puede dar lugar a todo el subcontexto del sitio, así como a enfatizar la sección de llamado a la acción. Sin embargo, los diseñadores deben tener cuidado de no ir demasiado lejos y crear algo que les lleve mucho tiempo desarrollar.

Día 15-25: Aplicar el diseño universal

El diseño universal, según lo describen sus desarrolladores, “se puede aplicar para evaluar diseños existentes, guiar el proceso de diseño y educar tanto diseñadores como consumidores sobre las características de productos y entornos más utilizables”.
El concepto de diseño universal es una de las soluciones más óptimas para usar cuando se trata de un proyecto de gran alcance: un concepto unificado y una dirección visual enfocada para la marca, el sitio web y las aplicaciones móviles es de gran beneficio cuando se diseñan bajo restricciones de tiempo.
La necesidad de elementos repetitivos puede ser un desafío en sí mismo. Esto sucede cuando encuentras requisitos técnicos. El sitio web receptivo y las plataformas móviles tienen una filosofía y un conjunto de reglas completamente diferentes y, por lo tanto, pueden convertirse en un problema si no se abordan de manera adecuada. Sin embargo, la creación de elementos que se pueden utilizar en múltiples plataformas es uno de los pilares del éxito de cualquier proyecto; en esta circunstancia particular, no habría sido posible cubrir tantas plataformas/dispositivos sin un diseño unificado que establezca claramente la dirección para el desarrollo de la marca
Representación visual de una interfaz de aplicación de iOS
La desventaja de una fecha límite ajustada y el diseño de múltiples plataformas es que es posible que no estés utilizando todo el potencial de cada una de las plataformas para las que estás diseñando. En tales casos, debido a la limitación de tiempo, una solución “a prueba de balas” que sea familiar para la base de usuarios podría ser una idea valiosa.
Por ejemplo: vuelve a aplicar una idea en varias páginas y remodela para cada dispositivo. Los patrones son similares en esencia, lo cual está a tu favor. Podría ser en la forma en que muestra información esencial o invita a los usuarios a comprar un producto. En este caso, incluso una barra de búsqueda podría ser similar si no es la misma.

Diagrama de flujo

El diseño del sitio web está hecho y tú tienes una visión más clara del UX para las aplicaciones. Una de las formas en que puedes hacer que el proceso de creación de UX sea más fácil y claro es crear un diagrama de flujo de usuario.
Representación visual de un diagrama de flujo detallado
El diagrama de flujo explica las conexiones entre las páginas y muestra cómo los usuarios interactuarán con la aplicación.
Hay varios métodos y herramientas que puedes usar para crear diagramas de flujo — la práctica habitual es hacer diagramas gráficos con títulos cortos y, si es necesario, texto explicativo. Usar Sketch o Illustrator para esto es mi preferencia, pero cualquier herramienta que te permita crear y mover elementos está bien para esta tarea.
Will Little ha dado una gran interpretación de esto:
“Aquí es donde los ingenieros y creativos deben trabajar en estrecha colaboración para decidir qué tipo de herramientas de software pueden soportar mejor las interfaces y el comportamiento de clic/deslizamiento, hasta la última pestaña, información sobre herramientas, lightbox, icono , etc.”.

Hazlo alto al hacerlo bajo

Descubrir el propósito principal de la aplicación ayudará a definir el UX. Eso podría ayudar a un usuario a comprar un producto, o quizás ayudarlo a usar un producto, la experiencia del usuario debe adaptarse a eso. Los wireframes de baja fidelidad creados en papel y luego llevados a una mayor fidelidad en Sketch o Photoshop pueden facilitar el proceso considerablemente.
Wireframes de alta fidelidad para una aplicación de Android
Cada proyecto es diferente, y en ocasiones será necesario crear wireframes de alta fidelidad.
En este caso, los wireframes de baja fidelidad eran suficientes ya que la aplicación es simple y solo se necesita seguir los detalles visuales del sitio web.
Si es posible, organiza una pequeña prueba para tu UX. Necesitarás un grupo de prueba de futuros usuarios para ver si los wireframes y el flujo de UX tienen sentido. Después de la prueba, contarás con información valiosa y puedes continuar con el siguiente paso (crear una interfaz de usuario).

Diseño unificado

Después de realizar algunos ajustes en el UX, tienes todo lo que necesitas para crear una interfaz de usuario lógica y bien definida, lo que te permite ajustarla a los requisitos visuales de las plataformas iOS y Android. Dado que iOS tiene algunas pautas de diseño muy específicas que pueden evitar que ingreses en la App Store de Apple, debes conocer esas reglas y verificar cuidadosamente cómo se está implementando tu diseño durante la etapa de desarrollo.
Interfaces de usuario para una aplicación de Android
Puedes crear un diseño unificado para ambas plataformas, iOS y Android, y al mismo tiempo utilizar sus mayores fortalezas siguiendo las pautas y reglas al diseñar la interfaz de usuario.

Día 25-30: Crear anuncios en sincronización con la marca

En este punto, debes haber diseñado un logotipo, elementos de marca, un sitio web y aplicaciones móviles. Aunque lo diseñaste todo en menos de 25 días, es demasiado pronto para celebrar, ya que todavía hay un paso más a considerar: crear anuncios para redes sociales y piezas impresas. Aquí es donde el concepto que creó al principio será de gran ayuda.
Seguir estos consejos cuando diseñe anuncios y materiales de redes sociales mejorará en gran medida la calidad, los niveles de participación y la creatividad general de sus imágenes:
  • Haz uso de colores vivos y brillantes que se destacan.
  • Mostrar personas felices y activas ayuda con la dinámica y los sentimientos sobre tus gráficos.
  • El movimiento, la actividad y la emoción de las personas siempre atrae la atención y ayuda con los sentimientos transmitidos en general.
Todas estas reglas te ayudarán a crear gráficos excepcionales para publicidades. Si corresponde, usa la paleta de colores, la tipografía y otros elementos visuales que hayas utilizado en tu sitio web, marca y aplicaciones. Esto te ayudará a ser consistente en tus diseños y trabajará a su favor cuando trabajes bajo restricciones de tiempo.
Representación visual de anuncios y gráficos de redes sociales
Tus resultados deben corresponder a la dirección visual general del proyecto.

Nunca te comprometas a una fecha límite que no puedes cumplir

En ocasiones, cualquiera puede subestimar la cantidad de esfuerzo y trabajo que un proyecto puede tomar, por eso planificar cada paso es crucial al comienzo de un proyecto. Los objetivos y las metas realistas divididos en partes pequeñas son fundamentales para entregar un trabajo sólido a tiempo.
Benjamin Franklin lo expresó mejor: “Al no prepararse, te estás preparando para fracasar”.
En todo momento, nunca dejes de prepararte, y nunca dejes de anticipar la posibilidad de que haya subestimado el trabajo en términos del tiempo requerido para entregarlo. Aunque los clientes pueden tener fechas límites, tú debes tener las habilidades que te ayudarán a determinar si un proyecto es factible o incluso vale la pena considerarlo en primer lugar. Sin embargo, no permitas que esto sea una excusa para que no acepte un desafío personal que, en última instancia, podría ayudarte a ser un diseñador y gerente más hábil de tu tiempo.

Este articulo fue escrito por Ivona Petrovic. Originalmente publicado en Toptal.

miércoles, 8 de noviembre de 2017

Creando Código Verdaderamente Modular sin Dependencias

El desarrollo de software es genial, pero… Creo que todos podemos estar de acuerdo en que puede ser una montaña rusa emocional. Al principio, todo es genial. Agrega nuevas características una tras otra en cuestión de días, si no de horas. ¡Estás en racha de suerte!
Avancemos rápido unos meses, y tu velocidad de desarrollo disminuye. ¿Es porque no estás trabajando tan duro como antes? Realmente no. Avancemos unos meses más y tu velocidad de desarrollo disminuirá aún más. Trabajar en este proyecto ya no es divertido y se ha convertido en un lastre.
Una representación abstracta del diseño de código modular
Pero se pone peor. Empiezas a descubrir múltiples errores en tu aplicación. A menudo, resolver un error crea dos nuevos. En este punto, puedes comenzar a cantar:
99 pequeños errores en el código.
99 pequeños errores.
Toma uno, ponle un parche,
…127 pequeños errores en el código.
¿Cómo te sientes al trabajar en este proyecto ahora? Si eres como yo, probablemente comiences a perder tu motivación. Desarrollar esta aplicación es complicado, ya que cada cambio en el código existente puede tener consecuencias impredecibles.
Esta experiencia es común en el mundo del software y puede explicar por qué tantos programadores quieren descartar su código fuente y volver a escribir todo.

Razones por las Cuales el Desarrollo de Software se Ralentiza con el Tiempo

Entonces, ¿cuál es la razón de este problema?
La causa principal es la creciente complejidad. Desde mi experiencia, el mayor contribuyente a la complejidad general es el hecho de que, en la gran mayoría de los proyectos de software, todo está conectado. Debido a las dependencias que tiene cada clase, si cambia algún código en la clase que envía correos electrónicos, sus usuarios de repente no pueden registrarse. ¿Por qué es eso? Porque su código de registro depende del código que envía los correos electrónicos. Ahora no puedes cambiar nada sin introducir errores. Simplemente no es posible rastrear todas las dependencias.
Entonces ahí lo tienes; la verdadera causa de nuestros problemas es aumentar la complejidad proveniente de todas las dependencias que tiene nuestro código.

La Gran Pelota de Barro y Cómo Reducirla

Lo curioso es que este problema se conoce desde hace años. Es un antipatrón común llamado la “gran bola de barro”. He visto ese tipo de arquitectura en casi todos los proyectos en los que trabajé a lo largo de los años en múltiples compañías diferentes.
Entonces, ¿qué es este antipatrón exactamente? Simplemente hablando, obtienes una gran bola de barro cuando cada elemento tiene una dependencia con otros elementos. A continuación, puede ver un gráfico de las dependencias del conocido proyecto de código abierto Apache Hadoop. Para visualizar la gran bola de barro (o más bien, la gran bola de hilo), dibuja un círculo y coloca las clases del proyecto de manera uniforme en él. Solo trace una línea entre cada par de clases que dependen el uno del otro. Ahora puedes ver la fuente de tus problemas.
Una visualización de la "gran bola de barro" de Apache Hadoop
La "gran bola de barro" de Apache Hadoop

Una Solución con Código Modular

Entonces me hice una pregunta: ¿sería posible reducir la complejidad y aún divertirme como al comienzo del proyecto? A decir verdad, no puedes eliminar todos la complejidad. Si desea agregar nuevas características, siempre tendrá que aumentar la complejidad del código. Sin embargo, la complejidad puede moverse y separarse.

Cómo otras Industrias están Resolviendo este Problema

Piensa en la industria mecánica. Cuando un pequeño taller mecánico crea máquinas, compra un conjunto de elementos estándar, crea algunos personalizados y los combina. Pueden hacer esos componentes completamente por separado y ensamblar todo al final, haciendo solo algunos retoques. ¿Cómo es esto posible? Saben cómo cada elemento se ajustará según los estándares de la industria, como el tamaño de los pernos, y las decisiones iniciales como el tamaño de los orificios de montaje y la distancia entre ellos.
Un diagrama técnico de un mecanismo y cómo encajan sus piezas
Cada elemento en el conjunto anterior puede ser proporcionado por una empresa independiente que no tiene ningún conocimiento sobre el producto final o sus otras piezas. Siempre que cada elemento modular se fabrique de acuerdo con las especificaciones, podrá crear el dispositivo final según lo planeado.
¿Podemos replicar eso en la industria del software?
¡Seguro que podemos! Mediante el uso de interfaces y la inversión del principio de control; la mejor parte es el hecho de que este enfoque se puede utilizar en cualquier lenguaje orientado a objetos: Java, C #, Swift, TypeScript, JavaScript, PHP — la lista sigue y sigue. No necesita ningún marco elegante para aplicar este método. Solo debe apegarse a algunas reglas simples y mantenerse disciplinado.

La inversión del Control es tu Amigo

Cuando escuché por primera vez sobre la inversión del control, inmediatamente me di cuenta de que había encontrado una solución. Es un concepto de tomar dependencias existentes e invertirlas mediante el uso de interfaces. Las interfaces son simples declaraciones de métodos. No proporcionan ninguna implementación concreta. Como resultado, se pueden usar como un acuerdo entre dos elementos sobre cómo conectarlos. Se pueden usar como conectores modulares, si se quiere. Mientras un elemento proporcione la interfaz y otro elemento proporcione la implementación, pueden trabajar juntos sin saber nada el uno del otro. Es brillante.
Veamos en un ejemplo simple cómo podemos desacoplar nuestro sistema para crear código modular. Los diagramas siguientes se han implementado como simples aplicaciones Java. Puede encontrarlos en este repositorio de GitHub.

Problema

Supongamos que tenemos una aplicación muy simple que consiste solo en una clase Main, tres servicios y una sola clase Util. Esos elementos dependen el uno del otro de múltiples maneras. A continuación, puede ver una implementación usando el enfoque de “gran bola de barro”. Las clases simplemente se llaman entre sí. Están estrechamente unidos, y no se puede simplemente sacar un elemento sin tocar a los demás. Las aplicaciones creadas con este estilo le permiten crecer inicialmente rápidamente. Creo que este estilo es apropiado para proyectos de prueba de concepto, ya que puedes jugar con facilidad. Sin embargo, no es apropiado para soluciones listas para producción porque incluso el mantenimiento puede ser peligroso y cualquier cambio puede crear errores impredecibles. El siguiente diagrama muestra esta gran bola de arquitectura de barro.
Un diagrama simple de la arquitectura de estilo "gran bola de barro"

¿Por Qué la Inyección de Dependencia lo Hizo Todo Mal?

En una búsqueda de un mejor enfoque, podemos usar una técnica llamada inyección de dependencia. Este método supone que todos los componentes se deben usar a través de interfaces. He leído afirmaciones de que desacopla elementos, pero ¿realmente lo hace? No. Echale un vistazo al diagrama a continuación.
Un diagrama de inyección de dependencia agregado a la gran bola de barro
La única diferencia entre la situación actual y una gran bola de barro es el hecho de que ahora, en lugar de llamar directamente a las clases, las llamamos a través de sus interfaces. Mejora ligeramente los elementos de separación entre sí. Si, por ejemplo, desea reutilizar Servicio A en un proyecto diferente, puede hacerlo sacando Servicio A, junto con Interfaz A, así como Interfaz B y Interface Útil. Como puede ver, el Servicio A todavía depende de otros elementos. Como resultado, todavía tenemos problemas para cambiar el código en un lugar y desordenar el comportamiento en otro. Todavía crea el problema de que si modifica Servicio B e Interfaz B, necesitará cambiar todos los elementos que dependen de él. Este enfoque no resuelve nada; en mi opinión, solo agrega una capa de interfaz sobre los elementos. Nunca debe inyectar dependencias, sino que debe deshacerse de ellas de una vez por todas. ¡Hurra por la independencia!

La Solución Para el Código Modular

El enfoque que creo que resuelve todos los principales dolores de cabeza de las dependencias lo hace al no usar dependencias en absoluto. Tú creas un componente y su oyente. Un oyente es una interfaz simple. Siempre que necesites llamar a un método desde fuera del elemento actual, simplemente agrega un método al oyente y llámelo en su lugar. El elemento solo tiene permitido usar archivos, llamar a métodos dentro de su paquete y usar clases proporcionadas por el marco principal u otras bibliotecas usadas. A continuación, puedes ver un diagrama de la aplicación modificada para usar la arquitectura de elementos.
Un diagrama de la aplicación modificada para usar la arquitectura de elementos
Ten en cuenta que, en esta arquitectura, solo la clase Main tiene múltiples dependencias. Conecta todos los elementos y encapsula la lógica de negocios de la aplicación.
Los servicios, por otro lado, son elementos completamente independientes. Ahora, puedes sacar cada servicio de esta aplicación y reutilizarlos en otro lugar. No dependen de nada más. Pero espera, se pone mejor: no necesitas modificar esos servicios nunca más, siempre y cuando no cambie su comportamiento. Mientras esos servicios hagan lo que se supone que deben hacer, pueden dejarse intactos hasta el final de los tiempos. Pueden ser creados por un ingeniero profesional de software, o un codificador por primera vez comprometido con el peor código de espagueti que alguien haya cocinado con declaraciones de gotomezcladas. No importa, porque su lógica está encapsulada. Por horrible que sea, nunca se extenderá a otras clases. Eso también le da el poder de dividir el trabajo en un proyecto entre múltiples desarrolladores, donde cada desarrollador puede trabajar en su propio componente de forma independiente sin la necesidad de interrumpir otro o incluso saber sobre la existencia de otros desarrolladores.
Finalmente, puedes comenzar a escribir código independiente una vez más, al igual que al comienzo de tu último proyecto.

Element Pattern

Definamos el patrón del elemento estructural para que podamos crearlo de manera repetible.
La versión más simple del elemento consta de dos cosas: una clase de elemento principal y un oyente. Si deseas usar un elemento, entonces necesitas implementar el oyente y realizar llamadas a la clase principal. Aquí hay un diagrama de la configuración más simple:
Un diagrama de un solo elemento y su oyente dentro de una aplicación
Obviamente, necesitarás agregar más complejidad en el elemento eventualmente, pero puedes hacerlo fácilmente. Solo asegúrate de que ninguna de tus clases de lógica dependa de otros archivos en el proyecto. Solo pueden usar el marco principal, las bibliotecas importadas y otros archivos en este elemento. Cuando se trata de archivos de activos como imágenes, vistas, sonidos, etc., también deben estar encapsulados dentro de los elementos para que en el futuro sean fáciles de reutilizar. ¡Simplemente puedes copiar la carpeta completa a otro proyecto y allí está!
A continuación, puedes ver un gráfico de ejemplo que muestra un elemento más avanzado. Ten en cuenta que consiste en una vista que está usando y no depende de ningún otro archivo de aplicación. Si deseas conocer un método simple para verificar dependencias, solo mire la sección de importación. ¿Hay algún archivo desde fuera del elemento actual? De ser así, debes eliminar esas dependencias moviéndolas al elemento o agregando una llamada apropiada al oyente.
Un diagrama simple de un elemento más complejo
Echemos un vistazo a un ejemplo simple de “Hello World” creado en Java.
public class Main {

  interface ElementListener {
    void printOutput(String message);
  }

  static class Element {

    private ElementListener listener;

    public Element(ElementListener listener) {
      this.listener = listener;
    }

    public void sayHello() {
      String message = "Hello World of Elements!";
      this.listener.printOutput(message);
    }
  }

  static class App {

    public App() {
    }

    public void start() {

      // Build listener
      ElementListener elementListener = message -> System.out.println(message);

      // Assemble element
      Element element = new Element(elementListener);
      element.sayHello();
    }
  }

  public static void main(String[] args) {
    App app = new App();
    app.start();
  }
}
Inicialmente, definimos ElementListener para especificar el método que imprime la salida. El elemento en sí se define a continuación. Al llamar a sayHello en el elemento, simplemente imprime un mensaje usandoElementListener. Ten en cuenta que el elemento es completamente independiente de la implementación del método printOutput. Se puede imprimir en la consola, una impresora física o una interfaz de usuario elegante. El elemento no depende de esa implementación. Debido a esta abstracción, este elemento se puede reutilizar fácilmente en diferentes aplicaciones.
Ahora echale un vistazo a la clase principal de App. Implementa el oyente y ensambla el elemento junto con la implementación concreta. Ahora podemos comenzar a usarlo.

Arquitectura de Elemento

Echemos un vistazo al uso del patrón de elementos en aplicaciones a gran escala. Una cosa es mostrarlo en un proyecto pequeño; otra es aplicarlo al mundo real.
La estructura de una aplicación web de pila completa que me gusta usar se ve de la siguiente manera:
src
├── client
│   ├── app
│   └── elements
│   
└── server
    ├── app
    └── elements
En una carpeta de código fuente, inicialmente dividimos los archivos del cliente y del servidor. Es algo razonable de hacer, ya que se ejecutan en dos entornos diferentes: el navegador y el servidor de fondo.
Luego dividimos el código en cada capa en carpetas llamadas aplicaciones y elementos. Los elementos constan de carpetas con componentes independientes, mientras que la carpeta de la aplicación conecta todos los elementos y almacena toda la lógica comercial.
De esta forma, los elementos se pueden reutilizar entre diferentes proyectos, mientras que toda la complejidad específica de la aplicación se encapsula en una sola carpeta y con frecuencia se reduce a simples llamadas a elementos.

Ejemplos Prácticos

Si creemos que la práctica siempre prevalece sobre la teoría, echemos un vistazo a un ejemplo de la vida real creado en Node.js y TypeScript.
Es una aplicación web muy simple que puede usarse como punto de partida para soluciones más avanzadas. Sigue la arquitectura del elemento y utiliza un patrón de elementos extensivamente estructural.
A partir de los aspectos más destacados, puede ver que la página principal se ha distinguido como un elemento. Esta página incluye su propia vista. Entonces, cuando, por ejemplo, deseas reutilizarlo, puede simplemente copiar la carpeta completa y soltarla en un proyecto diferente. Simplemente conecta todo y estarás listo.
Es un ejemplo básico que demuestra que puede comenzar a introducir elementos en su propia aplicación hoy. Puedes comenzar a distinguir componentes independientes y separar su lógica. No importa cuán desordenado sea el código en el que esté trabajando actualmente.

¡Desarrollar más rápido, reutilizar más a menudo!

Espero que, con este nuevo conjunto de herramientas, puedas desarrollar más fácilmente código que sea más fácil de mantener. Antes de saltar al uso del patrón de elementos en la práctica, repasemos rápidamente todos los puntos principales:
  • Se producen muchos problemas en el software debido a las dependencias entre varios componentes.
  • Al hacer un cambio en un lugar, puedes introducir un comportamiento impredecible en otro lugar.
Los tres enfoques arquitectónicos comunes son:
  • La gran bola de barro. Es ideal para un desarrollo rápido, pero no tan bueno para fines de producción estable.
  • Inyección de dependencia. Es una solución a medias que debes evitar.
  • Arquitectura de elementos. Esta solución le permite crear componentes independientes y reutilizarlos en otros proyectos. Es mantenible y brillante para lanzamientos estables de producción.
El patrón de elemento básico consiste en una clase principal que tiene todos los métodos principales, así como un oyente que es una interfaz simple que permite la comunicación con el mundo externo.
Para lograr una arquitectura de elemento de pila completa, primero se separa el front-end del código de back-end. Luego, crea una carpeta en cada uno para una aplicación y elementos. La carpeta de elementos consta de todos los elementos independientes, mientras que la carpeta de aplicaciones conecta todo junto.
Ahora puedes ir y comenzar a crear y compartir tus propios elementos. A largo plazo, te ayudará a crear productos fáciles de mantener. ¡Buena suerte y déjame saber lo que has creado!
Además, si te encuentras prematuramente optimizando tu código, lee _ Cómo evitar la maldición de la optimización prematura_ del mi compañero de Toptal, Kevin Bloch.
Este articulo fue escrito por Konrad Gadzinowski. Originalmente publicado en Toptal.