Especificación del manual de desarrollo de Ali (JAVA)

Tabla de contenido

1. Protocolo de programación 

(1) Convención de nomenclatura

(2) Definición constante

(3) Formato de código 

(4) protocolo de programación orientada a objetos

(5) Fecha y hora

(6) Procesamiento de cobro 

(7) Procesamiento concurrente

(8) Declaración de control

(9) Notas y Estatutos

(10) Protocolos de front-end y back-end

2. Registro de excepciones 

(1) Código de error

(2) Manejo de excepciones

(3) protocolo de registro 

3. Pruebas unitarias 

4. Normas de seguridad

5. Base de datos MySQL 

(1) Protocolo de creación de tablas

(2) Protocolo de índice 

(3) instrucción SQL

(4) mapeo ORM

6. Estructura de ingeniería 

(1) Capas de aplicación

(2) Dependencias de bibliotecas de terceros 

(3) servidor 

7. Reglamento de Diseño 


1. Protocolo de programación 

(1) Convención de nomenclatura

1. Ningún nombre en el código puede comenzar con un guión bajo o un signo de dólar, ni puede terminar con un guión bajo o un signo de dólar. Contraejemplo : _nombre / __nombre / $nombre / nombre_ / nombre$ / nombre__.

2. Está prohibido mezclar pinyin e inglés. Ejemplo de contador : DaZhePromotion [descuento] / getPingfenByName() [puntuación].

3. Los nombres de clase utilizan el método de denominación de mayúsculas y minúsculas, los nombres de métodos, los nombres de parámetros, las variables miembro y las variables locales utilizan el método de denominación de mayúsculas y minúsculas.

4. Los nombres de las constantes están en mayúscula y las palabras están separadas por guiones bajos, por ejemplo : MAX_STOCK_COUNT / CACHE_EXPIRED_TIME.

5. El tipo va seguido de corchetes para indicar una matriz. Ejemplo : Definir una matriz de enteros int[] arrayDemo. 

6. Para las variables de tipo booleano, no comience con para evitar errores en el marco de serialización parcial. Contraejemplo : booleano isExists.

7. Poner fin a las abreviaturas completamente no estándar para evitar la ignorancia del significado. Contraejemplo : AbstractClass se "abrevia" en AbsClass; condition se "abrevia" en condi.

8. Para las clases Servicio y DAO, debe ser una interfaz y la implementación debe terminar con el sufijo de Impl. Diferente de interfaces
como: CacheService CacheServiceImpl.

9. El nombre de la clase de enumeración tiene el sufijo Enum, y los nombres de los miembros de la enumeración deben estar en mayúsculas y las palabras deben estar separadas por guiones bajos. 

10. No agregue ningún modificador a los atributos y métodos en la interfaz de clase.

(2) Definición constante

1. No permita que ningún valor mágico (es decir, constantes que no estén predefinidas) aparezca directamente en el código.  Ejemplo negativo : clave de cadena = "id=" + id;

2. Cuando se asigna inicialmente long y Long, se deben usar mayúsculas para evitar confusiones con el número 1.
Ejemplo : Long a = 2L    Contraejemplo : Long a = 2l

3. No utilice una clase constante para mantener todas las constantes, divídalas y clasifíquelas de acuerdo con funciones tanto como sea posible, y manténgalas por separado. Fácil de entender y mantener.

(3) Formato de código 

1. Si las llaves están vacías, simplemente escriba {}, y no hay necesidad de nuevas líneas ni espacios entre las llaves, si es un bloque de código no vacío: (1) No hay nueva línea antes de la llave izquierda, y una nueva línea después de la llave izquierda. (2) Salto de línea antes de la llave de cierre.  

2. No hay espacio entre el paréntesis izquierdo y el carácter siguiente, y no hay espacio entre el paréntesis derecho y el carácter anterior
Ejemplo : si (bandera == 0).

3. Se deben agregar espacios entre las palabras reservadas como si/para/mientras/cambiar/hacer y los corchetes. 

4. Cualquier operador binario y ternario necesita agregar un espacio en los lados izquierdo y derecho. 

5. Solo hay un espacio entre las barras dobles del comentario y el contenido del comentario. 

6. Cuando se definen y pasan parámetros de método, se deben agregar espacios después de las comas para varios parámetros. Ejemplo : método("a", "b", "c");

(4) protocolo de programación orientada a objetos

1. Use el nombre de la clase directamente para acceder a las variables estáticas o métodos estáticos de una clase.

2. Todos los métodos de anulación deben anotarse con @Override para determinar con precisión si la anulación es exitosa.

3. Las interfaces externas deben evitar modificaciones en principio, y se pueden agregar nuevas interfaces. Las interfaces obsoletas deben anotarse con @Deprecated

