前言

自去年年底出差开始做的中台项目,几个迭代经过疫情、work from home、间歇性复工,直到前几天上线,算是告一段落。因为是和烟台的同事临时组建的团队,开发人员水平参差不齐 ,沟通大多是远程,算是从未有过的一段开发经历。

抽象与封装

这次重起炉灶的第一步就是果断升级jdk11,虽然语法上和jdk8差别没有features列举的那么大,但是毕竟用了新的gc。根据我的观察,jdk从8开始,新的版本很少再出现安全bug和内存泄露bug。后续如果可能,我会果断再升级到jdk14,看官方介绍,已经要痛下杀手干掉NPE,甚至还要抢lombok的饭碗。java未来如果能再借鉴 kotlin的协程,再火个十年不成问题。
这次项目开发,吸取了上次重构项目的教训,考虑到二线城市的程序员开发水平真的一言难尽,前期没有让其他后端同事介入,我一个人完成了项目的搭建,核心模块的封装,核心工具包的集成。随着开发的年限越久,越理解面向对象的三大核心:抽象、封装和继承。封装不仅仅是为了代码简洁,抽象和封装做的越好,后期其他经验稍浅的同事开发效率会越快,留给他们制造的bug的机会也越少,更换插件/工具包对项目的影响也越小。这次封装的一个得意之作是依靠FunctionalInterface和泛型以及AOP,直接屏蔽开发人员掉操作数据源和线程,框架搭建后,他们仅仅需要复制粘贴很少的业务代码、修改router地址,即可完成功能开发。不再需要纠结访问es或者mysql要写两套代码,同步异步切换要调用线程池,上传下载要操作io流。一切都是参数+注解完成,甚至类和代码,也有接近70%是自动生成。高度封装的优点在测试阶段得到充分体现,大多数的bug都是手误,字段名称错误,前后端沟通错误,功能性问题、性能问题几乎没有.

excel

用了很久的poi,最近发现了easyExcel,阿里的工程师出品。试用了一下,体验不错,比笨重的poi要好很多。对阿里好感+1。
阿里开源的项目,不管技术水平如何,总是在人性化和易用性上保持一贯的优势,之前看dubbo的文档即有此感想。easyExcel虽然看起来只是几个工程师的的业余时间的成果,但是功能demo几乎涵盖了所有常见的excel读写场景,一些之前需要非常繁琐的操作才能解决的痛点需求,easyExcel可以轻易借助注解来完成,看来作者没少经历过excel导出导出需求的毒打。本次项目的三十多处导入导出功能,均采用easyExcel实现。并且如上一节说讲,同样进行了深度的抽象和封装,最终配合aws的s3和异步线程池实现任意的导入导出均可两行代码实现。当然easyExcel毕竟是小项目,用下来的确有一些不易察觉的bug。尤其是其中根据内容自动变动宽度的功能,有一个静态变量引发的bug,我覆盖了原来的配置类,并给作者提个issue,一天之内就得到回复,告知会在下个版本修复。为阿里人的效率点赞。

spark

中台这个概念,包含数据中台、算法中台等。数据分析处理这块用的是aws的emr平台上的spark,实际上就是写python和通过java的sdk传递参数,回想大概六年前接触hadoop的时候,需要自己搭建hadoop集群,甚至还要自己搭建hbase,而现在数据处理已经进化到一线工程师仅仅会写python脚本就可以。江湖谣传现在很多硕士生做算法,听起来高大上,其实就是调参侠。不禁感叹自己错过了大数据开发,沦为一线码农。

其他

这两三个月的开发,是在不太平的外界环境(云谲波诡的国内外疫情)和不平静的内在思绪(有朋友和同事在漫长的寒假期间陆续高薪跳槽,并鼓动我尝试)下进行的。大半年前我就在思考事业规划,作为多年老程,早已到了失业的瓶颈期。虽然我很认同马爸爸那句在平凡的岗位上做好不平凡的事,也的的确确在认真的做项目、写代码、带新人。但是看着小孩一天天长大(最近已经满一岁),身边朋友薪资暴涨,自己难免时不时的浮躁。可是我的工作经历本身就是吃了浮躁的亏,曾经不满足工资太低而跳槽却遭遇部门裁员,未经受住诱惑入职了外滩边的豪华写字楼里的创业公司结果不到一年就垮掉,最终留在简历上的是一段段一到两年的工作经验。前段时间跟风刷了几个月的题,又学了一段时间的golang,还是太浮躁太短视。年届而立,我是想好好沉下心来,思考下自己真的喜欢做什么,未来还能做什么。最近的想法是,离这些谋生的东西都远一些,沉心学学《线代》和英语。


Is this article useful to you? How about buy me a coffee ?