写业务代码中的成长机会
本文来自《程序员的三门课》读书笔记，于君泽著。
写业务代码有成长机会吗？关于这个问题，答案非常肯定：必须有成长机会。对于大部分公司而言，能够写底层代码或者中间件代码的人总是有限的，写业务代码会面临更高的复杂度。
这里分三个层次来看其中的成长机会。
- 第 1 个层次，让代码写得不一样。可从代码规范、可读性、可扩展性等角度着手，这也是程序员的基本功。
- 第 2 个层次，考虑业务问题和技术问题的匹配。可从写业务代码中理解需求，- 并做好分析与设计。被动接收需求和实现接口，确实成长空间不大。
- 第 3 个层次，总结相关方法体系，成为业务及技术双料专家。
下面通过例子分别针对这 3 个层次进行讲解。
让代码写的不一样
这里看一个例子，常见的代码如下：
这段代码其实可以写成这样：
考虑业务问题和技术问题的匹配
这里举一个烟囱型架构重构的例子。某团队在早期发展阶段对新来的每个业务都会搭建一套系统，业内人士将这种见招拆招、垂直化发展的架构称为「烟囱型架构」。烟囱型架构并非一无是处，在早期业务成败未知的情况下，不过度设计架构，能直接、有效地支持业务。
不过，随着业务的发展，「烟囱」越来越多，对这些「烟囱」的后续维护成为很大的问题，「成长」的烦恼如期而至。
其中存在的问题如下
- 人手不够，业务响应慢了下来。 以一个 5 人研发团队为例，起初这个团队从 0 到 1 进行建设，5 个人花了 1 个月做出一个简单版的红包系统；几年后该团队增加到 10 个人，但手头要维护 10 个系统，每个人就要维护一个系统。这时又来了两个新业务，该团队派出 3 个人去做这两个新业务，大约要花 4 个月才能完成。这严重不符合前端业务的响应预期。
- 重复建设。 在同类烟囱系统中有 80% 的功能是类似的，从数据库模型到主要业务逻辑都是复制粘贴加补丁，一不留神就又踩到一个坑。
- 维护成本高。 面对日常升级包、咨询支持服务，该团队疲惫不堪。
那么，能不能将其中 80% 甚至 90% 的共性问题抽象出来呢？核心领域模型是否可以稳定呢？
在既要支持不断出现的各种业务，又要建设新平台的纠结中权衡之后，该团队首先启动了平台化项目，建设路径是存量业务继续使用烟囱架构，但新业务随着新平台一起接入，然后逐步迁移存量业务，实现烟囱系统的下线。如图所示，优惠券平台对前端业务提供统一的能力输出。
总结下来，平台化架构有如下好处。
- 快速支撑、响应业务。
- 抽象共性、边界清晰。快速支撑、响应业务是以终为始的出发点。
架构不服务业务，那么再高大上都是空话。技术不是炫技，要服务于商业。对于抽象共性的问题，业务平台化要解决业务的共性问题，比如天猫、淘宝都有各类营销活动，那就抽象出一个营销平台来管理营销活动、营销工具的整个生命周期，并提供给前端业务使用。
总结相关方法体系，成为业务及技术双料专家
举个例子，曾有一位做事非常努力、成长也比较快的小兄弟诉苦说，他之前在做网关程序，做得很细，除了完成了业务还保障了系统没有 Bug，还使文档沉淀、效率提升，外部机构联调合作方比如银行对其反馈也很好，但大家对其印象是善于合作，技术貌似一般。这位小兄弟在最近一年又做了业务平台，觉得自己在分析设计、中间件技术的应用上已经进步很大，甚至对自己的成长也很满意，但其他人还是认为其技术貌似一般。这位小兄弟百思不得其解。
笔者的反馈如下。
- 从量变到质变是有一个过程的，自我感觉总是良好的，外部感知可能会晚。如果坚持去做，「迟到的」一定会到。
- 大部分人都是固定型思维模式和成长型思维模式的混合模式，如果你身边的人固守对你的原有看法，不是你的错，你需要做的就是不断拓展自己的能力。
再举个例子，小郭在几年前参与了一个接入类业务，当时已经有不少机构接入了这个业务，业务规模不大不小，产品经理换了几茬，研发团队也变更了三次。当大家日复一日地做业务接入、测试、发布时，有人发现这个业务缺少一个业务视图。也就是说，这个业务有对系统资源的检测、对接口调用的监控，但是没有对业务运行情况的监控，看不到地区粒度、子业务粒度的变化情况等，甚至 BD 在签订新业务时都不了解为啥某地区已经没有调用量了。小郭利用业余时间开发了一个业务视图工具，整个团队马上就感受到他的过人之处了。有人讲，大公司不是应该什么都就绪吗？实际情况是，大公司也是经历了业务的高速发展的，可以这样说，大部分公司并不缺少做得更好、做得不一样的机会！
所以，「写业务代码有成长机会吗」这个句式还可以改为「维护老系统如何晋升」「做商户接入如何走向高端」和「项目这么忙如何学习」，我们需要进一步将自己的知识和经验系统化，形成相关的方法体系。
在心态上，笔者提两点建议：一是欣赏自己的成长，二是做个有心人。
感谢您的阅读和关注。