我的 2015-2018 —— 银行软开三年项目回顾

我的 2015-2018 —— 银行软开三年项目回顾

借着掘金“项目复盘”的机会,回顾自己工作的真实项目。本项目是我进入职场的第一个项目。从研三实习开始到第一个部门结束,一直都在做的项目。我们内部将这种项目称作“滚动开发包”,从名字就能看出来,持续滚动开发就是这个项目最大的特点,而从 2015 年 9 月开始,到 2018 年 7 月,将近 3 年的时间,我的主要工作都是围绕这个项目,是我职业生涯的第一个里程碑,在此进行复盘,希望其中的点滴内容能够帮助到希望进入银行软开的同学们。

一、项目简介

本项目是部门的内部项目管理系统,提供了从项目立项、方案评审、实施、上线到结项的全生命周期项目管理,涵盖了项目管理中的资源、进度、成本、质量等关键维度,学过 PMP 的同学们应该都比较熟悉。

  • 项目用户:部门中高管、PMO、行员、外包。
  • 项目特点:滚动开发包,需求迭代非常频繁,管理侧改革落地基本都基于本系统;内部系统,用户体验方面要求不高;用户量不大,几乎没有高并发场景;
  • 项目缺点:技术栈老旧、前后端未分离、需求变化频繁、缺少业务和技术文档、代码臃肿、开发效率低下;
  • 项目类型:采购产品,并根据业务需求进行了多年的迭代开发
  • 开发团队:10 左右规模,包括行内的项目经理、技术经理和我,其余开发、测试都为外包。

我入职的时候,行员就我一个开发,还有一个项目经理,一个技术经理。后来加入了祥哥作为技术经理,他是 Java 大牛。团队用了快 2 年的时间,将我们的项目从采购系统逐渐转变为了能够真正完全自主掌控的系统。我在这个项目中做过很多的角色,前后端开发、UI 设计、产品经理、项目经理、DBA、运维、运营、客服这些工作都贯穿在我工作的始终,银行软开的小伙伴对这种一人分饰多角的体验应该比较熟悉。我也通过接近两年的努力,将自己强行掰回了 Web 前端的轨道上来,并重归 Web 前端的正轨。

二、项目背景

先聊聊本项目的技术栈,本项目原本是采购产品,上线时间为 2013 年,采购产品的技术栈是消失已久的 EJB,没错,就是 EJB,早已被 Spring 取代的企业级 Java 开发框架,估计现在还掌握 EJB 的都是远古时期的 Java 大哥们了。系统架构大致如下,实际耦合更为严重:

截屏2021-03-19 下午12.24.36.png

老旧的技术栈造成了本项目的第一个困难。EJB 实在太重了,而且别说精通,熟练掌握的同事都不多,一般来说都是根据已有代码“照猫画虎”实现类似功能;而 Struts + JSP 的 MVC 方式,前后端完全耦合,很多复杂业务的 JSP 页面有几千行代码,修改起来十分痛苦。甚至很多页面是 JSP + Java 代码混合生成的,更增加了修改维护的难度。

当然这个系统也有一些优点,一是专业的全生命周期管理,结合了 PMP 的理论,该有的模块和功能都很齐全。二是完善的系统后管,包括通过页面可视化配置流程、列表页、表单页,这和最近几年比较火的低代码平台做的事情是一样的,只是通过 Java 实现的,连页面都是 Java 拼接 html 字符串返回给 JSP 的。通过页面配置可以实现不复杂的流程,但是用这套功能带来的问题就是,定制化的需求会极其难处理,即使像是在表单页面加个元素,有一些简单的交互事件这种简单需求,在这套框架处理起来就十分困难。

架构这么老旧,为什么不重构?我也经常问自己这个问题,归结起来原因还是很现实的,源源不断的需求带来的业务压力造成只能抽时间对关键的性能瓶颈做修补,祥哥来了之后有了更多的好转,很多技性能问题都陆续被解决了。

三、渐进式重构

其实彼时行内早已有了基于 Spring 的企业级 Java 框架,并应用在了非常多的项目里,运行非常稳定,而前端也有了基于 React 技术栈的前端全家桶解决方案。下定决心重构的契机是在做一个评审的需求,这个需求变更很频繁,而且业务逻辑非常复杂,现有的 JSP 代码累积接近两万行,即使改一个小需求都非常困难,终于下定决心根项目经理商量,我要重构这块内容。渐进式重构是一个当时最好的选择,拥有复杂逻辑的复杂系统,完全推翻重来很不现实。

那么接下来的问题就是:

  • 前端技术选型
  • 后端技术选型
  • 新老系统互相跳转,如何做用户认证和鉴权

后端技术比较好选,行内统一后端技术栈,使用自研的基于 Spring 的企业级 Java 框架就可以。下面聊聊剩余两个问题。

前端技术选型

其实当时和现在一样,ReactVue 二选一,当时也巧,正好赶上了闹的沸沸扬扬的 Facebook 开源协议事件,可能很多同学都忘记了,可以看当时 Facebook 发的声明,后来迫于社区和 Apache 基金会的强硬措施,Facebook 最终做出了妥协,将 React 的协议改为了 MIT。但在当时时间节点, React 并不是一个很好的选择,所以自然就选择了 Vue。
前端组件库,当时主流的是饿了么的 Element UI,我选择了 UI 更加精美的 iView,现在貌似已经商业化了,更名为了 View UI。

新老系统用户鉴权

