Header Ads Widget

Ticker

6/recent/ticker-posts

Uso de un diseño basado en el esquema como su única fuente de verdad


 Una de las partes más difíciles del desarrollo de un producto es la coordinación de tantos equipos y partes móviles. Asegurarse de que todos avancen en la misma dirección, hacia el mismo objetivo y de una manera complementaria es el elemento más importante, pero también el más difícil, de cualquier proyecto colaborativo. Si no alinea adecuadamente sus recursos, podría ralentizar el desarrollo, hacer un esfuerzo repetido en varios dominios y, en algunos casos, incluso terminar los proyectos por completo.

Entonces, ¿cuál es la solución? El establecimiento de una única fuente de verdad mediante el uso de un diseño basado en el esquema puede ayudar a alinear el desarrollo de software. Identificar un objetivo común y establecer una fuente para que los equipos y procesos se alineen es increíblemente importante, y en este artículo, le brindaremos la comprensión y algunas herramientas para hacer exactamente eso.

Los problemas del desarrollo tradicional

Al definir por qué es necesario el esquema primero, primero debemos analizar qué está mal en el proceso de desarrollo tradicional . Al desarrollar una aplicación en el sentido tradicional, el desarrollo a menudo se divide entre varios equipos y, a veces, entre varios departamentos. Hay un objetivo común declarado, pero generalmente tiene una base algo amplia, como " necesitamos crear una aplicación que aproveche Python para procesar las solicitudes numéricas de los consumidores ". Establecer objetivos como estos es necesario, pero deja vagas las especificaciones de desarrollo.

La idea es tener estos equipos en la misma página , desarrollándose por separado pero en colaboración hacia el objetivo final establecido. Sin embargo, la realidad de la situación es a menudo inversa debido a la variedad inherente de paradigmas de desarrollo. Los equipos de desarrollo no siempre se comunican claramente y, como tal, a menudo se encuentran en diferentes etapas de su ciclo de desarrollo.

La situación empeora cuando los equipos son combativos entre sí. Un equipo puede tener que esperar a que el otro cree su módulo, y luego el otro equipo puede restarle prioridad a esa solicitud para su propia ruta de trabajo. Con el tiempo, estos proyectos competitivos sutiles e indirectos tienen el efecto acumulativo de disminuir el éxito del proyecto. Agregue a esto la práctica estándar de cambiar conjuntos de características, cambios de alcance, etc., y tendrá una fórmula para el desastre.

El problema no es solo entre equipos. Hacer coincidir el desarrollo de API y aplicaciones con las necesidades del desarrollador es una cosa, pero tener que hacerlo también con los propósitos comerciales y las expectativas de las partes interesadas es bastante problemático. La falta de una limitación estricta sobre lo que es posible y lo que se espera solo amplifica estos problemas.

Más adelante, una vez que la API y la aplicación están completas y se genera la documentación , surgen más problemas. Hacer coincidir la documentación con la funcionalidad real, garantizar contenidos y referencias actualizados, y otros problemas similares de unir la actualidad con la funcionalidad esperada puede matar rápidamente la adopción o hacer que la iteración adicional sea mucho más difícil.

Eso es exactamente lo que crea un esquema : un contrato, un plan y un acuerdo detallado. Cuando discutimos el concepto de "esquema", lo que realmente estamos discutiendo es una estructura organizacional definida por código , un sistema que define y limita el diseño y la función de una base de código dada dentro de un "plan" específico. Un esquema a menudo define tipos de datos y sus interacciones específicas, y puede adoptar muchas formas.

Lea también: Cómo hacer una API empresarial autodescriptiva

¿Qué es el desarrollo de esquema primero?

Quizás la mejor solución a este problema es la adopción de una práctica de desarrollo basada en el esquema. El desarrollo del esquema primero establece un contrato entre los desarrolladores y las expectativas operativas de los gerentes de proyecto . Un esquema es fundamentalmente un conjunto acordado de estándares y enfoques, y al establecer el esquema como un contrato restringido, puede asegurarse de que, independientemente de lo que surja del desarrollo, se alineará con los objetivos generales establecidos.

