Cómo evitar la codificación estricta en el desarrollo

Al desarrollar el sistema interno de una empresa antes, por un lado, el tiempo era escaso y el trabajo preliminar no estaba completamente preparado. Por otro lado, las especificaciones del trabajo de codificación y acoplamiento empresarial no se realizaron muy bien. , lo que resultó en que el sistema solo permaneciera en un estado utilizable.

El mayor problema es la escalabilidad. Todo el desarrollo utiliza el siguiente modelo:

SpringBoot + shiro + MyBatis + easyPoi + Layui + Mysql5.7 (posteriormente actualizado a 8.0) + Redis + RabbitMQ.

No existe separación entre los extremos delantero y trasero. En realidad, están bien. El problema es que hay mucha codificación rígida en el código, lo que hace que no sea amigable para respaldar la expansión comercial posterior.

PD: ¿Se puede echar la culpa al desarrollo ágil? ¡No! ¡No es por mi propia comida! ! !

Ha habido algunos cambios en el negocio recientemente, por lo que hay un problema general con estas partes codificadas: ¡No, no admitimos esto!

Sin embargo, el negocio no puede detenerse y esperar a otros, y el cronograma de reconstrucción del proyecto llega relativamente tarde, por lo que por el momento, los ajustes solo se pueden realizar en el sistema original.

La codificación rígida mencionada aquí no es el procesamiento de codificación rígida de la computadora, sino la codificación rígida a nivel de código durante la programación de software (en pocas palabras, es un código rígido que no admite flexibilidad).

PD: Este es solo un ejemplo de pseudocódigo, ¡pruébalo!

① Codificación rígida en el procesamiento de condiciones

Java

② Codificación rígida en el procesamiento de información

Java

③ Codificación rígida en el valor de retorno

Java

④ Codificación rígida en el valor del atributo

Java

PD: simplemente siga la toma anterior cuatro situaciones como ejemplos.

① Es fácil provocar que las condiciones no coincidan, lo que resulta en la imposibilidad de ingresar la condición.

Por ejemplo: cuando el proyecto es mantenido por un reemplazo o conectado al front-end, escribe "inspección independiente" al llamar a Completado”

② ¿Esta tarea solo puede ser completada por Xiao Ming? ¿Xiao Ming solo puede completar la tarea A aquí? ¡Xiaohua, quiero completar la tarea B!

③ Xiao Ming: ¿Solo puedo ser un pequeño supervisor en esta vida? ¡Mira quién no puede permitírselo!

④ Baidu: Nuestro proyecto ha sido ajustado y ahora la interfaz se ha cambiado a: :8089/orderAdd

¡Las desventajas de la codificación rígida son tan aterradoras!

PD: Al mismo tiempo, no podemos simplemente pensar que la codificación rígida es mala. No codifique al escribir pruebas unitarias. Para algunos valores fijos (masculino, femenino, desconocido), la codificación sigue siendo útil durante el desarrollo rápido. Simplemente significa que puede haber algunos malos olores en el desarrollo formal... / p>

Dado que se manejan todos los módulos del sistema, resolver los problemas no es complicado.

Debido a que algunos problemas objetivos solo pueden eliminar el 90% de las partes codificadas esta vez, la mejora de todo el proyecto dependerá temporalmente de la reconstrucción posterior del proyecto. Al mismo tiempo, el 90% de la transformación de codificación ya puede satisfacer las necesidades actuales y ser más amigable para la escalabilidad posterior. Este artículo se basa en la idea de no perseguir el perfeccionismo extremo y cierta experiencia en toda la mejora.

En el escenario 2 anterior, si tanto el nombre como la tarea se tratan como parámetros de entrada, es fácil implementar funciones como: Xiaohua completó la tarea C.

La clase de enumeración es fácil de expandir y también puede estandarizar datos. En el escenario uno anterior, escribir el estado como una clase de enumeración puede resolver fácilmente el problema de los errores de estado y la expansión del estado.

PD: ¡Nunca des clases de enumeración directamente al front-end, porque no sigues el código ético!

Tomando SpingBoot como ejemplo, podemos poner algunas propiedades que se usan comúnmente y son difíciles de configurar en Xml o Yml, y luego usar la anotación @Value en el código para usarlas.

De esta forma, no importa cómo cambien los cuatro escenarios, podemos modificarlo directamente en el archivo de configuración, ¡y solo modificar un lugar!

PD: la anotación @Value no se puede modificar con estática

En los tres escenarios anteriores, podemos configurar la información de Xiao Ming en la base de datos y luego leer la información de la base de datos cuando la usamos. .

De esta manera, Xiao Ming no tendrá problemas para ser ascendido, conseguir un aumento, convertirse en director ejecutivo y casarse con Bai Fumei.

(¡Afirmación de Xiao Ming!)

De hecho, en general estos son causados ​​por malos hábitos de codificación o solo considerando el presente sin cometer errores en la expansión posterior.

¡Espero que todos podamos escribir un código hermoso y ser un buen desarrollador que respete la ética del código!

PD: ¡La familiaridad con la limpieza del código debe incluirse en la agenda! ! !