4. El método equals de Object es fácil de lanzar una excepción de puntero nulo, y debe usar una constante o un objeto que seguramente tenga un valor para llamar a equals. Ejemplo : "prueba".equals(objeto); 

5. Todas las comparaciones de valores entre objetos envolventes de enteros se compararán utilizando el método de igualdad. Si se utiliza == para el juicio, habrá un límite para el rango de valores.

6. Concatenación de cadenas en el cuerpo del ciclo, utilizando el método de adición de StringBuilder.

7. Está prohibido agregar cualquier lógica comercial en el método de construcción. Si hay una lógica de inicialización, póngala en el método init. 

8. Para el juicio de equivalencia entre números de coma flotante, el tipo de datos básico no se puede comparar con ==, y el tipo de datos del paquete no se puede juzgar con iguales. 

(5) Fecha y hora

1. Al formatear la fecha, la y minúscula se usa uniformemente para representar el año en el patrón entrante. 

2. Obtenga los milisegundos actuales: System.currentTimeMillis(); en lugar de new Date().getTime(). 

(6) Procesamiento de cobro 

1. Siempre que se reescriba equals, se debe reescribir hashCode.

2. Para juzgar si todos los elementos de la colección están vacíos, utilice el método isEmpty() en lugar del método size()==0.

3. El resultado del método subList de ArrayList no se puede convertir en ArrayList. (subList devuelve la clase interna de ArrayList, no ArrayList, y es una vista de ArrayList. Todas las operaciones en SubList se reflejarán en la lista original de ArrayList).

4. Para usar el método de colección a matriz, debe usar la matriz toArray(T[] de la colección).

5. No elimine/agregue elementos en el bucle foreach. Utilice el método Iterator para eliminar elementos. Si la operación se realiza al mismo tiempo, debe bloquear el objeto Iterator. 

6. Al usar la clase de herramienta Arrays.asList() para convertir una matriz en una colección, no se pueden usar métodos relacionados con la modificación de la colección, como: agregar/eliminar/borrar arrojará una excepción UnsupportedOperationException.

(7) Procesamiento concurrente

1. La obtención de un objeto singleton debe garantizar la seguridad de subprocesos, y los métodos que contiene también deben garantizar la seguridad de subprocesos. 

2. Los recursos de subprocesos se deben proporcionar a través del grupo de subprocesos, y no está permitido crear subprocesos explícitamente en la aplicación, para evitar crear demasiados subprocesos y reducir la sobrecarga de creación y destrucción de subprocesos.

3. Los grupos de subprocesos no se pueden crear mediante ejecutores, sino a través de ThreadPoolExecutor. La desventaja de los objetos de grupo de subprocesos devueltos por los ejecutores es que se puede crear una gran cantidad de subprocesos o se puede acumular una gran cantidad de solicitudes, lo que resulta en OOM .

4. Para la concurrencia, considere la pérdida de rendimiento de los bloqueos. Si puede bloquear sin bloquear, no necesita un bloqueo; si puede bloquear un bloque, no bloquee todo el método; si puede bloquear un objeto, no bloquee una clase.

5. Al bloquear varios recursos, tablas de bases de datos y objetos al mismo tiempo, es necesario mantener una secuencia de bloqueo coherente, de lo contrario, puede producirse un punto muerto.

6. Si la probabilidad de conflicto de acceso no es alta, se recomienda utilizar el bloqueo optimista.

7. Cuando la capacidad de HashMap no es suficiente para cambiar el tamaño, debido a la alta concurrencia, puede haber un enlace muerto, lo que hace que la CPU se dispare. Preste atención para evitar este riesgo durante el proceso de desarrollo. 

8. Se recomienda utilizar la modificación estática para el objeto ThreadLocal

(8) Declaración de control

1. En el bloque de interruptores, cada caso finaliza con un descanso/retorno, o un comentario indica qué caso se ejecutará; un interruptor debe contener valores predeterminados, incluso si está vacío.

2. Cuando el tipo de variable entre paréntesis del interruptor es Cadena y esta variable es un parámetro externo, primero se debe realizar un juicio nulo.

3. Deben usarse llaves en declaraciones if/else/for/while/do. 

4. En escenarios de alta simultaneidad, evite usar juicios "igual a" como condiciones de interrupción o salida. Contraejemplo : cuando se considera que el número restante de premios es igual a 0, la distribución de premios finaliza, pero debido a un error de procesamiento concurrente, el número de premios se vuelve negativo instantáneamente. En este caso, la actividad no puede ser terminado. 

(9) Notas y Estatutos

