La calidad es el sustento de un producto y la inspección del código es una parte vital del proceso de desarrollo de software. Puede ayudarnos a descubrir y corregir errores potenciales, mejorar la calidad del software y reducir los costos de mantenimiento.
Este problema también existe en los productos Kangaroo Cloud . Debido a los diferentes niveles de SQL de los desarrolladores de datos fuera de línea, la escritura del código es confusa y hay muchos problemas de ejecución de código SQL. Este artículo presentará cómo utilizar reglas de verificación SQL para estandarizar el código SQL en productos fuera de línea , interceptar problemas de escritura de código, facilitar la administración unificada y evitar la introducción de problemas que deben administrarse.
A través de la introducción de este artículo, esperamos que pueda darse cuenta de la importancia de la inspección del código y comprender cómo mejorar la calidad del código y la eficiencia del desarrollo mediante las mejores prácticas.
¿Cuándo se deben realizar las comprobaciones de las reglas del código?
Después de desarrollar la tarea SQL en la interfaz del producto fuera de línea , si hace clic en el botón Ejecutar, primero será verificada por las reglas del código. Si no se cumplen las reglas del código, se le indicarán al usuario motivos específicos.
El módulo de activos de datos tiene 5 reglas de inspección de código integradas , que los usuarios pueden activar selectivamente según sea necesario.
Después de activarlo, puede seleccionar los elementos de verificación de reglas de código , el alcance efectivo y el tipo de tarea SQL que se utilizarán en la gestión de proyectos fuera de línea .
Antes de ejecutar un SQL en una tarea SQL fuera de línea, el código se verificará de acuerdo con las reglas seleccionadas. Si la verificación del código falla, se le dará retroalimentación al usuario. El usuario puede juzgar si ejecutar el SQL de acuerdo con las necesidades reales.
En el tiempo de inspección del código de los activos de datos, puede ver el historial de inspecciones activadas y las estadísticas correspondientes.
¿Cómo implementar reglas de inspección de código?
Una interfaz de verificación de reglas de código común se define en el paquete CodeCheck.
public interface ICheck {
Result codeCheck(String checkContent, String defaultDb, Integer dataSourceType, Long tenantId, SqlParseInfo sqlParseInfo);
CodeCheckType getCheckType();
}
Tomando como ejemplo la consulta de la tabla de particiones que debe tener reglas de partición, primero se llamará al componente SQLParser para realizar el análisis SQL. SQLParseInfo es el resultado del análisis SQL. Durante la verificación, primero se juzgará si la declaración SQL es una declaración de consulta. Si es así, se juzgará si la tabla consultada es una tabla particionada, luego se determinará si existe una condición de consulta y, finalmente, se determinará si la condición de consulta contiene un campo de partición para determinar si se pasa la verificación.
public class CodeCheckImplType01 extends AbstractCheck {
private static final Logger LOGGER = LoggerFactory.getLogger(CodeCheckImplType01.class);
@Autowired
private DataTableColumnThirdService dataTableColumnThirdService;
@Autowired
private DataTableThirdService dataTableThirdService;
@Override
public Result codeCheck(String checkContent, String defaultDb, Integer dataSourceType, Long tenantId, SqlParseInfo sqlParseInfo) {
if (!isQuery(sqlParseInfo.getSqlType())) {
return Result.buildSuccessResult();
}
try {
MetadataSearchParam searchParam = new MetadataSearchParam();
searchParam.setDbName(sqlParseInfo.getMainTable().getDb());
searchParam.setTableName(sqlParseInfo.getMainTable().getName());
searchParam.setDataSourceType(dataSourceType);
searchParam.setTenantId(tenantId);
List<TableDTO> tableDTOS = dataTableThirdService.tableList(searchParam);
// 获取表信息
for (TableDTO tableDTO : tableDTOS) {
List<DataTableColumn> tableColumns = dataTableColumnThirdService.listColumnByTableIds(Lists.newArrayList(tableDTO.getTableId()));
if (CollectionUtils.isEmpty(tableColumns)) {
continue;
}
List<String> partitionColumnNameList = tableColumns.stream()
.filter(Objects::nonNull)
.filter(t -> HavePartitionEnum.have_partition.getPartitionValue().equals(t.getIsPartition()))
.map(DataTableColumn::getColumnName)
.collect(Collectors.toList());
// 非分区表直接返回
if (CollectionUtils.isEmpty(partitionColumnNameList)) {
continue;
}
if (CollectionUtils.isEmpty(sqlParseInfo.getColumnIdentifierList())) {
// 没有查询条件则校验失败
return Result.buildFailedResult(String.format(getCheckType().getCheckResultFormat(), searchParam.getTableName()));
}
List<String> columnList = sqlParseInfo.getColumnIdentifierList().stream()
.filter(c -> StringUtils.equals(c.getDb(), searchParam.getSchemaName()) && StringUtils.equals(c.getTable(), searchParam.getTableName()))
.map(ColumnIdentifier::getColumn).collect(Collectors.toList());
boolean disjoint = Collections.disjoint(partitionColumnNameList, columnList);
if (disjoint) {
return Result.buildFailedResult(String.format(getCheckType().getCheckResultFormat(), searchParam.getTableName()));
}
}
} catch (Exception e) {
// 异常情况先通过
LOGGER.error("code check error, check content: {}, defaultDb: {}, checkType: {}", checkContent, defaultDb, getCheckType().name());
}
return Result.buildSuccessResult();
}
@Override
public CodeCheckType getCheckType() {
return CodeCheckType.TYPE_01;
}
}
¿Cómo personalizar las reglas de inspección de código?
Si las reglas de verificación de código integradas no cumplen con los escenarios de uso del cliente, los clientes pueden personalizar las reglas de verificación de código cargando archivos jar .
Las reglas de verificación de código personalizado utilizan el mecanismo SPI para cargar archivos jar personalizados cargados por los usuarios y llaman al método CodeCheck durante la detección de código y al método de cierre cuando los recursos están cerrados. Los usuarios deben depender de los archivos jar en la descripción del archivo de configuración en sus propios proyectos. detalles de la siguiente manera:
● Crear una clase que implemente la interfaz.
Cree una clase que implemente la interfaz com.dtstack.assets.spi.codecheck.ICodeCheckClient e implemente los métodos CodeCheck y close, y escriba código lógico relevante. Si la verificación pasa, establezca el éxito en el objeto CheckResult en verdadero. Si falla , establezca el campo de éxito en falso y establezca el motivo por el cual falla la verificación.
package com.dtstack.assets.spi.codecheck;
import java.util.Map;
public interface ICodeCheckClient {
/**
* 代码检查
*
* @param checkContent 检查内容
* @param extMap 扩展配置
* @return 检查结果
*/
CheckResult codeCheck(String checkContent, Map<String, Object> extMap);
/**
* 释放资源, 调用时需要关闭所使用的资源
*/
void close();
}
·Explicación de los campos de parámetros de entrada
– checkContent es una única pieza de información SQL
– extMap establecerá algunas propiedades de la plataforma, incluido el nombre de la tarea, el tipo de tarea, etc.
· Explicación de los campos de parámetros.
– el éxito indica si se pasó la verificación y se debe configurar
– checkResult es el resultado de la verificación y no puede estar vacío cuando la verificación falla.
package com.dtstack.demo;
import com.dtstack.assets.spi.codecheck.CheckResult;
import java.util.Map;
public class CodeCheckImpl implements com.dtstack.assets.spi.codecheck.ICodeCheckClient{
@Override
public CheckResult codeCheck(String checkContent, Map<String, Object> extMap) {
// 代码检查相关逻辑
CheckResult checkResult = new CheckResult();
checkResult.setSuccess(false);
checkResult.setCheckResult("校验不通过的理由");
return checkResult;
}
@Override
public void close() {
// 关闭相关资源
}
}
● Cree el directorio META-INF/services en el directorio de recursos.
● Crear archivos en el directorio META-INF/services
El nombre del archivo es com.dtstack.assets.spi.codecheck.ICodeCheckClient y el contenido del archivo es el nombre de clase definido por permiso de la clase que implementa la interfaz ICodeCheckClient.
Ejemplo de nombre de archivo y contenido:
● Empaquetar el proyecto actual y registrar reglas de verificación de código en la página de recursos de datos.
Se dará un aviso para los frascos que no cumplan con las condiciones.
¿Cómo cargar el jar correspondiente a las reglas del código personalizado?
Inicializaremos un cargador de clases personalizado único para el jar correspondiente a cada regla cargada. Este cargador de clases hereda el URLClassLoader y garantiza que el cargador de subclases se cargue primero.
Cargue y almacene en caché el cliente correspondiente en la primera llamada.
Después de que el usuario vuelva a cargar o editar las reglas, borre el cargador de clases antiguo y el cliente cargado y libere los recursos.
"Informe técnico del producto Dtstack": https://www.dtstack.com/resources/1004?src=szsm
Dirección de descarga del "Libro técnico sobre prácticas de la industria de gobernanza de datos": https://www.dtstack.com/resources/1001?src=szsm Amigos que quieran saber o consultar más sobre los productos de big data, las soluciones industriales y los casos de clientes de Kangaroo Cloud, navegue por el sitio web oficial de Kangaroo Cloud: https://www.dtstack.com/?src=szkyzg
Al mismo tiempo, los estudiantes interesados en proyectos de código abierto de big data pueden unirse a "Kangaroo Cloud Open Source Framework DingTalk Technology qun" para intercambiar la información más reciente sobre tecnología de código abierto, número de qun: 30537511, dirección del proyecto: https: // github.com/DTStack
Multado con 200 yuanes y más de 1 millón de yuanes confiscados You Yuxi: La importancia de los documentos chinos de alta calidad El servidor de migración de núcleo duro de Musk Solon para JDK 21, ¡los hilos virtuales son increíbles! ! ! El control de congestión de TCP salva Internet Flutter para OpenHarmony está aquí El período LTS del kernel de Linux se restaurará de 6 años a 2 años Go 1.22 solucionará el error de la variable del bucle for Svelte construyó una "nueva rueda" - runas Google celebra su 25 aniversario