En un mundo ideal, nos gusta que los equipos sean multifuncionales, donde se integran backend, front-end y UX. Si un equipo es responsable de cierta parte del conjunto de características del producto, tiene todas las competencias integradas para diseñarlo, construirlo y operarlo. No se puede señalar con el dedo, y hay menos necesidad de coordinación, transferencias y gestión de dependencias, que no son escalables.
Amazon es famoso por un enfoque en el que, según Werner Vogels, “cada servicio tiene un equipo asociado, y ese equipo es completamente responsable del servicio, desde el alcance de la funcionalidad, la arquitectura, la construcción y el funcionamiento”. (Ver http://queue.acm.org/detail.cfm?…)
Sin embargo, a veces la división de back-end de front-end es inevitable y es algo con lo que tienes que trabajar. Quizás la organización ha sido operada de esta manera durante mucho tiempo, y usted no tiene tiempo suficiente para solucionarlo. Quizás esté tratando con dos tiendas diferentes, una que resulta ser Ace en HTML5 y otra en backend y Big Data. Una forma de abordarlo es observar cómo la tecnología inteligente ha permitido la integración de sus servicios con sus clientes y socios. Con las API y los SDK, ha formalizado contratos entre un equipo y otro equipo, manifestado en código, documentación y pruebas. Estos pueden funcionar para usted en muchas configuraciones diferentes, resumiré un par aquí:
- ¿Cuál es la mejor manera de detectar un cambio en un cuadro de texto HTML?
- ¿Qué CMS o herramientas es mejor para hacer un sitio de revista?
- ¿Puedo usar ReactJS con otros marcos Javascript?
- ¿Cuáles son los diferentes controles de .NET AJAX?
- ¿Es fácil para un diseñador web que solo conoce HTML5 y CSS3 aprender PHP y MySQL?
SOA
Una forma de integrarse con el back-end de la capa web front-end es con servicios de estilo HTTP REST. Por ejemplo, puede tener una pila Java que sirve puntos finales JSON y una capa web de Python que consume e interactúa con esos servicios web. El equipo de back-end solo proporciona cierta documentación sobre los servicios y las pruebas automatizadas que se ejecutan continuamente en su contra.
Biblioteca de cliente o SDK
Otras veces, no está utilizando SOA internamente, digamos que está en una pila completa de Ruby o una pila completa de Java, pero su equipo de front-end estará operando en la parte superior, por ejemplo, creando rutas de URL y controladores, mientras que el back- El equipo final está construyendo toda la lógica empresarial y el código de acceso a datos. Aquí puede presionar para que el equipo de back-end proporcione una biblioteca de cliente que exponga todas las interfaces que se espera que el front-end use para construir páginas. Haga que se ejecuten pruebas de integración automatizadas en esa biblioteca cliente.
Datos simulados
Muchas veces, los problemas con la integración entre equipos funcionales están en las transferencias. El equipo de front-end no puede construir su widget porque el equipo de back-end aún no lo ha hecho, o de lo contrario lo han hecho pero están en algún proyecto de infraestructura y los servidores están explotando durante todo el día. La biblioteca del cliente puede proporcionar una capa de aislamiento al equipo de front-end, donde debería poder conectar diferentes fuentes de datos en su entorno de desarrollo, para simular el funcionamiento del backend según las especificaciones. Esto garantiza que pueda desarrollarse de forma independiente, al mismo tiempo, sin salir completamente del rango y preparándose para una integración dolorosa más adelante.
Integración continua
Las pruebas son las que le permiten comunicar el estado de los puntos de integración a un nivel detallado, automáticamente. Cuando alguien registra un código que rompe el contrato, lo sabes de inmediato. Las pruebas de CI y automatizadas también evitan los problemas comunes que las grandes reuniones de integración y alineación entre equipos intentan resolver. Los resultados de las pruebas transmitidas a los líderes del equipo aseguran que la responsabilidad del equipo sea evidente, en lugar de turbia y subjetiva.
Tangencialmente, vale la pena leer la publicación de Steve Yegge, si de alguna manera aún no lo ha hecho, sobre la construcción de plataformas y la separación entre equipos: https://plus.google.com/11267870…. Habla mucho sobre cómo lo hizo Amazon y los desafíos que enfrentó en Google.