1. Los comentarios sobre clases, atributos de clase y métodos de clase deben usar la especificación Javadoc, usar el formato /**content*/ y no usar el método // xxx.

2. Todos los métodos abstractos (incluidos los métodos en las interfaces) deben anotarse con Javadoc

3. Todas las clases deben agregar creador y fecha de creación. 

(10) Protocolos de front-end y back-end

1. La API para la interacción de front-end y back-end debe especificar el protocolo, el nombre de dominio, la ruta, el método de solicitud, el contenido de la solicitud, el código de estado y el cuerpo de la respuesta.

2. Se devuelve la interfaz relacionada con las listas de datos de front-end y back-end.Si está vacía, se devolverá una matriz vacía [] o una colección {} vacía. 

3. Cuando se produce un error en el lado del servidor, la información de respuesta devuelta al front-end debe incluir cuatro partes: código de estado HTTP, código de error, mensaje de error e información de solicitud de usuario.

2. Registro de excepciones 

(1) Código de error

1. El código de error no refleja el número de versión ni la información del nivel de error. 

2. El código de error no se puede enviar directamente al usuario como un mensaje de aviso. 

(2) Manejo de excepciones

1. No detecte las excepciones de tiempo de ejecución heredadas de RuntimeException. Estas excepciones deben verificarse y evitarse por sí mismas, como: IndexOutOfBoundsException / NullPointerException.

2. No lo use para control de procesos o control condicional después de que se detecte la excepción. 

3. El propósito de capturar una excepción es manejarla. No la capture, sino deséchela sin procesar nada. Si no desea manejarla, envíe la excepción a quien la llamó.

4. El bloque finalmente debe cerrar el objeto de recurso y el objeto de flujo, e intentar capturar si hay una excepción, no use retorno en el bloque finalmente. 

(3) protocolo de registro 

1. No use la clase de implementación de registro, pero use la interfaz API de SLF4J, use el modo de fachada y es fácil lograr un método de procesamiento de registro unificado para todas las clases.

2. Todos los archivos de registro se conservan durante al menos 15 días, ya que algunas anomalías tienen características de frecuencia de aparición "semanal".

3. Para evitar la impresión repetida de registros y el desperdicio de espacio en disco, asegúrese de configurar additivity=false en el archivo de configuración de registro. 

4. Al imprimir registros, está prohibido usar herramientas JSON directamente para convertir objetos en cadenas.

3. Pruebas unitarias 

1. Una buena prueba unitaria debe cumplir con el principio AIR, es decir, tiene las características de automatización, independencia y repetibilidad.

2. Las pruebas unitarias pueden ejecutarse repetidamente y no pueden verse afectadas por el entorno externo. 

3. Mantenga las pruebas unitarias independientes. Para garantizar que las pruebas unitarias sean estables, confiables y fáciles de mantener, los casos de prueba unitaria no deben llamarse entre sí, ni pueden depender del orden de ejecución. 

4. Normas de seguridad

1. Las páginas o funciones que pertenecen al usuario deben someterse a verificación de control de permisos. 

2. Está prohibida la visualización directa de datos confidenciales del usuario, y los datos de visualización deben ser insensibilizados. 

3. Los parámetros SQL ingresados ​​por el usuario están estrictamente limitados por el enlace de parámetros o los valores del campo METADATA para evitar la inyección SQL y prohibir el empalme de cadenas SQL para acceder a la base de datos. 

4. Los formularios y envíos de AJAX deben realizar una verificación de seguridad CSRF. 

5. Base de datos MySQL 

(1) Protocolo de creación de tablas

1. El campo que expresa el concepto de sí o no debe nombrarse en forma de is_xxx, y el tipo de datos es tinyint sin signo (1 significa sí, 0 significa no). 

2. El nombre del campo del nombre de la tabla debe usar caracteres en minúscula o números, el comienzo de un número está prohibido y solo los números entre dos guiones bajos están prohibidos. Ejemplo : aliyun_admin, rdc_config, level3_name.

3. Deshabilite las palabras reservadas, como desc, rango, partido, retrasado, etc.

4. Los nombres de las tablas no usan sustantivos en plural. 

5. El nombre de índice de clave principal es pk_field name, el nombre de índice único es uk_field name, el nombre de índice común es idx_field name. Nota: pk_ es la clave principal; uk_ es la clave única; idx_ es la abreviatura de index. 

6. El tipo decimal es decimal, y float y double están prohibidos. 

7. Si las longitudes de las cadenas almacenadas son casi iguales, utilice el tipo de cadena de longitud fija char.

8. Varchar es una cadena de caracteres de longitud variable y la longitud no debe exceder los 5000. Si la longitud de almacenamiento supera este valor, use texto y enumérelo de forma independiente.