Al hacerlo, los equipos ni siquiera tienen que comunicarse necesariamente: sus sistemas funcionarán entre sí siempre que cumplan con el contrato. Para cuando haya terminado, todo funcionará de la manera que se supone que debe hacerlo, sin la necesidad de tener scrums masivos o pausar el desarrollo mientras espera que los módulos o partes del código estén terminados.

Considere un ejemplo básico de JSON:

{
    "title": "Person",
    "type": "object",
    "properties": {
        "firstName": {
            "type": "string"
        },
        "lastName": {
            "type": "string"
        },
        "age": {
            "description": "Age in years",
            "type": "integer",
            "minimum": 0
        }
    },
    "required": ["firstName", "lastName"]
}

En tal esquema, podemos ver la función exacta de cada dato y cómo esos datos interactúan con otros. Sabemos que firstNamees una propiedad de cadena, que agees un tipo entero con un valor mínimo y que ambos son elementos del objeto PersonDesde aquí, con objetos, funciones, tipos y puntos finales adicionales, podemos formar un rango de objetos y entidades específicos, y definir su función en contexto entre sí, en lugar de definir su función esotéricamente.

Lea también: CLI que utilizan empresas relacionadas con API

5 Beneficios del diseño Schema-First

Entonces, ¿cuáles son algunos de los beneficios de adoptar un diseño de esquema primero? Además de la mejora de la colaboración y la coherencia de la plataforma, existen otros beneficios prácticos que pueden obtenerse mediante la adopción.

1: Desarrollo restringido

La elección de un esquema restringido obliga a los equipos a comunicarse entre sí. Esta comunicación puede no ser explícita, pero como sus funciones están limitadas por restricciones establecidas, siempre se adhieren pasivamente a la intención comunicada del contrato acordado.

Si bien la comunicación real y directa es a veces preferible, la adopción de un concepto de esquema primero obliga a los equipos a trabajar de manera más eficiente manteniéndose " en las especificaciones ". Esta alineación pasiva con el objetivo establecido significa que los equipos pueden desarrollarse sin tener que esperar nuevos módulos, ya que esperan cierta funcionalidad del núcleo y la alineación establecida. Todo el trabajo está sincronizado entre sí .

Para llevar:

El diseño de esquema primero establece un proceso de desarrollo restringido que evita el desarrollo y la desviación del alcance.

2: Desarrollo más rápido

Una gran ventaja de tener una especificación común y aceptada es que el desarrollo es mucho más rápido de lo que permitirían los métodos tradicionales. Los equipos frontend pueden comenzar a construir componentes de inmediato, independientemente de si dichos componentes backend existen o no, porque no tienen que esperar para ver qué gancho debe llamarse y cómo funcionará. Si bien es probable que los puntos finales y los elementos internos cambien, la forma en que funcionan no lo hará: los equipos saben en general qué se va a construir porque conocen las limitaciones sobre las que se construirá.

Lo mismo ocurre con el equipo de backend . Su trabajo no necesita ser traducido al equipo de frontend, ya que todo está diseñado de forma estandarizada y, como tal, es muy predecible. Si la planificación se realizó correctamente antes del desarrollo, y tanto los plazos como los objetivos están bien establecidos, este desarrollo puede ser incluso más rápido debido a las ganancias en eficiencia mediante esfuerzos coordinados.

Para llevar:

El diseño de primer esquema reduce muchos de los elementos que provocan retrasos en el desarrollo y ralentización de los procesos.

3: Desarrollo más limpio

