Revisión Efectiva de Documentos de Diseño en Equipo
Resumen
¿Cómo revisar eficazmente un documento de diseño?
Revisar un documento de diseño no solo es una práctica valiosa, sino esencial para asegurar la calidad y optimización de un proyecto. A través de la colaboración y la retroalimentación, podemos identificar fallos potenciales y proponer mejoras. Pero, ¿cuáles son las mejores estrategias para llevar a cabo una revisión eficaz? Aquí te presentamos algunas recomendaciones vitales.
¿Qué pasos seguir para una revisión de diseño efectiva?
Colaboración en equipo: Involucra a tus compañeros de equipo o colegas en el proceso de revisión. Al compartir diferentes perspectivas, se pueden descubrir aspectos que quizás no se consideraron inicialmente.
Discusión de alternativas: No te limites a una sola opción de diseño. Presentar múltiples alternativas puede enriquecer el debate y eventualmente llevar a una solución más sólida y adaptada a los requerimientos.
Preguntas críticas: Al revisar, formula preguntas del tipo:
¿Por qué se eligió esta opción?
¿Cómo puede mejorar el diseño?
¿Cómo impacta esto en la infraestructura?
¿Cómo se relaciona con los objetivos del negocio?
¿Cómo manejar el feedback de diseño?
Al recibir opiniones o críticas, es fundamental abordar el feedback de manera constructiva. Busca entender las razones detrás de las sugerencias de cambio. Pregunta por qué una recomendación podría ser mejor que tu propuesta original y cómo podría beneficiar al proyecto en su conjunto.
¿Cuál es el impacto de la infraestructura y la escala del proyecto?
La infraestructura es un pilar fundamental en cualquier diseño. Considera cómo el diseño actual se escalará en función del crecimiento del proyecto. Por ejemplo, plantea preguntas sobre:
La capacidad de almacenamiento y procesamiento de la base de datos.
La regionalización para optimizar la latencia y el acceso.
La sostenibilidad frente al aumento de la carga de trabajo.
// Ejemplo de un servicio para gestionar reseñas en una base de datos MySQL.publicclassReviewService{// Método que agrega una nueva reseña a la base de datos.publicvoidaddReview(Review review){// Se establece conexión con la base de datos MySQL.Connection connection =Database.getConnection();// Se prepara la sentencia SQL para insertar la reseña.String query ="INSERT INTO reviews (content, userId) VALUES (?, ?)";// Bloque try con recursos para asegurar el cierre de recursos.try(PreparedStatement statement = connection.prepareStatement(query)){ statement.setString(1, review.getContent()); statement.setInt(2, review.getUserId()); statement.executeUpdate();}catch(SQLException e){ e.printStackTrace();// Manejo de excepciones en caso de error.}}}
¿Qué preguntas considerar durante el design review?
Para que un design review o revisión del diseño de la arquitectura sea auténticamente productivo, es vital que cada interacción aporte mejoras sustanciales. Aquí es donde entran las preguntas cruciales y las alternativas de diseño:
¿Cómo se puede adaptar el diseño si cambian los requisitos del negocio?
¿Se han contemplado problemas potenciales de redundancia y recuperación de datos?
¿Cuál es la viabilidad económica de la opción propuesta?
En resumen, la revisión de un documento de diseño es una oportunidad invaluable para mejorar y refinar un proyecto. Con la preparación adecuada y una mentalidad abierta para el feedback, cada revisión no solo hará que el diseño sea más robusto, sino también más flexible y alineado con las metas del negocio. Continúa perfeccionando tus habilidades y comparte tus aprendizajes con otros para fomentar un entorno de mejora continua. ¡Sigue adelante y crece en tu camino hacia la excelencia en el diseño!
Cosas importantes a tener en cuenta:
.
¿Por qué?: Especifica por qué una alternativa es mejor que otra o por qué puede beneficiar más.
¿Cómo afecta la infraestructura? Especifica cómo va a beneficiar en cuanto a infraestructura se refiere (recuerda que la infraestructura es toda esa distribución que tenemos planeada, desde las localizaciones de los sistemas, etc.)
¿Cómo ligarlo con los requerimientos originales del negocio? Verifica si tus propuestas realmente satisfacen los requerimientos que tienes que resolver
¿Cómo mejoran los costos? Mira si tus propuestas ayudan a disminuir costos en infraestructura
.
Siempre pide opinión de los demás, todos podemos tener opiniones diferentes en cuanto a la realización de la planificación de la distribución del sistema, entre las opiniones de todos podemos llegar a una solución más eficiente ^^
Complementando lo que el Profe @RetaxMaster comenta, me gustaría agregar que en ocasiones es necesario considerar el Stack Tecnológico existente del cliente, ya que no siempre se tiene la libertar de usar todas las tecnologías; en otras palabras, estamos limitados a montar soluciones en arquitecturas ya existentes, lo que nos lleva a entender el As Is y no necesariamente irnos al To Be de la solución del requerimiento; Por lo que este punto es muy importante considerarlo y como bien lo comentan nunca dejar de lado el tiempo/costo.
Que gran curso 👏🏼👏🏼
Este paso es uno de los mas valiosos de la construcción o el diseño de una infraestructura. Muchas veces iniciamos nuestro proyecto omitiendo muchas perspectivas que se nos presentan en el día a día con los sistemas.
Cómo se va a comportar la DB si tiene replicas en diferentes regiones?
Qué pasa si X servicio se cae por un momento, como se comportaría el sistema?
Lo más relevante es hacer preguntas de posibles comportamientos del sistema, a partir de ahí, se crean las soluciones.
¡Qué buen curso! Me está abriendo la mente a lo que ignoraba.
Si senor
Me gusta mucho este tipo de ejercicios en los que te plantean antes el problema a resolver y tenemos suficiente tiempo de pensar en nuestra solución antes de mostrar la propuesta del profesor, en mi caso tenía ya pensada una arquitectura pero que tenía algunos problemas que ya yo mismo había identificado y no sabía como resolver. Se expande la mente cuando la propuesta dada resuelve los problemas que ya tenías identificados.
Importante trabajar con el cliente para tener claro todos los requerimientos
Hace poco vi el curso de arquitectura de alta concurrencia, donde mencionaban que era normal presentar una arquitectura donde hubieran más bases de datos de lectura que de escritura, así que me siento muy orgulloso de haber pensado en la arquitectura que propone el profe sin necesidad de haber visto esta clase primero c:
Dónde viste el curso de arquitectura de alta concurrencia. Puedes compartir el link. Muchas gracias. Saludos y Exitos-...
NO se debería tener como base el RTO y RPO para poder iniciar el diseño?
Excelente pregunta, estuve leyendo ya que no sabia a cerca de estas estrategias, y seria interesante poder mostrarla en el desarrollo de del document, para poder enseñarles al cliente cuales pueden ser sus tiempos de respuesta si algo ha dejado de funcionar y que implica en costos/tiempo este "desastre"
tengo entendido que las noSql son muy rapidas en su consultas a las bases de datos, y las Sql son muy buenas para hacer queries complicadas, en este caso de uso, con el usuario que escribe sus reviews, no veo en los casos de uso ni una query complicada ni algo que indique que se necesita poca latencia, entonces la base de datos no debería ser agnostica?, osea sin especificar noSQL o Sql?
El diseño debe ser un trabajo en equipo, las perspectivas de cada quien son distintas dependiendo las tareas que les correspondan y el feedback se hace esencial por esto.
Un equipo multicultural ayuda a encontrar esos puntos ciegos que puede haber omitido una persona
Es indispensable tener en cuenta el DRP y las respectivas pruebas, por mas que sea nube (asi sea la mas avanzada) se pueden presentar caidas del servicio. Todo debe tener alta disponibilidad.
Hasta este momento esta clase si me ha aportado. Open my mind. Gracias.
Dar feedback partiendo del por qué
Esto me recordó algo de la clases de ING de software que tome en la Uni.
EL tema de diagrama de Casos de uso.
Diagrama secuencial.
Requerimientos funcionales - no funcionales
Entre muchas otras cosas más
En el tema de usuarios; siempre nos referíamos a concurrencia, y el tema de patrones de diseño.
Esta clase en particular me pareció excelente, sería genial tener mas cursos de este estilo con enfoque a planeación de un desarrollo de software