He leído muchas cosas en Internet. Es realmente difícil encontrar algo sobre la arquitectura del software JAVA. Sin embargo, la arquitectura del desarrollo de software es básicamente la misma. Por lo tanto, busqué en Internet muchos artículos sobre arquitectura de software en otros idiomas. Una vez más, permítanme hablar sobre mis puntos de vista sobre la arquitectura de software, especialmente sobre la arquitectura de proyectos JAVA. Puede que eso no sea correcto, pero este es también mi resumen de los últimos años.
1. Intenta no considerar la reutilización fuera del proyecto.
Mucha gente piensa que es mejor mejorar la reutilización del software. Sin embargo, la situación real de cada proyecto será diferente. Al diseñar un determinado módulo o método en el proyecto, demasiada consideración de la reutilización fuera del proyecto inevitablemente aumentará el número. de proyectos. La complejidad aumenta el tiempo de desarrollo. Algunas personas pueden decir que esto reducirá el costo del próximo proyecto. ¿Cuál es el próximo proyecto? ¿Cuáles son las necesidades? ¿Cuáles son los factores que influyen en varios aspectos? ¿Quién sabría todo esto en este momento? Si realmente desea reutilizar, debe extraer las piezas reutilizables una vez completado el proyecto, modificarlas y optimizarlas y utilizarlas como activos reutilizables de la empresa, en lugar de hacer ilusiones en el proyecto actual. Considere la reutilización fuera del proyecto. Este es un error común que cometen muchos programadores que son nuevos en el trabajo del software. A menudo, cuanto más piensan en ello, el software que crean no logra el efecto de diseño y no completa las funciones básicas. Procesos lógicos de código. Muchos, las funciones del programa no son perfectas, etc.
2. Verifique con frecuencia la estructura del proyecto.
La arquitectura del proyecto suele ser algo que se determina antes de que comience la implementación del proyecto y es un diseño general. Sin embargo, en este momento, la comprensión de los requisitos del proyecto y la estimación de la complejidad aún se encuentran en una etapa inicial. Si la arquitectura no se puede mejorar junto con la comprensión del proyecto durante el proceso de desarrollo del proyecto, los miembros del proyecto inevitablemente desarrollarán el proyecto de acuerdo con la arquitectura incorrecta. Por lo tanto, la arquitectura del proyecto debe verificarse con frecuencia y realizarse las refactorizaciones necesarias.
3. Refactorización
Algunas personas dicen que después de escribir tanto, revisarlo no es una pérdida de tiempo. Quizás no pensó que una tarde de refactorización podría acelerar el desarrollo en los próximos meses. El tiempo ahorrado es inimaginable. Además, a través de la refactorización, generalmente se pueden pensar en métodos más simples para reemplazar la implementación existente. Esta experiencia también puede simplificar el desarrollo de otros módulos.
4. Evite la integración excesiva y deje que cada módulo haga solo lo suyo.
Un ejemplo común de desarrollo de OA es que generalmente hay muchas aprobaciones en los sistemas comerciales y muchas personas pensarán inmediatamente en convertir las aprobaciones en un módulo universal. No hay ningún problema con esto, pero el problema habitual es que demasiadas personas colocan el procesamiento comercial después de la aprobación en la lógica comercial del módulo de aprobación. De hecho, esos son los módulos comerciales de cada módulo comercial, y la aprobación solo debería realizarse. se completará una vez que se complete la aprobación. Sin embargo, en cuanto a qué hacer después de que se complete la aprobación, deje que el módulo que realiza este proceso lo maneje por sí solo.
5. Evite ser demasiado flexible
El diseño y el código no siempre son lo más flexibles posible. Un ejemplo común es que cuando se usan genéricos, las clases o métodos pueden operar en diferentes objetos. Sin embargo, en la arquitectura de tres niveles comúnmente utilizada en JAVA, si una serie de clases están originalmente destinadas a operar en una entidad específica, no hay necesidad. Especificarlo como un tipo genérico y luego especificarlo para usar una clase de entidad específica cuando lo use. Esto parece superfluo.
6. Reducir las características de la guinda del pastel.
La falta de actualización de página, efectos de visualización más frescos, etc. son la guinda del pastel para el sistema empresarial. Si la interfaz empresarial es muy complicada debido a esto, traerá una serie de problemas al procesamiento empresarial. En casos extremos, el procesamiento empresarial no puede. No importa lo hermosa que sea la interfaz, es inútil cuando continúas. Cuando se trata de un consejo, sólo considere los demás si desea asegurarse de que el proceso comercial se realice correctamente. Un requisito previo para esto es la necesaria comunicación con los usuarios. En otras palabras, los proyectos implementados por JAVA se centran en el procesamiento empresarial. Sólo cuando el procesamiento empresarial se realiza bien se puede tener en cuenta la belleza de la interfaz y el sentido visual del usuario.
7. Dividir adecuadamente
Esto es similar a 4. Intenta reducir al máximo la complejidad de cada módulo y convierte el trabajo mental en trabajo físico. Un ejemplo común es que un formulario suele tener las funciones de agregar, modificar, eliminar y visualizar. Sin embargo, las primeras tres operaciones generalmente solo las realizan personas en un determinado punto de función, en un estado específico y con permisos específicos (quizás solo en la única interfaz del sistema). Sin embargo, las operaciones de visualización se distribuirán en todos los rincones del proyecto. Si estas cuatro operaciones se colocan en la misma interfaz, aunque se puede reducir el número de interfaces, lo que aumentará es la complejidad de esta interfaz. Procese los juicios necesarios para realizar configuraciones de solo lectura para los elementos de la interfaz. El aumento en la complejidad es exponencial y, si divide la vista, la carga de trabajo será lineal. Incluso si tiene que crear 10 interfaces de vista, la complejidad será. más alto que el anterior, es mucho más fácil lidiar con convertirlo en 10 * 10, y también se puede componer.
8. Mantener una buena comunicación con los clientes.
Mucha gente no presta atención a mantener la comunicación con los clientes. Muchos arquitectos creen que la comunicación y la comunicación con los clientes solo son necesarias durante la fase de demanda del proyecto. Este es un muy mal hábito, porque los requisitos del cliente cambiarán con el tiempo. en el entorno Sólo manteniendo una buena comunicación con los clientes de forma regular podemos comprender los cambios en las necesidades de los clientes lo antes posible, ajustando así nuestro plan de estructura de proyecto para satisfacer las necesidades de los clientes en el menor tiempo posible.
9. La conexión entre la arquitectura del proyecto y la arquitectura de la base de datos.
Mucha gente cree que una base de datos no es necesaria durante el desarrollo del proyecto, siempre que esté implementada en la memoria. Personalmente creo que este es un muy mal hábito de desarrollo. Aunque la base de datos se determina según las necesidades específicas del proyecto. Sin embargo, si un proyecto no considera la arquitectura de la base de datos en absoluto durante el proceso de arquitectura, es probable que las cosas implementadas en el proyecto sean difíciles de registrar en la base de datos o que el diseño de la base de datos sea muy problemático, lo que prácticamente aumentará la Dificultad para el desarrollo del proyecto. Además, no considerar la base de datos durante el proceso de desarrollo del proyecto puede causar problemas como la imposibilidad de implementar alguna lógica empresarial, pérdida de datos, etc. una vez que el proyecto se vincula a la base de datos.
Por supuesto, muchas personas tienen diferentes opiniones arquitectónicas según sus diferentes estilos arquitectónicos, y mi opinión puede no ser correcta. Espero que todos puedan aprender algo de mis cosas y también espero que todos puedan compartir sus puntos de vista sobre la arquitectura.