Algo terciario del desarrollo eficiente es el hecho de que el desarrollo es mucho más limpio . La adopción de un enfoque de esquema primero tiene el efecto de reducir los problemas de las funciones de la base de código que no cooperan, los errores entre los puntos finales y los controladores incorrectamente indicados, etc. Al hacer que los equipos acuerden un esquema, los errores se reducen drásticamente, al igual que los errores de funcionalidad no intencionada: la funcionalidad es conocida y esperado, por lo que cuando ocurre un error , se puede identificar rápidamente.

Este enfoque también puede reducir la duplicación . Sin un contrato establecido de qué es qué y cómo esperamos que se haga, los equipos de backend pueden construir enlaces que el equipo de frontend no necesita, el frontend puede replicar funcionalidades que pueden no ser necesariamente frontales, o se podrían diseñar funciones completas para propósitos que ya no existe. Definir el código base esperado y lo que debería hacer alivia muchos de estos problemas.

Para llevar:

El diseño de esquema primero da como resultado una base de código más limpia, en la que la funcionalidad esperada se presenta de una manera limpia sin duplicación de código y esfuerzo.

4: Generación de recursos

Un beneficio masivo que no puede pasarse por alto es el hecho de que la adopción de un enfoque basado en el esquema crea material que se puede utilizar para generar recursos adicionales . Hacer que el código base se adhiera a un esquema estricto es como un lenguaje o matemáticas: con un conjunto común de reglas, cualquier cosa se puede portar o traducir entre múltiples formas.

El contenido de la base de código basado en esquemas bien definido se puede utilizar para generar automáticamente una API, su documentación e incluso la CLI que controla las funciones. Además, un esquema base y una API se pueden aprovechar para generar o renderizar una API de hipermedia con muy poca sobrecarga adicional.

También debe tenerse en cuenta que una API basada en esquemas bien definida se presta muy bien a la iteración , ya que dichas iteraciones se basan en elementos y restricciones conocidos y, por lo tanto, se pueden impulsar sin romper la funcionalidad para los clientes o bifurcaciones de la base de código principal.

Para llevar:

El diseño de primer esquema permite la generación automatizada de recursos clave para los usuarios de API y aplicaciones y, a su vez, reduce el tiempo de comercialización.

Fuente única de verdad

Todos estos beneficios se unen para formar la esencia de por qué el esquema primero es tan efectivo: crea una única fuente de verdad . El concepto de una sola fuente de verdad se puede resumir a grandes rasgos como la formación de un modelo de información estructurado y un enfoque de esquema que define los elementos de datos de forma singular. En otras palabras, debe haber un esquema acordado que defina la funcionalidad y los datos que maneja, en lugar de utilizar diferentes fuentes de diferentes equipos, que pueden ni siquiera estar de acuerdo con el objetivo declarado del proyecto.

Una única fuente de verdad es esencialmente una "lengua franca" de objetivos; proporciona una dirección para cada decisión que se toma y un único punto de referencia. En este caso, no hay datos específicos de "escritorio", datos específicos de "dispositivos móviles" o "diseño obsoleto"; todo se basa en una sola fuente, un solo punto de referencia y, por lo tanto, hay poco contenido duplicado o confuso.

Lea también: 4 mantras para diseñar API escalables

Pensamientos finales

El diseño de esquema primero toma un acuerdo tácito sobre el propósito y el plan, y lo convierte en una guía establecida, aceptada y compartida para el desarrollo. Sin un objetivo tan singular y declarado, cualquier proyecto de desarrollo no estará en gran parte guiado y, debido a esto, sufrirá muchos de los problemas que hemos discutido hoy.

El simple hecho es que adoptar un diseño de esquema primero no es difícil, y los beneficios que se obtienen de su adopción son tan enormes que no se pueden ignorar. Aprovechar una única fuente de verdad es extremadamente poderoso y debe hacerse lo antes posible en un proceso de desarrollo, y adoptar un diseño de esquema es la forma más fácil de establecer dicha fuente.

¿Qué opinas sobre el diseño de esquema primero? ¿Es una fuente única de verdad realmente tan importante, o son aceptables otras metodologías en ciertas aplicaciones? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios