¿Por qué necesitamos documentos en el proceso de desarrollo? ¿Qué pasa con esta afirmación de que el ? código se documenta a sí mismo Consideremos el escenario más común: el código del sistema (ya sea un programa, proyecto o producto) se escribe durante un largo período, y el equipo cambia gradualmente durante este proceso, llevándose consigo ciertos conocimientos sobre el sistema a medida que los desarrolladores se van. ¿Qué podemos hacer en tal caso? La respuesta más sencilla es que capture todos los detalles de implementación para garantizar que el sistema cumpla con los requisitos originales. escribir una especificación Sin embargo, un documento de este tipo es muy difícil de redactar con antelación y, durante el proceso de desarrollo, algunos detalles de implementación pueden cambiar (adaptación al mercado/nuevas solicitudes de mecánica, etc.). Entonces, ¿qué podemos idear para mejorar el ? factor autobús Intentemos seguir un flujo que podría ser una de las posibles soluciones para abordar el problema mencionado anteriormente. Requisitos y RFC Primero, necesitamos describir el diseño inicial basado en los requisitos de las partes interesadas y documentarlo. Después de eso, este documento se puede compartir con otros equipos y solicitar sus comentarios: solicitar implementar ciertas características, comentar sobre el diseño inicial, arreglar una determinada interfaz, etc. Un documento de este tipo se puede llamar . RFC , o "Solicitud de comentarios", es un documento que se distribuye entre las partes interesadas (incluidos desarrolladores, arquitectos y otros equipos) para recopilar comentarios y sugerencias. Es menos detallado que una especificación e incluye sólo el problema inicial, la tarea y el dominio de la solución. Al ser más flexible, permite aceptar activamente cambios en el diseño, asegurando una comprensión profunda de la tarea y facilitando la calidad y la toma de decisiones reflexivas. RFC Compromiso de diseño y ADR Bien, hemos y . ¿Que sigue? definido los requisitos técnicos recopilado los requisitos de otros equipos En esta etapa, es necesario y todas las funciones principales que realizará. Para ello redactamos un . finalizar el diseño del sistema ADR , o "Registro de decisiones de arquitectura", es un documento que registra decisiones arquitectónicas importantes tomadas durante el proceso de desarrollo de software. Cada describe una decisión arquitectónica específica de alto nivel, su contexto, las alternativas consideradas, la decisión tomada y la motivación para elegir estos detalles específicos sobre otros. ADR ADR Un documento de este tipo permite que cada miembro del equipo (y también otros equipos) los principios y valores que sustentan el diseño. Si un nuevo desarrollador se une al equipo años después y pregunta: "¿Por qué lo hiciste de esta manera?", se le puede mostrar este documento, que responderá a todas sus preguntas. comprenda Especificación Ahora es el momento de escribir el código y sus especificaciones. En esta etapa, trabajamos minuciosamente en cada característica, recopilando simultáneamente toda la información y los detalles de implementación en un documento especial. Este documento debe reflejar los requisitos actuales de bajo nivel para el sistema. : durante el ciclo de vida del software, dicha especificación puede cambiar significativamente, y eso está bien. Sin embargo, es muy importante permanecer dentro del diseño y la arquitectura originales para evitar que el código base se convierta en algo inmanejable. Un punto importante Plan de prueba ¿Por qué es necesario? Es fundamental que un plan de pruebas se construya escrito de acuerdo con la especificación (escribimos el código y las pruebas para este código para que pasen), sino sobre que incluya escenarios críticos que . También es muy conveniente que pueda enviar dicho plan de prueba para que otros equipos lo revisen (para integraciones o simplemente para pruebas adicionales), dejando claro cómo se comportará el sistema en diferentes situaciones. no sobre la base del código la base de un diseño debe ser procesado correctamente ¿Qué incluye? Todos los escenarios posibles de funcionamiento del sistema. feliz camino camino triste Manejo de errores Todas las posibles invariantes que deben mantenerse durante la operación del sistema. Pruebas de aceptación para verificar el estado del sistema al inicio (deben considerar el entorno, por ejemplo, datos en la red) Finalizamos el , escribimos el código y y compilamos el . ¡Ya suena bastante sólido! ¿Pero qué más podríamos agregar? diseño las especificaciones plan de pruebas Plan de empleo Un plan de este tipo podría ser necesario hasta cierto punto para y crear condiciones en las que cualquier miembro del equipo pueda implementar el sistema y verificar su estado. mejorar el factor bus ¿Por qué no podemos prescindir de él? Podemos, pero en el mundo real, equipos grandes donde muchas personas son responsables de diferentes partes del sistema y el proceso de implementación podría a DevOps. ¿Qué hay de malo en eso? Dado que escribimos pruebas, las pusimos en CI y verificamos las vulnerabilidades, ¿necesitamos algo más? Quizás no, pero a menudo las pruebas no consideran el estado actual del sistema y no prueban exactamente lo que nos gustaría. delegarse completamente Qué plan de implementación : podría contener Una descripción completa de las acciones que deben realizarse para que se lleve a cabo la implementación. Parámetros de implementación: Variables de entorno Estado inicial Parámetros para el lanzamiento. Un plan por si algo sale mal en algún paso Un plan de respaldo, si es posible El estado necesario al que se debe llevar el sistema en caso de que no sea posible continuar con el despliegue Acciones que deben realizarse después de la implementación Notificar a otros equipos Habilite las integraciones necesarias, si es necesario Nada complicado, ¿verdad? Tener un documento de este tipo para una actualización específica puede y de personas específicas. ¿No es eso lo que queremos? mejorar significativamente el factor bus evitar la dependencia Conclusión En el proceso de desarrollo de software, es importante no sólo escribir código, sino también crear documentación que garantice la comprensión y la coherencia en todas las etapas del desarrollo. La documentación , pero la experiencia ha demostrado que la documentación es muy importante para mantener la calidad, estabilidad y escalabilidad futura del sistema, especialmente cuando el equipo cambia durante el desarrollo, y también cuando el proyecto evoluciona y se adapta a nuevos requisitos. puede ser el código en sí La documentación incluye (Solicitud de comentarios), (Registros de arquitectura), , , y más. Esto garantizará la , simplificará el proceso de al proyecto y . RFC ADR Especificaciones Planes de prueba Planes de implementación retención del conocimiento en el equipo integración de nuevos empleados aumentará la confiabilidad general y la resistencia del sistema a los cambios

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Making security fun one episode at a time

¿Qué sabe sobre el desarrollo basado en documentos?

Demasiado Largo; Para Leer

Roman Kolpakov

STORY’S CREDIBILITY

Guide

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

¿Qué sabe sobre el desarrollo basado en documentos?

Demasiado Largo; Para Leer

Roman Kolpakov

STORY’S CREDIBILITY

Guide

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS