¿Deberíamos escribir un diseño de arquitectura detallado o simplemente un esbozo al diseñar un programa?

Cuando estoy diseñando para una tarea, sigo luchando contra esta sensación persistente de que, aparte de ser un esquema general, al final será más o menos ignorado. Te daré un ejemplo:

Estaba escribiendo una interfaz para un dispositivo que tiene operaciones de lectura / escritura. Tenía perfecto sentido en el diagrama de clases para darle una función de lectura y escritura. Sin embargo, cuando llegó el momento de escribirlos, me di cuenta de que eran literalmente la misma función con solo una línea de código cambiada (llamada de función de lectura vs escritura), por lo que para evitar la duplicación de código, terminé implementando una función do_io con un parámetro que distingue entre operaciones Adiós diseño original.

Este no es un cambio terriblemente disruptivo, pero ocurre a menudo y también puede ocurrir en partes más críticas del programa, por lo que no puedo evitar preguntarme si hay un punto para diseñar más detalles que un esquema general, al menos cuando viene a la arquitectura del programa (obviamente cuando especificas una API tienes que explicar todo).

Esto podría ser solo el resultado de mi inexperiencia en el diseño, pero por otro lado tenemos metodologías ágiles que dicen "renunciamos a la planificación con anticipación, de todos modos todo va a cambiar en unos pocos días", lo que a menudo es como me siento.

Entonces, ¿cómo exactamente debo "usar" el diseño?

Si tenía sentido proporcionar operaciones de lectura y escritura, ¿por qué eliminarlas?

Desde el punto de vista del usuario, todavía tiene mucho sentido. Los detalles de implementación no deben interferir con una interfaz proporcionada.

Lo que puede hacer es crear un do_io interno que se llama mediante lectura y escritura.

Al final, el proceso de diseño sigue estos pasos:

• definir la interfaz
• dibujar un diseño aproximado
• refinar sin cambiar la interfaz acordada

El diseño arquitectónico de un programa evoluciona con el tiempo. No creo que al principio tenga toda la información que necesitará para tener un diseño correcto.

Entonces, si te apegas al diseño que pensabas al principio, probablemente te limitarás.

A menos que esté creando una API pública, creo que está bien hacer cambios en el diseño en el camino.

