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!
Revisión Efectiva de Documentos de Diseño en Equipo
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.
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.
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:
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.
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.
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.