专栏首页前端全栈开发者写业务代码中的成长机会

写业务代码中的成长机会

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

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

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

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

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

让代码写的不一样

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

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

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

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

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

其中存在的问题如下

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

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

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

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

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

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

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

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

笔者的反馈如下。

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

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

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

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

感谢您的阅读和关注。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 实战|仅用18行JavaScript构建一个倒数计时器

    有时候,你会需要构建一个 JavaScript 倒计时时钟。你可能会有一个活动、一个销售、一个促销或一个游戏。你可以用原生的 JavaScript 构建一个时钟...

    Dunizb
  • 【译】3条简单的React状态管理规则

    React组件内部的状态是在渲染之间保持不变的封装数据。useState()是React钩子,负责管理功能组件内部的状态。

    Dunizb
  • 使用React Hook一步步教你创建一个可排序表格组件

    我花了一些精力来创作本文,以及熬夜编写本文的示例程序,以便您能在阅读之后可以实践参考,阅读后如果觉得对您有帮助,可以关注作者、收藏和点赞本文,这是对作者写出优质...

    Dunizb
  • 如何量化考核技术人的KPI? 转

    对技术人来说,技术是成长的“核心”。然而,在实际工作协作中,技术的重要性常常被业务所掩盖,造成先业务后技术的现象。

    wuweixiang
  • 搞定中台,必须有的中控平台,业务身份和扩展点

    业务中台需要解决信息获取成本高、互联互通成本高、服务的不确定性、低水平重复建设这四个难题的。

    春哥大魔王
  • 数据百问系列:关于数据仓库,什么样的产品是好的Partener?

    本话题是一个发散性的话题,并没有限制太多的内容,主要是想跟大家讨论一下在实际工作中我们会更希望产品经理具有哪一方面的能力,又是为什么这么选。

    木东居士
  • 以赋能业务为目标的技术创新

    在软件研发从业者的视角里,创新分为两种:一种是与软件研发技术相关的创新,特别是在大数据和AI这种快速发展的领域,需要保持与技术进步的同频;而另一种创新,是与公司...

    宜信技术学院
  • 【门票福利】ArchSummit 全球架构师峰会

    阿里在投身云计算之初,王坚博士对马云说了一句话:如果阿里不投入精力研究技术,那历史长河中将不会有阿里巴巴的位置。随后阿里云的故事便家喻户晓。 对于企业来说,技...

    腾讯大讲堂
  • 腾讯云运维干货沙龙-海量运维实践大曝光 (三)

    12月16日,首期沙龙“海量运维实践大曝光”在腾讯大厦圆满举行。沙龙出品人腾讯运维技术总监、复旦大学客座讲师、DevOps专家梁定安,讲师腾讯手机QQ运维负责人...

    织云平台团队
  • 阿里入职一个月思考(随笔)

      最近没怎么写技术博客了。。原因是,跳到了曾经期望的公司,还在做技术储备。。。如今入职一个月了,已经完全进入状态。同时,也带来更多思考与感悟。

    用户3003813

扫码关注云+社区

领取腾讯云代金券