【PostgreSQL】后端部署使用PostgreSQL数据库

PostgreSQL数据库配置

驱动配置

Maven配置(14.3版本可用)
<postgresql.version>42.6.0</postgresql.version>

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>${postgresql.version}</version>
</dependency>
离线驱动下载

postgresql-42.2.18.jar
postgresql-42.6.0.jar
postgresql-42.7.3.jar

JDBC连接配置

pamirs:
  datasource:
    base:
      type: com.alibaba.druid.pool.DruidDataSource
      driverClassName: org.postgresql.Driver
      url: jdbc:postgresql://127.0.0.1:5432/pamirs?currentSchema=base
      username: xxxxxx
      password: xxxxxx

连接url配置

暂无官方资料

url格式
jdbc:postgresql://${host}:${port}/${database}?currentSchema=${schema}

在jdbc连接配置时,${database}和${schema}必须完整配置,不可缺省。

其他连接参数如需配置,可自行查阅相关资料进行调优。

方言配置

pamirs方言配置
pamirs:
  dialect:
    ds:
      base:
        type: PostgreSQL
        version: 14
        major-version: 14.3
      pamirs:
        type: PostgreSQL
        version: 14
        major-version: 14.3
数据库版本 type version majorVersion
14.x PostgreSQL 14 14.3

PS:由于方言开发环境为14.3版本,其他类似版本(14.x)原则上不会出现太大差异,如出现其他版本无法正常支持的,可在文档下方留言。

schedule方言配置
pamirs:
  event:
    enabled: true
    schedule:
      enabled: true
      dialect:
        type: PostgreSQL
        version: 14
        major-version: 14.3
type version majorVersion
PostgreSQL 14 14.3

PS:由于schedule的方言在多个版本中并无明显差异,目前仅提供一种方言配置。

其他配置

逻辑删除的值配置
pamirs:
  mapper:
    global:
      table-info:
        logic-delete-value: (EXTRACT(epoch FROM CURRENT_TIMESTAMP) * 1000000 + EXTRACT(MICROSECONDS FROM CURRENT_TIMESTAMP))::bigint
PostgreSQL数据库用户初始化及授权
-- init root user (user name can be modified by oneself)

CREATE USER root WITH PASSWORD 'password';

-- if using automatic database and schema creation, this is very important.
ALTER USER root CREATEDB;

SELECT * FROM pg_roles;

-- if using postgres database, this authorization is required.
GRANT CREATE ON DATABASE postgres TO root;

Oinone社区 作者:oinone原创文章,如若转载,请注明出处:https://doc.oinone.top/install/50.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

Like (2)
oinone's avataroinone
Previous 2023年6月20日 pm4:07
Next 2023年11月2日 pm1:58