También una de las mejores cosas para hacer es invertir en una herramienta que pueda extraer el diseño del código (como NDepend para C #)

Agile afirma responder a este problema, con cierto éxito. Sin embargo, Fred Brooks tuvo la respuesta hace 40 años, cuando escribió "Escribe uno para tirar, porque de todos modos lo harás". Aquellos que no estudian historia están condenados a repetirla.

Entonces, ¿qué hacer es tratar el diseño como un plan, hecho con el único propósito de cambiarlo? Los diseños que no se pueden cambiar están condenados. Debes estar preparado para tirar los malos.

Si el diseño es de una API pública, interfaz o similar, se debe tener mucho cuidado ya que el costo del cambio es alto, sin embargo, la imposibilidad de cambiar lo condenará al fracaso.

Por un segundo, no piense que es lo suficientemente bueno y sepa lo suficiente para hacerlo bien primero, segunda o incluso tercera vez.

Es un hecho de la vida en la mayoría de los proyectos de la vida real que las cosas cambian:

• (como notó) el entorno / plataforma / API que utilizará el programa puede ser diferente de lo que se suponía originalmente
• los requisitos pueden cambiar en cualquier momento
• el mercado / mundo circundante puede cambiar, obsolescendo algunos requisitos (o todo el proyecto)
• ...

Esta es la razón por la cual los métodos ágiles se oponen a Big Design Up Front, porque solo da una falsa sensación de seguridad, implica mucho esfuerzo inútil y hace que la adaptación a los cambios inevitables sea más difícil.

Sin embargo, Agile no equivale a "renunciar a la planificación con mucha antelación" . Los métodos ágiles implican la cantidad necesaria de planificación cuidadosa y reflexiva, simplemente no más. Son muy disciplinados y diferentes de la "codificación de vaqueros". Hacer la cantidad correcta de diseño es un intento continuo de encontrar el equilibrio correcto entre un diseño excesivo y un diseño insuficiente. Pero en mi humilde opinión, es mejor errar un poco del lado de demasiado, que hacer muy poco.

El diseño inicial no debe tratar de abarcar todo, pero debe darle una sensación segura de que sabe cómo seguir adelante con la implementación, tiene respuestas a las preguntas fundamentales sobre la arquitectura y tiene un modelo mental de cómo el uso conocido Los casos van a funcionar en la vida real. En la vista Ágil, la prueba real de un diseño es la implementación, por lo que está bien comenzar a escribir código incluso durante la fase de diseño, solo para tener una idea de cómo se vería el diseño previsto, o para prototipar / validar rápidamente alguna suposición . Sin embargo, tenga en cuenta que la mayoría de estos trabajos iniciales se deben desechar una vez que se determina la respuesta a la pregunta dada. Casi siempre es malo comenzar a construir una aplicación de producción real a partir de un prototipo inicial.

Y también está bien regresar y modificar el diseño si realiza una nueva realización importante durante la implementación. Este es un comentario importante en dos niveles:

• su diseño concreto necesita adaptarse al mundo cambiante, y
• su proceso de diseño debe adaptarse para cubrir tales posibilidades en el futuro (es decir, la próxima vez piense en el caso de uso de leer y escribir en el dispositivo con mayor anticipación).

Siempre es importante cuando crea un documento para comprender cuál es su propósito.

Creo que debemos tener cuidado con lo que llamamos documentos de "arquitectura". Todo es una cuestión de alcance.

Si está hablando de un sistema que requiere varios equipos o grupos de equipos, entonces está hablando de un documento cuyo propósito es detallar como mínimo:

• ¿Cuáles son los componentes del sistema?
• ¿Cómo se conectan los componentes?
• ¿Cuáles son las responsabilidades de cada componente?
• Quién debería estar trabajando en cada componente

Si su documento es para un sistema más pequeño, puede reducir la cantidad de elementos que debe incluir porque algunos supuestos serán inherentes al sistema existente. Por ejemplo, suponga que está armando una función que necesitará realizar un trabajo en un sitio web y algunas llamadas nuevas en una API, luego su documento servirá como una forma de concretar lo siguiente:

• Qué lógica vivirá en el sitio web
• Qué lógica vivirá en la API
• ¿Cuáles serán los contratos de llamadas API?

Estos documentos generales sirven para traer conversaciones al frente sobre quién debe hacer qué y cómo deben integrarse. Una vez que se toman esas decisiones, los equipos pueden operar en gran medida de forma autónoma con una probabilidad mucho menor de problemas de integración.

Cuantos más problemas de integración perciba, más detallados deberían ser los documentos.

Parece que te has topado con un enigma común en el desarrollo de software. No es posible planificar un sistema completo antes de comenzar a construirlo, porque hay demasiadas cosas que aún no sabe.

Esta es la razón por la cual las metodologías ágiles utilizan el desarrollo iterativo, ya que permite comentarios regulares para cambiar la dirección del software, en lugar de permitir que las cosas se alejen más y más de lo que realmente se necesita. Cada cambio afectará el diseño.

Habiendo dicho todo esto, en realidad habría escrito dos métodos para el escenario específico que describió anteriormente, pero habría encapsulado la lógica compartida en un tercer método privado que puede ser utilizado por los dos métodos. De esta manera, los métodos públicos son responsables de una sola cosa y son fáciles de nombrar read_filey write_filedecir exactamente lo que hacen, mientras que do_filees ambiguo.

Libros como Clean Code , Robert C Martin y Emergent Design , Scott L Bain le brindarán información más detallada sobre este tema.

Esto podría ser solo el resultado de mi inexperiencia en el diseño, pero por otro lado tenemos metodologías ágiles que dicen "renunciamos a la planificación con anticipación, de todos modos todo va a cambiar en unos pocos días", lo que a menudo es como me siento.

No es posible planificar cada detalle por adelantado. Es perfectamente aceptable hacer cambios aquí y allá.

Sin embargo, es importante planificar con anticipación. Hacer ágil no significa que no haya diseño ni planificación en absoluto , pero significa que está esperando cambios.

Entonces, ¿cómo exactamente debo "usar" el diseño?

Debes usar tu diseño tal como está. Como no está escrito en la piedra, es fácil cambiarlo.

La cantidad de tiempo que pasa en la arquitectura debe estar determinada por el grado de riesgo en esa parte del sistema.

En general, querrá tomar una decisión con bastante anticipación sobre los estilos arquitectónicos: capas, componentes, pub-sub, etc., etc. Ninguna cantidad de código limpio y acoplamiento flojo facilitará el cambio de estilos más adelante un proyecto.

Hacer eso le dará una idea básica de los diferentes bloques de construcción en su sistema y cuál será la hoja de ruta a medida que su sistema y requisitos evolucionen con el tiempo.

Una vez que entre en los casos de uso, creo que debe hacer un diseño suficiente para asegurarse de que comprende completamente el problema y la solución. Si lo que ha hecho una y otra vez es el código de la placa de la caldera, entonces el riesgo de equivocarse (en un sentido arquitectónico, aún tendrá que probar, por supuesto) es bastante bajo, por lo que es probable que la cantidad de diseño inicial ser bastante mínimo Si se trata de un problema nuevo, o uno con una solución poco clara o que es potencialmente riesgoso para el negocio, entonces merecerá mucho más tiempo para pensarlo detenidamente.

Por supuesto, hay una amplia gama de formas de hacer esto: UML, prototipos, bocetos de pizarra, etc. Cualquiera que sea el método que use, la clave es recordar que su propósito es ayudarlo a pensar y comunicarse sobre su diseño.