Una revisión del desarrollo de sistemas de gestión bibliotecaria (desde la perspectiva de un diseñador)

Ha pasado casi un mes desde que comenzaron las clases. La primera vez trabajé en un proyecto pequeño: un sistema de gestión de bibliotecas. Es muy pequeño, pero aprendí mucho con él, no solo entregando tareas, sino consolidando conocimientos y sentando una base sólida. uno. Estándares de programación Estándares de programación Aquí es donde más me siento. Los proyectos de desarrollo corporativo de hoy ya no se pueden realizar solos. Requieren división del trabajo y trabajo en equipo. Los miembros del equipo deben leer el código de los demás. Además, una vez desarrollado un sistema, no es necesario utilizarlo una vez, sino que se debe actualizar y mantener continuamente para satisfacer las necesidades cambiantes de los usuarios. En este proceso, es posible que no lo complete usted, sino otros, lo que requiere que cualquiera lea y comprenda su código de forma independiente, por lo que el valor de los estándares de programación se refleja naturalmente en este momento. Por este motivo, el código debe escribirse de conformidad con los estándares y especificaciones de la industria. Por ejemplo, los comentarios en el documento deben entenderse claramente y las funciones, nombres, parámetros y valores de retorno de clases y métodos deben resumirse en detalle de la siguiente manera: (1). El nombre del paquete debe reflejar las funciones del sistema que desea desarrollar y el nombre del paquete debe estar claramente dividido en cuatro capas. Generalmente, el nombre de dominio de la empresa debe escribirse al revés. En otras palabras, este sistema de gestión de bibliotecas puede utilizar el nombre de dominio de nuestra escuela cn.edu.hevttc en su conjunto, más el nombre del sistema book, seguido de los nombres de cada capa, como cn.edu.hevttc.book..ui ( capa de presentación) y cn.edu.hevttc.book.service (capa de servicio). Cn.edu.hevttc.book.dao (capa de persistencia), cn.edu.hevttc.book.domain (este paquete coloca principalmente clases de entidad y tablas de mapeo en la base de datos), también puede tener un paquete: cn.edu. TTC .book . util, que contiene clases de herramientas que pueden ser utilizadas por todo el sistema. Tenga en cuenta también que los nombres de los paquetes deben estar en minúsculas. (2) Denominación de clases, métodos, variables y controles 1. Los nombres de las clases deben ser sustantivos, no verbos, con la primera letra en mayúscula y las palabras separadas por letras mayúsculas. Por ejemplo, esta es una interfaz de capa de servicio, servicio de libro de interfaz pública {. Los métodos generalmente se nombran con la primera palabra como un verbo seguido de un sustantivo. El verbo debe estar en minúscula y la primera letra del sustantivo debe estar en mayúscula. Por ejemplo: cadena pública getNextID(){

............} 3. El nombre de la variable suele ser el mismo que el nombre del método. 4. En VE, la denominación de un control generalmente va precedida por el tipo de control + el significado de la función a completar. Por ejemplo, denominación de etiqueta: lblResults denominación de botón: btnSubmit puede hacer referencia a la convención de nomenclatura de control. neto. Nota: En términos generales, no importa qué aspecto se nombre, debe reflejar el significado de la función que desea completar, de modo que cualquier programador que vea su código pueda "conocer su significado por su nombre". Esto es lo más importante, refleja directamente la legibilidad del código y es una parte integral de la especificación de programación. (3) Las notas de las preguntas anotadas deben entenderse en detalle. La calidad de los comentarios de la documentación se refleja directamente en la documentación de la API, porque otros quieren comprender las funciones de las clases de código, los métodos y las interfaces de la documentación de la API. Al comienzo de todo el documento, haga una declaración sobre derechos de autor, tiempo, etc. , y use /*…………………………………………*/ para completar la descripción de una función al comienzo de la clase, indicando qué tipo de función desea completar en esta clase; el método debe explicar la función, los parámetros, los valores de retorno y las posibles excepciones, los comentarios sobre las variables deben explicar el significado de las variables, los comentarios de la documentación deben colocarse en /* *.... */, solo se generarán aquellos colocados dentro de la documentación API. Nota: Si desea escribir un buen comentario, la forma más sencilla es consultar el código de la empresa Sun, porque tiene más autoridad. 1. Estructura jerárquica del diseño del sistema (estructura de cuatro capas) La calidad del diseño de un sistema está directamente relacionada con la durabilidad del sistema, porque el criterio para medir un buen sistema es si puede satisfacer las necesidades cambiantes de los usuarios y si puede cumplir con los requisitos de reutilización y escalabilidad. Para lograr este objetivo, las clases con las mismas funciones deben colocarse en el mismo paquete, es decir, en la misma capa. Estas capas no se llaman directamente, sino a través de interfaces, pero pueden estar estrechamente relacionadas entre sí para lograr una alta cohesión y un bajo acoplamiento. Esta vez tengo una comprensión más profunda de la importancia de la estructura de cuatro capas. Era la primera vez que lo jugaba libremente y, justo después de completar la función, las capas estaban demasiado conectadas y todas estaban apretadas. “Si cambias este lugar, tienes que cambiar aquel lugar.

Este tipo de mantenimiento de código requiere una gran cantidad de trabajo. La estructura de cuatro capas puede resolver muy bien este problema. Entonces, lo que aprendí es que debes diseñar bien antes de escribir código. El diseño es el punto clave. "El afilado de la espada mejora el cortador de leña." Un buen diseño puede obtener el doble de resultado con la mitad de esfuerzo. 2. Cuando las expresiones regulares implican verificación en el sistema, básicamente usé un método de bucle al principio, y el código era para..., si... De lo contrario... A través de la comunicación, descubrí un nuevo método, que son las expresiones regulares. Se entiende que las expresiones regulares se utilizan especialmente para la verificación. El uso de expresiones regulares puede reducir en gran medida la cantidad de código y hacerlo conciso y claro. La única dificultad, y la clave para escribir expresiones regulares, es escribir el patrón. Si escribes bien todo irá bien, pero muchas veces es difícil. Creo que hay muchas cosas que no entiendes y no es fácil entenderlas todas, por lo que a veces puedes tomar prestados los logros ya hechos de otras personas y es mejor usarlos. Por ejemplo, la verificación de la fecha no se puede entender en tres o dos días. Puede copiarla en línea, pero intente dominar más puntos de conocimiento durante la etapa de capacitación. Originalmente quería resumir las funciones comúnmente utilizadas de las expresiones regulares, pero luego no hubo necesidad de pensar en ello porque están disponibles en la API. Lo que resumiste no se trata solo de la API. Las expresiones regulares se encuentran en el paquete java.util.regex. 4. La importancia de la depuración La función de depuración es muy útil e importante. A medida que aumenta el código, una vez que ocurre un error, no basta con preocuparse por él con los ojos y la eficiencia no es alta. La depuración es una herramienta eficaz para solucionar errores. Hay que aprender a utilizarlo habitualmente y acostumbrarse desde el inicio del entrenamiento.