〇、工作

2021年是一个奋斗的年份,除了应届毕业刚工作那会以外,2021可以说是最忙也是压力最大的一年了。
2021年3月转正,也是我来到望海的第一个完整年份。

身份转变

在这一年中,我经历了从入职时的架构师定位到研发经理的转变。

在一个小规模的部门中,并不需要两个架构师的存在,在技术方向的探索和选型中,有一个架构师指明方向就行了,其他人负责查缺补漏即可。
多个有领导力的架构师同时存在是会存在一定程度的内耗的,所以说,架构师也并不是越多越好。

参与项目

在业务方面也是接触到了数字卫健的全部历史项目,比如最重要的上海申康项目,深挖坑广埋人的郑州和北京顺义项目等等。对数字卫健现有的全部业务进行了深入了解。
包括监管平台、财务大屏、预算编制、支出控制等不同业务。

甚至参与了智慧运营平台的初期建设工作,设计并实现了第一版的指标库,虽然没实际使用,哈哈哈,算了这段删除。

在参与申康项目时,我梳理了全部申康一期二期的表结构,并编写了excel文档,补全了所有表与字段的中文含义。现在这个excel基本上做过申康项目的研发和实习生人手一份。

在参与海南和郑州项目,特别是郑州项目时,我梳理了财务、成本、人资、耗材、绩效等全部监管报表的查询逻辑和对应的数据库表和字段,并形成了excel文档。
2021总结01

且在只有部分交接的情况下,理顺了郑州现场屎山一般的部署环境。
2021总结02

在后期参与北京顺义项目时,深入理解学习了工作流引擎的,重写了流转记录功能、添加了新的流程变量,接手了老刘的遗产。
了解很少一部分HERP的技术框架和业务逻辑,能帮项目经理查一些库表,解决一些简单的问题,最重要的是,做一下北京研发和项目经理之间的润滑剂吧,相当于一个翻译,能把两边说的话都翻译成对面能听明白的方式。

还梳理了HERP的发版流程。
2021总结03

单体补丁的发布流程。
2021总结04

技术能力

在技术方面,接触了部门全部技术栈,包括不限于springboot、springcloud、react(能改BUG、有例子情况下能开发新需求)、各版本fineReport(不同版本差异,二次开发集成认证)、viewhighBI(拆解了公司BI设计思路和数据结构)、UniEAP(主要靠老刘支持哈哈哈)、cas(在做郑州项目时,做到cas无源码二次开发集成卫宁统一认证)、甚至HERP(现在能做到读懂,可以在项目经理做数据时,告诉他哪个页面的数据是从哪个表来的)

在解决各种现场问题时,有时候迫于时间压力,必须另辟蹊径。
比如在做申康合院时,有几十张数据库表中数据的处理,外加几十个帆软页面的改造。而时间紧迫,就那么一两天。
为了不加班,这任务必须得动脑干,不能傻干了。
数据处理我首先排除了项目经理提的手动处理选项,因为太多表了,人的精力不够且容易出错。
我决定写了一个存储过程来执行数据处理,这一个存储过程要适配几十张不同的表,并识别出维度和事实字段,非常不好写,但是我就喜欢写这样的程序,写完很有成就感。这一个存储过程我写了两天,最终完成一劳永逸。甚至前几天又有合院问题时又用上了,值了。
在帆软页面改造时,一个一个找依然不能满足速度需求。
通过分析帆软的源文件我发现,帆软源文件的存储格式是xml,可以直接使用IDEA打开且不会乱码。
那么我就决定直接使用高级的语法匹配,整个进行工程级别的文字替换即可了,我花了半天时间找到所有需要修改的地址和特征并编写替换规则,就搞定了几十个帆软页面。
最后花了半天时间测试,没有任何问题,这样整个合院的需求3天就搞定了。
2021总结05

再举一个郑州的例子,郑州是阿里统一建设,阿里要求所有系统集成卫宁的统一认证。
我们在郑州部署的系统全是东拼西凑的,用了三种不同的数据库,4个帆软版本还不一致,里面有不同时期的基础平台,甚至存在UniEAP……
如果按照标准的接入方式集成卫宁统一认证,那么改造的工作量非常的巨大,且卫宁只提供一个入口跳转地址到我们的系统。
经过讨论与慎重思考,我决定将我们的cas与卫宁统一认证做集成,这样的好处1可以保留我们的cas登录入口,2我们9个子系统不用每个都改造了。
但是做起来很难,首先,网上没什么资料可以参考,都是各种系统集成cas,而不是cas去集成别人。
其次,我们还没有郑州cas的源码,郑州是一个老版本的cas,且之前有过二开,网上的cas源码不能直接用。
那么,我用IDEA直接打开郑州cas整个目录作为工程路径,然后手动指定lib包,利用IDEA自带的反编译功能直接阅读cas的源码。
参照卫宁的集成文档,用了一天半时间复写了多个配置文件与class类,实现了卫宁统一认证与cas的集成。
2021总结06

问题

要说今年最遗憾的就是顺义项目,年中的时候我没有下狠心接手重构,导致现在积重难返,产品化也失败了,只能按照项目做,而且质量一般般。
顺义预算,其实还真完全是我部门主导研发的产品,并不是二开。
我总结的经验的教训:

  1. 需求问题:需求不明确,拍脑袋定需求,未与甲方进行有效沟通,导致后期超大量改动。
  2. 研发问题:代码质量奇差,未能有效管理。
  3. 过度乐观:前期主观认为没有问题,不去发现可能的风险。后期暴露大量风险时,又因能力问题应对失措。

以上三点,我认为归根结底是人的问题,再说明白一点就是上一任研发经理、产品经理共同导致的问题,初期不能识别需求正确与否,做的和甲方想要的南辕北辙。中期不能管理代码质量,自己不写代码不做代码review,下属写的代码稀烂也不管导致质量奇差,一天天跟下属你好我好大家好。后期又不舍得那点奖金,认为没有重构的必要,完完全全的失职。

总结

用正确的人在正确的位置上,才能如臂使指,丝滑顺畅。
不要抱有不切实际的幻想,当一件事情有可能往最坏的结果发生时,它就一定发生。

一、生活

生活方面乏善可陈,天天加班996导致基本没什么业余生活了,这是2022年要改善的方面。