本文主要是介绍总结一下自己,最近三年,我做了哪些工作,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
简单总结下吧,我算是业务架构师,确实对得起这个名字,经常冲在一线,业务和架构相关的东西都有做,系统比较复杂,不过逐步了解谁都会熟悉的
下面简单列一列我这三年的工作情况吧,也算是给自己一个交代,不全,但大体就这些了
2021年
业务系统熟悉,技术框架熟悉
参与交易模式开发
2022年
工作流改造
工作流支持前台用户的参与:(原设计只能后台进行审核,前台用户也无法审核参与)
-
兼容老工作流使用
-
重新封装接口,前端使用组件不用变化
-
支持后台审核
-
支持前台用户程序调用提交
-
支持动态指定下一个审核人
-
支持接口调用流转节点
-
支持新增审核节点,可跳过业务,只做多节点的审核动作,无需更改代码
-
支持业务审核记录的查看追踪
-
支持审核过程中动态传递变量供决策等操作;支持多条线决策
容器化的搭建
功能能够给用户建立完整的系统,可通过运维平台查看操作相关功能,包括节点管理,容器组管理,容器管理工作负载,存储,配置等等,同时可部署常用的组件。
制作dockerfile,编写maven脚本打包安装包、镜像包推送到远程仓库
docker命令熟悉以及使用
可视化对接转化工具使用
一个公司的工具,比如对接银行时的报文不用写代码,像低码一样进行转化处理,弊端颇多,后来我封装了common包进行优化,定义规范,使调用方方便,使工具开发简洁,支持原来不支持的功能,记录报文
工具经过使用已暴露出多个缺点
-
有门槛
-
JSON转JSON翻译key不支持可视化,只能自定义插件写代码,增加复杂度
-
List如果只有一个对象,XML转换JSON后变成对象 (已通过自定义插件并引入解决此问题,略微麻烦)
-
无法指定类型如int,只能是String,如果银行方接收是其他类型,需要手动兼容处理,处理麻烦
-
没有设计性,lua脚本的编写只是为了转换参数,且开发困难,必须了解整个链路调用才能知道变量是从哪里定义的
-
异常处理机制不完善,无法调试,只能通过打印日志,且报错没有明确位置
-
每个对接一个微服务,浪费资源
交易服务代码抽取
交易模式慢慢变多,交易需要的各个资源很多都耦合到了整体的common中,其实交易可以看成整体的模块,很多校验相同,外部调用相同等等,现在的问题是各个交易模式相同的代码来回拷贝,有的相同的功能不同人用不同的方式来做,一般涉及共性修改,则所有项目都要修改,可维护性比较差
抽取common-trade公共模块治理代码,统一请求减少差异性,向下兼容,打通各个交易模块的服务壁垒,减少重复性工作,增强可维护性
-
生成交易编号封装
-
对外部服务的调用进行封装等等,此封装不仅仅是调用,要解析提供给当前服务所需要的东西
-
校验封装
-
共性交易相关Bean、枚举、常量、注解定义
-
共性交易工具类相关,如金额业务处理
-
共性业务封装,能够确定的共性业务,否则不要封装
框架升级
升级框架,提高了框架的可维护性和安全性
大家可以看这篇文章,这是我升级整理出来的 https://blog.csdn.net/Goligory/article/details/128314051?spm=1001.2014.3001.5502
项目开发
外部港口以及区块链对接
协议转让模块,监管模块,对外对接相关对接及改造等
工作流封装以及使用
脚手架的定义及维护;
相关项目的需求开发
其他
日志中心功能包括全链路日志检索,链路追踪、图表分析,链路分析包括耗时信息等可以很快定位问题
低码平台预研:功能还可以,版本比较低,业务最终没用起来
网关服务优化对内对外接口并落地标准文档;
设计滑动窗口限流方案;
设计个性化重推方案
2023年
产品
- 公共包完善:
- 工作流封装完善
- 接手产品仓单仓储业务;优化代码、日志以及注释,提高可读性和可维护性;解决遗留问题
- 仓单仓储完善相关索引设计;解决相关并发问题
- 产品仓单外部操作接口增加业务编号和合同编号并记录到日志中,提高交易与仓单的可追溯性
架构
- 框架维护升级
- 工作流维护升级;解决标题过长问题以及自定义标题问题
- 用户中心升级:使用表单自定义功能嵌入自己的业务规则,提高工作流使用的扩展性;
- 增加拦截器解决页面重复提交问题
- MQ死信队列丢失问题预研,目前死信队列的消息没有专门处理,超过规则限制会存在丢失的情况,需要整体整理topic以及队列管理,对死信队列有专门的处理并持久化等操作
- 数据库表索引问题:目前有一部分表没有常用索引,有些功能查询效率比较低下,最好规划预研Sql建立基础索引并优化大sql,提高查询效率,提高用户体验
- 统一网关完善:完善对接使用文档;增加获取文件接口;增加验签方式;增加对方访问我方的接口标准;
- 建立用户中心封装包并封装相关功能,后面需陆续在使用过程中迁移封装相关功能,易于产品管理
项目1
- 协议转让业务随着各个版本需求完善
- 监管功能支持
- 工作流使用完善,结合区域,市场,是否开启审核等等进一步控制工作流节点审核的权限
- 数据权限开发,根据不同规则进行sql路由
仓单项目
- 接手电子仓单业务;随着各个版本需求完善,解决遗留问题
- 代码优化,日志优化,注释优化
- 对接区块链,解决推送的高性能以及不丢失方案,支持定时失败重推,解决线程不释放导致线程池耗尽的问题
- 多港口港口对接代码重构,减少对接一个港口分散各处的改动,易于扩展,易于对接,对后面的对接提供了标准
- 仓单模块逆流程开发仓单注册和仓单质押
- 签章核心代码优化;注销、拆分、部分解质押增加签章背书
- 支持融资需求;网关支持完善SM2加密方式,增加根据fileId获取文件外部接口
- 多级审核(可设置人员以及顺序)
项目3
- 接手仓储模块(此时前女友开发了一版但是没有提测),仓单模块改造,对接仓储模块,随着各个版本需求完善功能
- 解决仓储环境部署配置问题;菜单问题;整理全量脚本
- 仓储功能入库预约单、入库单、在库库存、货主库存、库位库存、过户预约单、过户单、提货预约单、发货单、出库单的管理以及审核等功能在原基础上全流程开发;关于库存的问题点较多也比较严谨,各个业务功能都有库存的正向以及逆向处理,解决优化
- 仓单仓储打通:仓单的注册改造、注销、合并、转让-过户单、提货-发货单、仓管员帮货主注册、过户、提货等功能打通,并增加仓储相关审核,
- 仓单仓储有开关控制对接仓储和不对接仓储
- 仓储费(个性化)开发,支持指定人或市场自动初始化、自动收取
- 仓储后台建设
- 用乐观锁解决并发问题,完善库存相关的乐观锁判断
- APP接口支持
仓单仓储的熟悉改造并没有降低产品的质量,在改造过程中坚持更好的设计,注意其可扩展性以及可维护性,为后面继续变动提供了好的基础
项目4
- 撮合引擎开发
- 基于期限、用户、部分成交标识的算法匹配;
- 日终对账逻辑开发,以撮合为核心对委托单进行对账并通知上下游
- 监控统计接口开发;
- 支持其他查询等功能
业务开发总结
- 有时急于满足客户需求没走正常流程,导致开发设计质量低下,开发和测试没有足够的自测测试时间,存在返工情况或其他风险,后面尽量沟通好确定的需求再移交开发
- 需求以及设计文档考虑不够详细,开发过程中发现有细节业务问题,会导致返工或工时不够的情况;后面需求设计尽量有业务闭环,原型、如涉及现有系统改动需提供改动点等,不仅仅完善了文档,同时减少了开发以及测试的问题
- 开发存在临时解决问题的情况,后面会很难维护:需要从一开始做好设计,提高开发觉悟,开发前自发组织简单的评审讨论
- 客户推动的业务时间很有限,和第一条类似,开发人员需把关质量,且评估是否能够完成,提早暴露风险,最好减少极致压缩时间的情况,提高产品质量;同时这一条也取决于上一条的设计,如果比较灵活,那么交付效率就会更高,质量更好
- 有个别生产问题由于升级时没有配置相关配置导致,部署需严格按照交付文档来配置,做好具体的版本管理,否则如果有的配置比较重要会有很大的业务风险;
架构开发设计为了建设产品解决客户问题,产品的建设为了快速交付,应关注研发产品以及我们业务产品,用技术赋能业务,提高客户满意度;
多会用更多的时间在架构和产品层面做出成果,帮助团队减负提效,提高交付效率,提高整个系统的扩展性,易用性,稳定性
2024年
- 仓单项目-树结构需求和客户沟通;逆流程开发
- 仓储服务业务需求开发;
- 仓单服务仓库和平台审核顺序+是否需要审核的动态配置
结尾
三年时间说长不长,说短不短,很感谢现在这个公司,也感谢领导对我的重用,系统的业务复杂程度还是蛮高的,我们想方设法做产品,但是比较难的正是做产品,既不能过于灵活增加太大的复杂度,又不能个性化严重,很难快速交付,期间我们会写概设,操作手册,需求沟通,落地文档,开发进度把控,项目进度把控,测试进度,难点攻关,等等等等;后面还是需要继续磨炼技术,做一些架构选型
在此过程中发现大多数人还是只是搬砖,if,临时方案,日志混乱,注释缺失,没有流程图,没有设计文档,一旦有需求修改就要各个地方都改,影响老功能;一旦有问题一脸蒙圈,也忘记了当初的设计初衷。排除能力在外,首先需要摆正的是心态,而日志注释这些并不难
所以我们需要想一下怎么才能提高自身的效率?进而提升团队的效率,当我们有这个想法的时候,我想就不存在为了省事xxxx了,工作过程中不求一定会遇到一个伯乐领导,但是首先自己有个好的心态工作也会开心,同时遇到的问题也会变少,因为排查问题,需求扩展等等各方面都比较容易,反而不需要加班加点
祝大家好运,祝我自己好运~
这篇关于总结一下自己,最近三年,我做了哪些工作的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!