9. La tabla debe tener tres campos: id, create_time, update_time. 

(2) Protocolo de índice 

1. Los campos con características únicas en los negocios, incluso los campos compuestos, deben integrarse en un índice único. 

2. Está prohibido unirse a más de tres mesas. Los tipos de datos de los campos que deben unirse deben ser absolutamente consistentes; cuando se realizan consultas de asociación de varias tablas, asegúrese de que los campos asociados deben tener índices.

3. Al crear un índice en un campo varchar, se debe especificar la longitud del índice. No es necesario crear un índice para todo el campo, y la longitud del índice se determina de acuerdo con la discriminación de texto real. 

4. El desenfoque izquierdo o el desenfoque total están estrictamente prohibidos.

5. Utilice el índice de cobertura para realizar operaciones de consulta para evitar volver a la tabla. 

(3) instrucción SQL

1. No use count (nombre de columna) o count (constante) para reemplazar count (*). count (*) es la sintaxis estándar para contar filas definida por SQL92, que no tiene nada que ver con la base de datos y no tiene nada que ver con hacer con NULL y no NULL. 

2. Cuando todos los valores de una columna son NULL, el resultado devuelto de count(col) es 0, pero el resultado devuelto de sum(col) es NULL, así que preste atención al problema de NPE cuando use sum(). 

3. Evite la operación in si se puede evitar. Si es realmente inevitable, debe evaluar cuidadosamente la cantidad de elementos establecidos detrás de la entrada y controlarla dentro de 1000. 

(4) mapeo ORM

1. En la consulta de la tabla, nunca use * como la lista de campos de la consulta, y se deben indicar claramente qué campos son obligatorios.

2. El atributo booleano de la clase POJO no puede agregar is, pero el campo de la base de datos debe agregar is_, lo que requiere la asignación entre campos y atributos en resultMap. 

3. Uso de los parámetros de configuración de sql.xml: #{}, #param# No use ${} Este método es propenso a la inyección de SQL.

4. Al actualizar un registro de la tabla de datos, el valor del campo update_time correspondiente al registro debe actualizarse al mismo tiempo que la hora actual. 

6. Estructura de ingeniería 

(1) Capas de aplicación

1. Especificación del modelo de dominio jerárquico: 
• DO (objeto de datos): este objeto tiene una correspondencia uno a uno con la estructura de la tabla de la base de datos y el objeto de fuente de datos se transmite hacia arriba a través de la capa DAO. 
• DTO (objeto de transferencia de datos): objeto de transferencia de datos, el objeto que transfiere el servicio o el administrador. 
• BO (Objeto comercial): objeto comercial, un objeto que encapsula la lógica comercial que puede generar la capa de servicio. 
• Consulta: objeto de consulta de datos, cada capa recibe la solicitud de consulta de la capa superior. Preste atención a la encapsulación de consultas con más de 2 parámetros, está prohibido usar la clase Map para transferir. 
• VO (objeto de visualización): objeto de capa de visualización, generalmente el objeto transmitido desde la Web a la capa del motor de representación de la plantilla. 

(2) Dependencias de bibliotecas de terceros 

1. El método de denominación del número de versión de la biblioteca de terceros: número de versión principal, número de versión secundaria, número de revisión.

2. El tipo de enumeración se puede definir en la biblioteca de terceros y el parámetro puede usar el tipo de enumeración, pero el valor de retorno de la interfaz no permite el uso del tipo de enumeración o los objetos POJO que contienen el tipo de enumeración. 

3. Cuando se confía en un grupo de bibliotecas de terceros, se debe definir una variable de versión unificada para evitar números de versión inconsistentes. 

4. Está prohibido tener el mismo GroupId, el mismo ArtifactId, pero diferentes Versiones en las dependencias pom de los subproyectos.

(3) servidor 

1. Para servidores de alta concurrencia, se recomienda reducir el tiempo de espera time_wait del protocolo TCP.

2. Establezca el parámetro -XX:+HeapDumpOnOutOfMemoryError en el parámetro de entorno de JVM para permitir que la salida de JVM descargue información cuando encuentre una escena OOM.

7. Reglamento de Diseño 

1. En la etapa de análisis de requisitos, si hay más de un tipo de Usuario interactuando con el sistema y más de cinco Casos de Usuario relacionados, utilice un diagrama de casos de uso para expresar requisitos estructurados más claros. 

2. Si un objeto comercial tiene más de 3 estados, utilice un diagrama de estado para expresar y aclarar cada condición desencadenante del cambio de estado.

Supongo que te gusta

Origin blog.csdn.net/weixin_51360584/article/details/128098109
Recomendado
Clasificación