相关推荐

  • 【界面设计器】模型增删改查基础

    阅读之前 你应该: 已搭建包含界面设计器的基础环境。 对平台元数据有基本了解和认识。(如果不是特别清楚也没关系) 常用元数据简介 平台中包含了许多元数据,以这些元数据为基础,可以较为完整的描述了一个【应用】或【模块】的存储结构以及用户交互。 图解 “` mermaidgraph TDModule —> DataDictionaryModule —> Model Model —> FieldModel —> Function1(Function)Model —> Action Action —> ViewAction —> ViewAction —> ServerAction —> Function2(Function)Action —> UrlActionAction —> ClientAction“` 概念解释 模块(Module):用于定义元数据的作用域。 数据字典(DataDictionary):固定数据可选项。 模型(Model):用于描述一个具体对象的集合。 字段(Field):模型中字段,用于描述对象属性。 函数(Function):模型中的函数,用于定义对象的服务端行为。 动作(Action):模型中的动作,用于定义对象的交互行为。具体表现为以下四个行为。 跳转动作(ViewAction):用于视图与视图之间的跳转。 视图(View):用于定义主内容分发区的页面内容。 服务端动作(ServerAction):用于客户端调用服务端行为。特殊的,当函数被作为API级别开放时,客户端也可以直接调用。 链接动作(UrlAction):用于执行浏览器超链接行为。 客户端动作(ClientAction):用于自定义客户端动作。 其他概念解释 应用(Application):特殊的模块,可以被用户访问的模块。 模块依赖(ModuleDependencies):模块与模块之间具备的一种关系,使得模块可以使用被依赖模块的相关元数据。 场景描述 在以下演示过程中,我们将通过【演示模块】这一应用来引导大家完成【商品】模型的增删改查操作。并根据实际应用场景,为大家提供模型增删改查的最佳实践。 创建第一个无代码应用 (基于低代码开发的应用,可以跳过这一步骤。) 登录进入系统后,将可以按照如下步骤进行操作。(为了方便演示和体验,可直接使用admin用户进入系统) 切换应用到应用中心 创建第一个应用 至此,你已经创建了一个【演示应用】,用于接下来的操作。 创建第一个无代码模型 (基于低代码开发的模型,可以跳过这一步骤。) 切换应用到模型设计器 在模型设计器切换视图为表模式 模型设计器具有表模式和图模式两种模型展示形式,表模式主要用于单个模型的管理,图模式主要用于查看多个模型之间的关联关系。 在这里我们使用表模式。 在模型设计器切换模块到【演示模块】 创建一个存储模型【商品】 在无代码模式中,只能选择【存储模型】和【传输模型】,其代表的含义为: 存储模型:创建模型时同步创建数据库表,具备数据存储能力。 传输模型:仅创建模型,不创建数据库表,不具备数据存储能力,仅作用户交互使用。 创建模型时,一定会继承一个父模型,在模型设计器创建模型都将默认继承【基础存储模型】,该模型中默认包含【编码】和【名称】两个业务字段,以及【ID】、【创建人ID】、【更新人ID】、【创建时间】、【更新时间】五个系统字段。 在专家模式中,可以查看模型的父模型进行查看,也可以在创建模型时修改父模型。这一功能在这里不进行演示。 在下面的操作中,我们仅需使用【编码】和【名称】这两个业务字段来创建相关视图。 创建第一个表格视图 切换应用到界面设计器 选择应用和模型 这里为了方便查看,我们可以使用【全部视图类型】。 创建表格视图 输入【页面标题】,修改【视图类型】为【表格】,直接点击确定即可。会自动进入【页面设计】。 页面设计 设计表格视图 从【组件库】-【模型】中将【编码】和【名称】两个【低代码字段】拖入【表格区】 小贴士: 在左侧组件库可以切换【组件】和【模型】。【组件】用于创建和选择字段,【模型】用于直接使用现有字段。 在模型面板可以查看当前选中字段所在模型。如未选择时,为当前视图模型。 对于存储模型而言,创建字段应该是一个谨慎的操作,在学习阶段尽可能从【模型】中使用现有字段。除非有创建新字段的需求。 大家可以自由发挥,将【编码】和【名称】拖入【列表搜索区】即可使用这两个字段进行搜索。单行文本默认使用模糊搜索。 为表格提供【创建商品】功能 从【组件库】-【组件】中将【跳转动作】组件拖入【动作区】,并填写相关的元数据信息,按图示输入完成后,点击保存即可。(具体解释在文章下方) 这里会创建一个【表单】视图,并绑定至当前动作。设计完表格视图后,我们需要设计表单视图。 为表格提供【编辑商品】功能 从【组件库】-【组件】中将【跳转动作】组件拖入【行内动作区】,并填写相关的元数据信息,按图示输入完成后,点击保存即可。 为表格提供【删除商品】功能 从【组件库】-【模型】中将【删除】动作分别拖入【动作区】和【行内动作区】即可。 将表格绑定到菜单,可以让用户访问 使用【显示母版】可以查看当前页面在母版中的预览效果 添加菜单项【商品管理】并【绑定当前视图】 发布表格视图,并返回列表页 至此,我们已完成了【表格】视图的基本功能设计。 接下来,我们需要设计刚刚在【创建商品】步骤时创建的【表单】视图。点击【商品表单】卡片任意区域进入【页面设计】。 设计表单视图 从【组件库】-【模型】中将【编码】和【名称】两个【低代码字段】拖入【表单区】 为表单提供【创建/更新】功能,使得表单可以提交数据到服务端 从【组件库】-【模型】中将【创建】动作拖入【动作区】 将【创建】动作的【是否隐藏】属性改为【条件隐藏】并设置表达式 从【组件库】-【模型】中将【更新】动作拖入【动作区】 将【更新】动作的【是否隐藏】属性改为【条件隐藏】并设置表达式 为表单提供【返回】功能 将【组件】-【客户端动作】拖入【动作区】添加【返回】功能 发布表单视图,并返回列表页 (同表格视图发布) 切换应用到应用中心,为应用设置首页 使用绑定菜单,将【商品管理】菜单设置为【演示模块】的应用首页。 切换应用到演示模块,查看刚刚设计的视图以及体验增删改查基本功能 至此,一个模型的全部增删改查功能已进行完整演示。下面将对上述步骤中可能产生的疑问点进行解释说明。 跳转动作元数据配置 动作名称:跳转动作的默认显示名称 数据控制类型:用于动作点击后的数据行为控制。 处理单条数据:携带当前可用数据的一行到目标页面中,仅一行,如果勾选了多行也仅有首行(首行按勾选顺序决定)。 处理多条数据:携带当前可用数据的多行到目标页面中,至少是两行。 处理单条或多条数据:携带当前可用数据的多行到目标页面中,至少是一行。 不进行数据处理:不携带任何数据到目标页面。 打开方式:用于动作点击后的跳转行为控制。 当前窗口打开:基本的页面跳转,不打开新的浏览器窗口或标签页。 新窗口打开:打开新的浏览器窗口或标签页。特殊的,使用了平台内置的多标签页时,将不再打开新的浏览器窗口或标签页,仅会在多标签页中添加一个新的标签页。 弹窗打开:使用弹窗打开,并渲染目标页面。 抽屉打开:使用抽屉打开,并渲染目标页面。 页面内容:界面设计器交互属性。 绑定已有视图:从平台中已存在的视图中选择视图作为目标页面。 创建新页面:输入视图相关信息,创建新视图并绑定到当前动作作为目标页面。 绑定页面:【绑定已有视图】时用于选择视图。 页面标题:【创建新页面】时使用的页面信息,与【界面设计器】中【创建视图】的【页面标题】一致。 页面模型:【创建新页面】时使用的页面信息,与【界面设计器】中【创建视图】的【模型】一致。 业务类型:【创建新页面】时使用的页面信息,与【界面设计器】中【创建视图】的【业务类型】一致。 视图类型:【创建新页面】时使用的页面信息,与【界面设计器】中【创建视图】的【视图类型】一致。 操作栏位置:【创建新页面】时使用的页面信息,与【界面设计器】中【创建视图】的【操作栏位置】一致。 禁用数据加载:打开目标页面时不发起服务端查询。 加载函数:打开目标页面时使用指定的加载函数发起服务端查询。 客户端动作元数据配置 动作名称:客户端动作的默认显示名称 客户端行为:平台内置的客户端行为 数据校验:同提交动作的数据校验功能 返回上一页/关闭弹窗/关闭抽屉 刷新数据:同提交动作的刷新当前视图功能 批量更新:在批量动作打开的弹窗中使用的特殊客户端动作 删除数据:在一对多(O2M)和多对多(M2M)使用表格组件时使用的删除功能 Q/A 跳转动作的数据控制类型该如何选择? 通常情况下,我们可以通过目标页面是否需要携带数据以及携带的数据行数,来决定数据控制类型。 在演示内容中,从【表格】视图通过【创建】按钮跳转到表单时,通常我们不需要任何数据,因此我们选择【不进行数据处理】来实现这一目的。从【表格】视图通过【编辑】按钮跳转到表单时,通常我们在行内进行操作,并且我们一次只能编辑一行数据,因此我们选择【处理单条数据】。 【组件库】-【组件】中的动作和【组件库】-【模型】中的动作有什么区别? 【组件库】-【组件】中的动作拖入页面时,会创建一个对应的动作,因此需要输入元数据相关信息。【组件库】-【模型】中的动作为当前模型中的【服务端动作】,因此拖入页面后无需输入元数据相关信息。 【删除】动作为什么可以显示在两个区域? 在模型中内置的【删除】动作,其数据类型为【处理单条或多条数据】,因此可以在表格的【动作区】和【行内动作区】各放置一个。不仅如此,所有的数据类型为【处理单条或多条数据】的【服务端动作】都可以这样做。 表格的【创建】和【编辑】为什么一个使用【创建新页面】,另一个使用【绑定已有视图】? 在新增【创建】这个【跳转动作】时,由于我们在当前模型下没有一个【表单】视图可以直接使用,因此在这里我们使用【创建新页面】的方式直接创建【表单】视图,并绑定至当前动作。 在新增【编辑】这个【跳转动作】时,由于我们在上一步骤已经创建了一个可以直接使用的【表单】视图,因此在这里我们使用【绑定已有视图】。 在演示内容中,我们假设【创建商品】和【编辑商品】使用的【表单】视图可以通过【是否隐藏】属性进行简单区分,因此采取了这样的演示操作。根据我们实践经验,在大多数场景中也的确如此。 表单的【创建】和【更新】配置的【条件隐藏】具有怎样的含义? 在平台任何存储模型/代理模型(不包含中间模型)中,都具备ID这一系统字段。通过【不进行数据处理】的跳转动作跳转至【表单】视图时,ID不会在跳转时进行传递,因此在【表单】中的ID字段为空。通过【处理单条数据】的跳转动作跳转至【表单】视图时,ID会在跳转时进行传递(如URL上可以看到id属性),因此在【表单】中的ID字段不空。 根据这一特性,我们就可以通过【条件隐藏】区分当前这个视图的业务功能。 表单的【创建】可以通过当前视图数据.ID非空进行隐藏,即表示当前ID非空时隐藏(当前ID为空时显示)。 表单的【更新】可以通过当前视图数据.ID为空进行隐藏,即表示当前ID为空时隐藏(当前ID不空时显示)。

    2023年11月1日
    8.6K00
  • 树形下拉组件数据查询覆写

    一、背景与问题 Oinone 的树形下拉组件(TreeSelect)和树视图(Tree)在查询数据时,最终调用的是树节点所配置模型的数据管理器函数: 树接口 调用的数据管理器函数 场景 fetchAll queryListByWrapper 一次性全量加载 fetchChildren queryPage 按层级懒加载(默认) queryKeywords4Tree queryListByWrapper 关键字搜索 reverselyQuery queryListByWrapper 已选数据回填 官方文档原文:「所有树查询接口都会调用模型对应的数据管理器函数,可以通过重写的方式修改其查询结果。」 直接覆写的风险 如果直接在原模型(如 business.PamirsDepartment)上覆写 queryPage: // ⚠️ 危险写法:会影响所有使用 PamirsDepartment.queryPage 的场景 @Component @Model.model(PamirsDepartment.MODEL_MODEL) public class DeptQueryAction { @Function.Advanced(type = FunctionTypeEnum.QUERY, category = FunctionCategoryEnum.QUERY_PAGE) @Function.fun(FunctionConstants.queryPage) @Function(openLevel = {FunctionOpenEnum.LOCAL, FunctionOpenEnum.REMOTE, FunctionOpenEnum.API}) public Pagination<PamirsDepartment> queryPage(Pagination<PamirsDepartment> page, IWrapper<PamirsDepartment> queryWrapper) { // 追加过滤条件… return new PamirsDepartment().queryPage(page, queryWrapper); } } 该覆写会全局生效——不仅是树形下拉,所有调用 PamirsDepartment 的 queryPage 的地方(组织架构页面、人员管理列表、权限分配、框架内部关联查询等)都会受到影响,容易引发难以排查的副作用。 二、推荐方案:代理模型(PROXY)隔离 核心思路 创建一个继承原模型的代理模型(ModelTypeEnum.PROXY),拥有独立的模型命名空间 在代理模型中重新声明自关联字段(如 parent),将关联目标指向代理模型自身 在代理模型的 Action 中覆写数据管理器函数,追加树形场景专属的过滤逻辑 树形下拉的视图 DSL 中,<node> 的 model 指向代理模型 代理模型与原模型共享同一张数据表,但函数注册在各自独立的命名空间下,互不干扰。 框架官方示例 Oinone 框架自身就采用了这一模式:ResourceRegionProxyModel 继承 ResourceRegion,用于地区页面的代理展示,其扩展点 ResourceRegionProxyModelExtPoint 中的 queryPageAfter 只影响代理模型自身的查询。 三、完整实现步骤(以 PamirsDepartment 为例) 场景假设 业务需求:某个表单页面的「部门」树形下拉只需要展示当前公司(companyCode == 当前用户公司)且启用状态(dataStatus == ENABLED)的部门,而系统中其他使用 PamirsDepartment 的地方(组织架构、权限管理等)不受影响。 步骤 1:定义代理模型 package com.example.demo.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.enmu.ModelTypeEnum; import pro.shushi.pamirs.business.api.model.PamirsDepartment; import java.util.List; /** * 部门树形下拉专用代理模型 * <p> * 继承 PamirsDepartment,共享同一张数据表, * 但拥有独立的函数命名空间,覆写 queryPage 不影响原模型。 */ @Model.model(DeptTreeProxy.MODEL_MODEL) @Model.Advanced(type = ModelTypeEnum.PROXY) @Model(displayName = "部门(树选择)", labelFields = "name") public class DeptTreeProxy extends PamirsDepartment { public static final String MODEL_MODEL = "demo.DeptTreeProxy"; /** * 【必须重新声明】上级部门(自关联字段) * <p> * 基类 PamirsDepartment 中 parent 的类型是 PamirsDepartment, * 代理模型必须将其覆盖为指向自身(DeptTreeProxy), * 否则设计器/树组件无法在代理模型命名空间内构成完整的自关联关系, * 导致树形下拉无法正确展开层级。 */ @Field.many2one @Field.Relation(relationFields = {"parentCode"}, referenceFields = {"code"}) @Field(displayName = "上级部门")…

    后端 2026年7月27日
    31700
  • 项目中排除掉特定的Hook和扩展点

    总体介绍 在共库共Redis的情况下,某些场景存在需要过滤掉特定Hook和扩展点(extpoint)的情况。本文介绍排除掉的配置方法 1. Oinone如何排除特定的Hook 配置: pamirs: framework: hook: excludes: – 排除的扩展点列表 示例: pamirs: framework: hook: excludes: – pro.shushi.pamirs.timezone.hook.TimezoneHookBefore – pro.shushi.pamirs.timezone.hook.TimezoneHookAfter – pro.shushi.pamirs.timezone.hook.TimezoneSessionInitHook – pro.shushi.pamirs.translate.hook.TranslateAfterHook 2. Oinone如何排除特定的扩展点 配置 pamirs: framework: extpoint: excludes: – 排除的扩展点列表 示例: pamirs: framework: extpoint: excludes: – pro.shushi.pamirs.demo.core.extpoint.PetCatTypeExtPoint

    2024年5月13日
    2.1K00
  • 技术精要:数据导出与固化实用指南

    数据被认为是企业发展和决策的重要资产。随着业务的不断发展和数据量的不断增加,企业通常需要将数据从不同的源头导出,并将其固化到产品中,以便进行进一步的分析、处理和利用。数据导出与固化的过程涉及到数据的提取、清洗、整合和存储,是确保数据长期有效性和可用性的关键步骤。 了解数据导出与固化的流程和方法对于企业具有重要意义。通过有效的数据导出和固化,企业可以更好地管理和利用数据资源,提升决策的准确性和效率,实现业务的持续发展和创新。本次讨论将重点探讨数据导出与固化的流程和关键步骤,帮助参与者深入了解如何将数据从导出到产品中,为企业数据管理和应用提供有力支持。 1. 数据导出与固化:将数据从导出到产品中的流程 1.1. pom依赖: <dependency> <groupId>pro.shushi.pamirs.metadata.manager</groupId> <artifactId>pamirs-metadata-manager</artifactId> </dependency> 1.2 将第⼆步下载后的⽂件放⼊项⽬中(注意⽂件放置的位置)。放置⼯程的resources 下⾯。例如: 1.3 项⽬启动过程中,将⽂件中的数据导⼊(通常放在core模型的init包下 ⾯)。⽰例代码: package pro.shushi.pamirs.sys.setting.enmu; import com.google.common.collect.Lists; import org.apache.commons.collections4.CollectionUtils; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.ApplicationContext; import org.springframework.stereotype.Component; import pro.shushi.pamirs.boot.common.api.command.AppLifecycleCom mand; import pro.shushi.pamirs.boot.common.api.init.LifecycleCompleted AllInit; import pro.shushi.pamirs.boot.common.extend.MetaDataEditor; import pro.shushi.pamirs.core.common.InitializationUtil; import pro.shushi.pamirs.meta.annotation.fun.extern.Slf4j; import pro.shushi.pamirs.meta.api.dto.meta.Meta; import pro.shushi.pamirs.meta.domain.module.ModuleDefinition; import pro.shushi.pamirs.metadata.manager.core.helper.DesignerIn stallHelper; import pro.shushi.pamirs.metadata.manager.core.helper.WidgetInst allHelper; import java.util.List; import java.util.Map; @Slf4j @Component public class DemoAppMetaInstall implements MetaDataEditor, LifecycleCompletedAllInit { @Autowired private ApplicationContext applicationContext; @Override public void edit(AppLifecycleCommand command, Map<String, Meta> metaMap) { if (!doImport()) { return; } log.info("[设计器业务元数据导⼊]"); InitializationUtil bizInitializationUtil = InitializationUtil.get(metaMap, DemoModule.MODULE_MODULE/ ***改成⾃⼰的Module*/, DemoModule.MODULE_NAME/***改成⾃⼰的 Module*/); DesignerInstallHelper.mateInitialization(bizInitializatio nUtil, "install/meta.json"); log.info("[⾃定义组件元数据导⼊]"); // 写法1: 将组件元数据导⼊到⻚⾯设计器. 只有在安装设计器的 服务中执⾏才有效果 WidgetInstallHelper.mateInitialization(metaMap, "install/widget.json"); // 写法2: 与写法1相同效果 InitializationUtil uiInitializationUtil = InitializationUtil.get(metaMap, "ui_designer", "uiDesigner"); if (uiInitializationUtil != null) { DesignerInstallHelper.mateInitialization(uiInitialization Util, "install/widget.json"); } // 写法3: 业务⼯程和设计器分布式部署,且希望通过业务⼯程导⼊ ⾃定义组件元数据. 业务模块需要依赖⻚⾯设计器模块,然后指定业务模块导 ⼊ DesignerInstallHelper.mateInitialization(bizInitializatio nUtil, "install/widget.json"); } @Override public void process(AppLifecycleCommand command, Map<String, ModuleDefinition> runModuleMap) { if (!doImport()) { return; } log.info("[设计器业务数据导⼊]"); // ⽀持远程调⽤,但是执⾏的⽣命周期必须是 LifecycleCompletedAllInit或之后. 本地如果安装了设计器,则没有要 求 DesignerInstallHelper.bizInitialization("install/ meta.json"); log.info("[⾃定义组件业务数据导⼊]"); // 当开发环境和导⼊环境的⽂件服务不互通时, 可通过指定js和 css的⽂件压缩包,⾃动上传到导⼊环境,并替换导⼊组件数据中的⽂件url // WidgetInstallHelper.bizInitialization("install/ widget.json", "install/widget.zip"); WidgetInstallHelper.bizInitialization("install/ widget.json"); return; } private boolean doImport() { // ⾃定义导⼊判断. 避免⽤于设计的开发环境执⾏导⼊逻辑 String[] envs = applicationContext.getEnvironment().getActiveProfiles(); List<String> envList = Lists.newArrayList(envs); return…

    2024年2月27日
    2.8K00
  • 后端代码规范

    前言 虽然oinone框架减少了很多的代码,但是低代码部分的代码质量也需要高度关注,不管是写的代码bug多,或者说被吐槽代码不行,还是说写的代码经常被重构,核心点还是没有代码规范的意识和技巧,下面摘录了一些常见的规范要求,去提高后端的代码质量,代码质量提高后,自然效率也会提升。 常见代码规范 **1、规范命名** 命名是写代码中最频繁的操作,比如类、属性、方法、参数等。好的名字应当能遵循以下几点: **见名知意** 比如需要定义一个变量需要来计数 int i = 0; 名称 i 没有任何的实际意义,没有体现出数量的意思,所以我们应当指明数量的名称 int count = 0; **能够读的出来** 如下代码: private String sfzh; private String dhhm; 这些变量的名称,根本读不出来,更别说实际意义了。 所以我们可以使用正确的可以读出来的英文来命名 private String idCardNo; private String phone; **2、规范代码格式** 好的代码格式能够让人感觉看起来代码更加舒适。 好的代码格式应当遵守以下几点: 合适的空格 代码对齐,比如大括号要对齐 及时换行,一行不要写太多代码 好在现在开发工具支持一键格式化,可以帮助美化代码格式,大家统一使用idea的规范即可。 **3、写好代码注释** 在《代码整洁之道》这本书中作者提到了一个观点,注释的恰当用法是用来弥补我们在用代码表达意图时的失败。换句话说,当无法通过读代码来了解代码所表达的意思的时候,就需要用注释来说明。 书的作者之所以这么说,是因为作者觉得随着时间的推移,代码可能会变动,如果不及时更新注释,那么注释就容易产生误导,偏离代码的实际意义。而不及时更新注释的原因是,程序员不喜欢写注释。😒 但是这不意味着可以不写注释,当通过代码如果无法表达意思的时候,就需要注释,比如如下代码: for (Integer id : ids) { if (id == 0) { continue; } //做其他事 } 为什么 id == 0 需要跳过,代码是无法看出来了,就需要注释了。 好的注释应当满足一下几点: 解释代码的意图,说明为什么这么写,用来做什么 对参数和返回值注释,入参代表什么,出参代表什么 有警示作用,比如说入参不能为空,或者代码是不是有坑 当代码还未完成时可以使用 todo 注释来标记 代码review发现漏洞时 可以使用 fixme 注释来标记 **4、try catch 内部代码抽成一个方法** try catch代码有时会干扰我们阅读核心的代码逻辑,这时就可以把try catch内部主逻辑抽离成一个单独的方法 如下图是Eureka服务端源码中服务下线的实现中的一段代码 整个方法非常长,try中代码是真正的服务下线的代码实现,finally可以保证读锁最终一定可以释放。 所以这段代码其实就可以对核心的逻辑进行抽取。 protected boolean internalCancel(String appName, String id, boolean isReplication) { try { read.lock(); doInternalCancel(appName, id, isReplication); } finally { read.unlock(); } // 剩余代码 } private boolean doInternalCancel(String appName, String id, boolean isReplication) { //真正处理下线的逻辑 } **5、方法别太长** 方法别太长就是字面的意思。一旦代码太长,给人的第一眼感觉就很复杂,让人不想读下去; 同时方法太长的代码可能读起来容易让人摸不着头脑,不知道哪一些代码是同一个业务的功能。 比如代码中有那种2000+行大类,各种if else判断,光理清代码思路就需要用很久时间。🤷🏻‍♀️ 所以一旦方法过长,可以尝试将相同业务功能的代码单独抽取一个方法,最后在主方法中调用即可。 **6、抽取重复代码** 当一份代码重复出现在程序的多处地方,就会造成程序又臭又长,当这份代码的结构要修改时,每一处出现这份代码的地方都得修改,导致程序的扩展性很差。 所以一般遇到这种情况,可以抽取成一个工具类,还可以抽成一个公共的父类。 **7、多用return** 在有时我们平时写代码的情况可能会出现if条件套if的情况,当if条件过多的时候可能会出现如下情况: if (条件1) { if (条件2) { if (条件3) { if (条件4) { if (条件5) { System.out.println("11111"); } } } } } 面对这种情况,可以换种思路,使用return来优化 if (!条件1) { return; } if (!条件2) { return; } if (!条件3) { return; } if (!条件4) { return; } if (!条件5) { return; } System.out.println("11111"); 这样优化就感觉看起来更加直观 **8、if条件表达式不要太复杂**…

    2024年12月11日
    3.2K00

Leave a Reply

Please Login to Comment