这块也是重构一直没有推动的原因,因为原来的方案是共享 session,但是比较复杂,不适合老项目。后来刚好行内要推广统一身份认证系统,这个系统基于 Oauth 协议,支持单点认证功能,祥哥想用其单点认证的功能,实现新老系统的跳转。但是当时我是不太想用这种方案,主要基于三方系统服务稳定性的考虑,统一身份认证服务若不稳定,则我们新老系统无法登陆,尤其是测试环境,统一身份认证经常出问题,严重影响我们内部系统的登陆。

后来我想出了一个比较简单的方法,使用 token 方式,大致流程如下:老系统跳转至新系统,先调用后台服务获取 token,后台会将用户信息、token、超时时间存入数据库;老系统页面跳转 url 携带 token,跳转至新系统的入口页面,该页面进行判断,新系统用户是否已经登陆,若未登陆,则请求鉴权服务,传入 token 作为参数,该服务调用老系统的服务,通过 token 查询记录,比较当前时间与超时时间,若未超,则以该条记录的用户进行新系统的登陆,至此完成登陆动作。新系统跳转老系统的流程同理。这里 token 使用了 JSESSIONID

截屏2021-03-19 下午3.01.22.png

有了简单实用的鉴权方法,我们终于可以着手落地重构工作了,系统由新老两部分组成,架构图大致如下:

截屏2021-03-19 下午1.03.39.png

  • 1、全新页面使用 VueJS 框架开发新页面
  • 2、现有页面
    • 新功能使用 iframe 嵌套新页面
    • 老页面 JSP 使用 jsp: include 嵌套新页面
  • 3、现有页面,使用 Http 请求调用新系统的服务
  • 4、新老系统后台使用 Dubbo 通信

这里多说一下 jsp: include 的方式,利用了 JSP 的服务端渲染能力。不使用 iframe 的原因是,有个场景希望点击新页面按钮之后,实现弹出的 Modal 全屏的效果,但 iframe 的固定宽高将这个“全屏”效果限制在了 iframe 的内部,不满足需求。上文说的上万行的评审页面就是用这种方式重构的,光梳理清楚现有业务逻辑就花了一周多时间,最终差不多断断续续三个月时间完成了这块功能的局部重构。重构之后,后续的迭代需求开发起来就十分轻松了,过去平均一周的开发工作,现在几个小时就能搞定,而且极大优化了用户操作体验。

直到 2018 年 7 月我调离到其他部门,本项目的新老系统并存方案已经平稳运行,并支持了 6 个大版本和 10 余个小版本共计数百个功能点的开发任务,无论是开发效率还是前端用户体验都有了极大提升。

四、总结思考

本文即是项目复盘,也是我职业生涯的第一阶段回顾,和我很多互联网的同学不同,银行软开有其很多独有的特点,下面写一些个人这些年的思考,希望可以帮到希望进入银行软开的同学们。

项目很坑怎么办

这个问题实际上很现实,不是所有的人都能接手一个明星项目,也不一定上来就能做一个全新的项目。我工作多年来基本接触的项目都是迭代开发的项目。由于历史原因,有坑实际是很正常的,有时回头看看自己当年很满意的代码,也感觉有很多可以优化的空间。我一个同事跟我说,坑的项目也有好处,因为有太多可以优化的空间,现在回想起来真的是这样,虽然可能会很困难,但是将坑填平也是对职业发展很有益处的一件事。所以即使项目很坑,也应该改变心态,不应该一味抱怨,发挥我们的能动性,将坑的项目变好,实现自我价值的提升。

银行软开是不是很轻松

相较于互联网行业高强度工作,银行软开强度确实没有那么高。但有时项目比较紧急,996 也是比较正常。到底加不加班,工作强度如何,还是看部门和项目,对于每周有上线的同事,周四可能会半夜才结束工作。

要不要进银行软开

先说优点,对于应届的同学,可能更多的是出于户口的考虑,概率比互联网大厂要高。工作强度没有那么大,一般都能享受到周末的美好时光。优秀的同事,一般银行软开的入门门槛都是名校的硕士,和优秀的同事一起工作体验真的是很不错,我在的第一个部门的前辈基本都是资深的项目管理专家,我在他们身上学到了很多优秀的工作方法,并且取得了 PMP 证书,并真正把 PMP 学到的知识应用到了日常的项目管理实践中。还有就是福利比较好,免费的早午晚餐,节假日的礼品等等。缺点也比较明显,最大的缺点就是传统的行员等级晋升对于新人很不友好,涨薪非常缓慢。还有就是技术场景可能不如互联网一线大厂,技术栈相对落后,技术提升需要自身努力。

银行软开外包是一个好选择吗

银行软开一个很大的特点是外包项目很多,很多同学可能在犹豫要不要找银行软开外包的工作,我的建议是,只要是有技术追求、工作认真负责的同事,实际上会有机会的,过去表现好是可以转正为正式员工的,而现在表现好也可以推荐到科技公司,工资福利也会比外包好很多。我之前也有前辈是外包转成行员了,技术能力很强,前几年因为小孩上学举家迁到了杭州,拿了阿里 P7 的 offer。


最后的话,感谢掘金的这个项目复盘活动,让我对多年前的项目又重温了一次,点点滴滴回忆都涌上心头,现在的自己早已不是当初那个少年,怀念自己当年敢拼敢闯的日子。

我的 2015-2018 —— 银行软开三年项目回顾

https://ivocin.github.io/2021/03/19/my2015-2018/

作者

清秋

发布于

2021-03-19

更新于

2021-03-28

许可协议

评论