本文来自《程序员的三门课》读书笔记,于君泽著。

写业务代码有成长机会吗?关于这个问题,答案非常肯定:必须有成长机会。对于大部分公司而言,能够写底层代码或者中间件代码的人总是有限的,写业务代码会面临更高的复杂度。

这里分三个层次来看其中的成长机会。

  • 第 1 个层次,让代码写得不一样。可从代码规范、可读性、可扩展性等角度着手,这也是程序员的基本功。
  • 第 2 个层次,考虑业务问题和技术问题的匹配。可从写业务代码中理解需求,- 并做好分析与设计。被动接收需求和实现接口,确实成长空间不大。
  • 第 3 个层次,总结相关方法体系,成为业务及技术双料专家。

下面通过例子分别针对这 3 个层次进行讲解。

让代码写的不一样

这里看一个例子,常见的代码如下:

这段代码其实可以写成这样:

考虑业务问题和技术问题的匹配

这里举一个烟囱型架构重构的例子。某团队在早期发展阶段对新来的每个业务都会搭建一套系统,业内人士将这种见招拆招、垂直化发展的架构称为「烟囱型架构」。烟囱型架构并非一无是处,在早期业务成败未知的情况下,不过度设计架构,能直接、有效地支持业务。

不过,随着业务的发展,「烟囱」越来越多,对这些「烟囱」的后续维护成为很大的问题,「成长」的烦恼如期而至。

其中存在的问题如下

  • 人手不够,业务响应慢了下来。 以一个 5 人研发团队为例,起初这个团队从 0 到 1 进行建设,5 个人花了 1 个月做出一个简单版的红包系统;几年后该团队增加到 10 个人,但手头要维护 10 个系统,每个人就要维护一个系统。这时又来了两个新业务,该团队派出 3 个人去做这两个新业务,大约要花 4 个月才能完成。这严重不符合前端业务的响应预期。
  • 重复建设。 在同类烟囱系统中有 80% 的功能是类似的,从数据库模型到主要业务逻辑都是复制粘贴加补丁,一不留神就又踩到一个坑。
  • 维护成本高。 面对日常升级包、咨询支持服务,该团队疲惫不堪。

那么,能不能将其中 80% 甚至 90% 的共性问题抽象出来呢?核心领域模型是否可以稳定呢?

在既要支持不断出现的各种业务,又要建设新平台的纠结中权衡之后,该团队首先启动了平台化项目,建设路径是存量业务继续使用烟囱架构,但新业务随着新平台一起接入,然后逐步迁移存量业务,实现烟囱系统的下线。如图所示,优惠券平台对前端业务提供统一的能力输出。

总结下来,平台化架构有如下好处。

  1. 快速支撑、响应业务。
  2. 抽象共性、边界清晰。快速支撑、响应业务是以终为始的出发点。

架构不服务业务,那么再高大上都是空话。技术不是炫技,要服务于商业。对于抽象共性的问题,业务平台化要解决业务的共性问题,比如天猫、淘宝都有各类营销活动,那就抽象出一个营销平台来管理营销活动、营销工具的整个生命周期,并提供给前端业务使用。

总结相关方法体系,成为业务及技术双料专家

举个例子,曾有一位做事非常努力、成长也比较快的小兄弟诉苦说,他之前在做网关程序,做得很细,除了完成了业务还保障了系统没有 Bug,还使文档沉淀、效率提升,外部机构联调合作方比如银行对其反馈也很好,但大家对其印象是善于合作,技术貌似一般。这位小兄弟在最近一年又做了业务平台,觉得自己在分析设计、中间件技术的应用上已经进步很大,甚至对自己的成长也很满意,但其他人还是认为其技术貌似一般。这位小兄弟百思不得其解。

笔者的反馈如下。

  1. 从量变到质变是有一个过程的,自我感觉总是良好的,外部感知可能会晚。如果坚持去做,「迟到的」一定会到。
  2. 大部分人都是固定型思维模式和成长型思维模式的混合模式,如果你身边的人固守对你的原有看法,不是你的错,你需要做的就是不断拓展自己的能力。

再举个例子,小郭在几年前参与了一个接入类业务,当时已经有不少机构接入了这个业务,业务规模不大不小,产品经理换了几茬,研发团队也变更了三次。当大家日复一日地做业务接入、测试、发布时,有人发现这个业务缺少一个业务视图。也就是说,这个业务有对系统资源的检测、对接口调用的监控,但是没有对业务运行情况的监控,看不到地区粒度、子业务粒度的变化情况等,甚至 BD 在签订新业务时都不了解为啥某地区已经没有调用量了。小郭利用业余时间开发了一个业务视图工具,整个团队马上就感受到他的过人之处了。有人讲,大公司不是应该什么都就绪吗?实际情况是,大公司也是经历了业务的高速发展的,可以这样说,大部分公司并不缺少做得更好、做得不一样的机会!

所以,「写业务代码有成长机会吗」这个句式还可以改为「维护老系统如何晋升」「做商户接入如何走向高端」和「项目这么忙如何学习」,我们需要进一步将自己的知识和经验系统化,形成相关的方法体系。

在心态上,笔者提两点建议:一是欣赏自己的成长,二是做个有心人。

感谢您的阅读和关注。