〇、工作
2021年是一个奋斗的年份，除了应届毕业刚工作那会以外，2021可以说是最忙也是压力最大的一年了。
2021年3月转正，也是我来到望海的第一个完整年份。
一、身份转变
在这一年中，我经历了从入职时的架构师定位到研发经理的转变。
在一个小规模的部门中，并不需要两个架构师的存在，在技术方向的探索和选型中，有一个架构师指明方向就行了，其他人负责查缺补漏即可。
多个有领导力的架构师同时存在是会存在一定程度的内耗的，所以说，架构师也并不是越多越好。
二、参与项目
在业务方面也是接触到了数字卫健的全部历史项目，比如最重要的上海申康项目，深挖坑广埋人的郑州和北京顺义项目等等。对数字卫健现有的全部业务进行了深入了解。
包括监管平台、财务大屏、预算编制、支出控制等不同业务。
甚至参与了智慧运营平台的初期建设工作，设计并实现了第一版的指标库，虽然没实际使用，哈哈哈，算了这段删除。
在参与申康项目时，我梳理了全部申康一期二期的表结构，并编写了excel文档，补全了所有表与字段的中文含义。现在这个excel基本上做过申康项目的研发和实习生人手一份。
在参与海南和郑州项目，特别是郑州项目时，我梳理了财务、成本、人资、耗材、绩效等全部监管报表的查询逻辑和对应的数据库表和字段，并形成了excel文档。
且在只有部分交接的情况下，理顺了郑州现场屎山一般的部署环境。
在后期参与北京顺义项目时，深入理解学习了工作流引擎的，重写了流转记录功能、添加了新的流程变量，接手了老刘的遗产。
了解很少一部分HERP的技术框架和业务逻辑，能帮项目经理查一些库表，解决一些简单的问题，最重要的是，做一下北京研发和项目经理之间的润滑剂吧，相当于一个翻译，能把两边说的话都翻译成对面能听明白的方式。
还梳理了HERP的发版流程。
单体补丁的发布流程。
三、技术能力
在技术方面，接触了部门全部技术栈，包括不限于springboot、springcloud、react（能改BUG、有例子情况下能开发新需求）、各版本fineReport（不同版本差异，二次开发集成认证）、viewhighBI（拆解了公司BI设计思路和数据结构）、UniEAP（主要靠老刘支持哈哈哈）、cas（在做郑州项目时，做到cas无源码二次开发集成卫宁统一认证）、甚至HERP（现在能做到读懂，可以在项目经理做数据时，告诉他哪个页面的数据是从哪个表来的）
在解决各种现场问题时，有时候迫于时间压力，必须另辟蹊径。
比如在做申康合院时，有几十张数据库表中数据的处理，外加几十个帆软页面的改造。而时间紧迫，就那么一两天。
为了不加班，这任务必须得动脑干，不能傻干了。
数据处理我首先排除了项目经理提的手动处理选项，因为太多表了，人的精力不够且容易出错。
我决定写了一个存储过程来执行数据处理，这一个存储过程要适配几十张不同的表，并识别出维度和事实字段，非常不好写，但是我就喜欢写这样的程序，写完很有成就感。这一个存储过程我写了两天，最终完成一劳永逸。甚至前几天又有合院问题时又用上了，值了。
在帆软页面改造时，一个一个找依然不能满足速度需求。
通过分析帆软的源文件我发现，帆软源文件的存储格式是xml，可以直接使用IDEA打开且不会乱码。
那么我就决定直接使用高级的语法匹配，整个进行工程级别的文字替换即可了，我花了半天时间找到所有需要修改的地址和特征并编写替换规则，就搞定了几十个帆软页面。
最后花了半天时间测试，没有任何问题，这样整个合院的需求3天就搞定了。
再举一个郑州的例子，郑州是阿里统一建设，阿里要求所有系统集成卫宁的统一认证。
我们在郑州部署的系统全是东拼西凑的，用了三种不同的数据库，4个帆软版本还不一致，里面有不同时期的基础平台，甚至存在UniEAP……
如果按照标准的接入方式集成卫宁统一认证，那么改造的工作量非常的巨大，且卫宁只提供一个入口跳转地址到我们的系统。
经过讨论与慎重思考，我决定将我们的cas与卫宁统一认证做集成，这样的好处1可以保留我们的cas登录入口，2我们9个子系统不用每个都改造了。
但是做起来很难，首先，网上没什么资料可以参考，都是各种系统集成cas，而不是cas去集成别人。
其次，我们还没有郑州cas的源码，郑州是一个老版本的cas，且之前有过二开，网上的cas源码不能直接用。
那么，我用IDEA直接打开郑州cas整个目录作为工程路径，然后手动指定lib包，利用IDEA自带的反编译功能直接阅读cas的源码。
参照卫宁的集成文档，用了一天半时间复写了多个配置文件与class类，实现了卫宁统一认证与cas的集成。
四、问题
要说今年最遗憾的就是顺义项目，年中的时候我没有下狠心接手重构，导致现在积重难返，产品化也失败了，只能按照项目做，而且质量一般般。
顺义预算，其实还真完全是我部门主导研发的产品，并不是二开。
我总结的经验的教训：
- 需求问题：需求不明确，拍脑袋定需求，未与甲方进行有效沟通，导致后期超大量改动。
- 研发问题：代码质量奇差，未能有效管理。
- 过度乐观：前期主观认为没有问题，不去发现可能的风险。后期暴露大量风险时，又因能力问题应对失措。
以上三点，我认为归根结底是人的问题，再说明白一点就是上一任研发经理、产品经理共同导致的问题，初期不能识别需求正确与否，做的和甲方想要的南辕北辙。中期不能管理代码质量，自己不写代码不做代码review，下属写的代码稀烂也不管导致质量奇差，一天天跟下属你好我好大家好。后期又不舍得那点奖金，认为没有重构的必要，完完全全的失职。
五、总结
用正确的人在正确的位置上，才能如臂使指，丝滑顺畅。
不要抱有不切实际的幻想，当一件事情有可能往最坏的结果发生时，它就一定发生。