El sabor del buen código: estrategia
El siguiente es el texto:
Hasta el día de hoy, el atributo más importante del código es que sirve como lenguaje para comunicarse e intercambiar ideas entre programadores.
En otras palabras, el propósito del código es, en primer lugar, la comunicación entre personas y, en segundo lugar, la comunicación entre personas y máquinas. Para que pueda leer el código como lo haría con una novela, un ensayo o una poesía.
Citando la descripción del código limpio del fundador de UML, Grady Booch, como evidencia:
En algún momento, hace unos años, tuve una epifanía sobre este concepto. Desde entonces, ajusto el color del IDE. esquema que va desde el negro intenso y geek hasta el blanco cálido y brillante.
Más cerca de casa, ya que estamos hablando de programación como escritura, creo que lo más importante de un buen artículo es "una jerarquía clara y una intención clara".
El código escrito por muchas personas es muy agotador de leer. La razón principal es que el código en diferentes niveles de abstracción se mezcla, lo que hace que las personas salten de un lado a otro entre niveles de abstracción superiores e inferiores. if Es como saltar escaleras arriba y abajo en la vida real.
Por ejemplo, antes de salir, ponerse ropa y pantalones, aflojar el cordón izquierdo-estirar el pie izquierdo-atar el cordón izquierdo, aflojar el cordón derecho-estirar el pie derecho-atar el cordón derecho. Esta es una combinación típica de abstracción de alto nivel y abstracción de bajo nivel.
Además de esta situación que puede existir con la lógica empresarial, también puede existir el mismo problema con las estructuras de datos. Por ejemplo, un DTO que representa la entidad de una persona incluye nombre, sexo, edad, etc. Si de repente se agregan seis campos como provincia, ciudad, distrito, calle y número de casa, habrá probabilidades correspondientes, especialmente provincia y ciudad. , esto alteraría el nivel de abstracción y la forma correcta de manejarlo es fusionar estos seis campos en el concepto más abstracto de una dirección.
El segundo tipo de código que puede resultar agotador de leer es el código en el que la lógica técnica y la lógica empresarial se mezclan, lo que significa que la intención no está clara.
Pero lo más frecuente es que la lógica empresarial del código que escribimos no sea lo suficientemente clara e incluso cuando miremos el código, estaremos completamente perdidos en un montón de detalles técnicos.
Es como si quisieras comer un trozo de carne y luego pedir un plato de carne frita con pimientos verdes. Cuando llega, te encuentras con pimientos verdes por todas partes y tienes que recoger el tuyo. palillos y hurgamos para encontrarlos un poco de carne picada.
En el código, las operaciones comunes como try/catch, lock/unlock y null entran en esta categoría.
Para darle un ejemplo aleatorio, he visto llamadas RPC que primero realizan autenticación, luego descifran el resultado y luego extraen una Lista de los DTO anidados para determinar si está vacía paso a paso. y finalmente determine si la Lista está vacía y si el número de elementos es mayor que 1, y luego elimine los elementos. Hay algunas impresiones de registros y otros códigos mezclados. Una función ocupa toda la pantalla y la lógica central puede ser solo una línea.
¿Qué se debería hacer mejor? En este momento, es hora de imitar a otros restaurantes de hot pot. ¿Por qué un restaurante de hot pot? Por ejemplo, si pides un plato de callos frescos, en términos generales, solo hay unas pocas rebanadas, pero la gente pone media olla de hielo en el fondo de la olla, lo que se dice que los mantiene frescos. Aunque sea odioso hacerlo, es lo que pediste y lo que pusieron en el lugar más destacado para ti.
El código es el mismo, pero este ejemplo es en realidad un muy buen enfoque desde un punto de vista técnico. No es el código lo que está mal, es la ubicación incorrecta del código.
En términos de soluciones, utilizar conceptos de AOP es una buena solución.
Mencionado en "El camino del código limpio":
Además, personalmente recomiendo usar el método de escritura de Spring. Por ejemplo, si tiene una función llamada createBean, entonces habrá. También suele haber una función llamada doCreateBean que pone la lógica en doXXX.
Estos son algunos de mis pensamientos sobre cómo escribir código excelente estratégicamente.
A menudo decimos que la legibilidad es la piedra angular de un buen código, y si ni siquiera puedes leer el código, no hay posibilidad de escalabilidad o capacidad de prueba.
En este sentido, programar es como escribir. Creo que si puedes escribir código que cumpla con los criterios de "jerarquía clara e intención clara", definitivamente pasarás la prueba de legibilidad. Al mismo tiempo, el marco general del código no puede ser tan malo.
En artículos posteriores, iremos añadiendo gradualmente más detalles a este marco. Por ejemplo, cómo saber de qué estás hablando y cómo mantener las funciones breves. También continuaremos agregando artículos sobre escalabilidad y capacidad de prueba, así que estad atentos.