La capacidad de la arquitectura de software se refiere a la capacidad de definir y guiar la implementación de soluciones de software estructuradas para escenarios relativamente complejos, donde estructurado significa que el software es homogéneo en su concepto de diseño, estructura de código e implementación dentro de su alcance de diseño.
El punto de partida para mejorar las capacidades de diseño estructurado es en realidad la estructura del código. Pero antes de la estructura, hay un punto de partida más sencillo, que es la limpieza del código.
En la era de Internet, la limpieza del código proviene principalmente del dominio y la aplicación de las especificaciones de programación, la abstracción del diseño y la adopción de patrones de diseño comunes. Para las especificaciones de programación, las principales empresas de software generalmente tienen requisitos, que se pueden recuperar en línea.
Ideas de diseño de programación orientada a objetos (POO). OOP es en realidad un paradigma importante del pensamiento estructurado, que requiere que pensemos detenidamente qué es una clase, qué es un objeto, cuáles son los atributos de un objeto, cuál es el posible comportamiento de un objeto, quién es el objetivo de este comportamiento, y así sucesivamente. Definir la estructura del software a través de este tipo de pensamiento sobre la esencia del modelo es una forma eficaz de mejorar la capacidad de diseño estructural del software.
Otra gran ayuda para la limpieza del código son los patrones de diseño. El principal valor de los patrones de diseño incluye tres aspectos.
- La experiencia precipitante se puede describir simplemente en una oración: si se encuentra con este tipo de escena, debe adoptar este patrón de diseño. Se puede decir que este es un proceso sistemático y eficiente de aprender de la experiencia exitosa de otros.
- Transmitir principios de diseño , que es una anotación estandarizada del pensamiento detrás del código. El campo cubierto por el código puede ser completamente nuevo, como una nueva especie en el metaverso, que puede que ni siquiera tenga una existencia correspondiente en el mundo real. Pero si usa la palabra _Factory_ o _Visitor_, los demás sabrán de inmediato el significado detrás del diseño, que es más profundo y preciso que los comentarios. Se puede decir que expresas tus pensamientos a través de un lenguaje de diseño estandarizado.
- Reduzca las barreras para comprender y mantener el código . Si los patrones de diseño comunes se usan a menudo en la implementación, se reducirá en gran medida el costo de que otros entiendan y mantengan su código. En código, estos patrones de diseño son como asientos para que los turistas descansen en las atracciones turísticas, lo que permite que otro transeúnte que está escalando con fuerza en su montaña de código encuentre de repente un lugar de descanso familiar.
Los patrones de diseño son diferentes del paradigma de pensamiento OOP. Los patrones de diseño enfatizan la convergencia y utilizan conocimientos ampliamente difundidos para estandarizar la implementación del código, reduciendo así la diversidad de métodos de implementación y nombres, es decir, para mejorar la consistencia del código. Por supuesto, algunas personas se oponen mucho a los patrones de diseño, pensando que los patrones de diseño se usan mal la mayor parte del tiempo. Es cierto que muchas personas terminan con diseños equivocados para referirse a patrones de diseño. Pero esto no es un problema de patrones de diseño, sino un problema de aplicación inadecuada por parte de los usuarios.
Entonces, en el trabajo diario, si quieres hacer un buen trabajo en el diseño estructurado, ¿a qué debes prestar atención ?
1. Concepto de diseño . Dicho esto, el diseño general debe ser coherente con la filosofía de la empresa o departamento.
Por ejemplo, si toda la empresa adopta una arquitectura en capas, su diseño también debe adoptar una arquitectura en capas tanto como sea posible. Toda la empresa adopta el concepto de diseño de microservicios, por lo que su diseño también debe adoptar el concepto de diseño de microservicios. De lo contrario, el código escrito es difícil de mantener y comprender, y también es difícil que otros lo reutilicen.
2. La estructura de la API . Es decir, la interfaz externa del módulo de software debe tener una estructura semántica relativamente obvia.
Las API expuestas a otras personas que llaman deben ser coherentes, expresivas y fáciles de entender. De lo contrario, la API hará que el código de la persona que llama sea oscuro y desestructurado en el entorno en el que se utiliza.
El primero es la naturaleza estructural de la expresión semántica. Si la API se entiende como un fragmento de texto, entonces este fragmento de texto debe tener un orden y una estructura internos, que es la estructura semántica que enfatizamos. Esta definición tiene un cierto significado interno y orden lógico, por lo que también tiene una estructura macroscópica.
El segundo es la estructura de la organización funcional. Por ejemplo, una API puede servir para múltiples roles de usuario, cada rol de usuario puede tener múltiples escenarios y cada escenario puede tener múltiples funciones. Luego, estas funciones deben organizarse en una estructura de tres capas: rol, escena y función. Los diferentes roles de usuario y los diferentes escenarios de uso deben tener diferentes granularidades de diseño.
El último es la estructura del modelo de datos. La API expondrá los datos a la persona que llama, por lo que los datos expuestos deben tener una estructura clara y cumplir con ciertas especificaciones.
3. La estructura interna del módulo , es decir, la estructura del programa. Este tipo de estructura es en realidad una manifestación concreta de la capacidad de diseño del programador que mencionamos anteriormente.
De hecho, existen estándares internacionales listos para usar en muchos campos involucrados en nuestro trabajo diario, y no hay necesidad de inventar y crear. El uso de marcos de servicios comunes como SprintBoot, confiar en las tecnologías convencionales en lugar de las de nicho y adherirse a las mejores prácticas publicadas por W3C son buenas formas de mejorar la estructura del código.
Este artículo es una nota de estudio para el día 27 de mayo. El contenido proviene del "Curso de arquitectura de Guo Dongbai" en Geek Time . Se recomienda este curso.