如何快速熟悉业务逻辑并付诸落地

2021-11-11 From 朝闻道 By 朝闻道

本次我们不分享技术,我们来聊聊软素质,具体点说,我们来聊聊新人程序员如何快速熟悉业务逻辑并付诸落地。

一个新人程序员,经历了面试的层层磨炼,终于尘埃落定入职心仪的公司。初来乍到,对周围的一切都不熟悉,业务不熟悉,同事也不熟悉。

这其中关系最大的就是对业务和代码的熟悉,如果能够掌握快速熟悉业务逻辑的方法,就能够很快进入到工作角色中,从容不迫的开展新的工作。

那么我们本次分享就从这几个方面展开:

  • 如何通过读代码建立对系统的全局观,cover链路上下游
  • 如何画图来辅助自己熟悉业务流程
  • 应当如何学习掌握领域知识
  • 对于方案设计有哪些技巧和注意点
  • 问题排查的大概思路

PS: 由于大部分的开发者都是面向业务,因此本次讨论对于中间件类的开发不做进一步展开,后面有机会再分享。

如何通过读代码建立对系统的全局观,cover链路上下游

不可否认的是读代码本身不是一件轻松的事情,这意味着我们需要强迫自己站在写代码人的角度去揣摩他当初的想法和意图。
而这恰恰就是问题的矛盾点:一段代码质量的高低和当事人当初的心境、所处的环境、经验的高低,甚至和当事人的性格都是息息相关的。 p> <p> 这就造成了即便是同样一个需求,由不同年龄、不同背景、不同工作经验的人来写,最终的效果也是风格各异。 p> <p> 但是基本上每个人都有一套自己对于好代码的评判标准,这里不细说。重点还是要站在代码角度去思考业务。 p> <p> 既然代码不得不去读,那么我们首先要明确的是,读代码的目的是什么。 p> <p> 私以为看代码的主要目的是,通过读代码,从代码中梳理上下游之间如何进行交互,以及内部业务逻辑是如何处理以达到某种具体的目的。 p> <p> 读代码基本上都有目的,明确从何处开始读以及怎样读很重要。 p> <p> 如果拿到需求就直接冲到代码细节中去,这往往都得不偿失,其实最好先了解下背景。比如说看一下公司内部有没有成熟的文档,这能够让我们对当前的所做的业务有一个全局的认识;尤其是当文档中还画了系统架构图、主要业务逻辑流程图,那简直就是雪中送炭,乐不可支了。即便随着时间推移,项目迭代,有些设计已经发生了变化,但是他也能为加深你对系统理解起到重要作用。如果运气不好,没有图,也没有文档,那就只好自己去摸索梳理了。 p> <p> 那么如何对新业务新系统进行摸索梳理呢,这里主要指出两个大方向,一个就是通过系统的读代码建立认知,一个就是通过查问题/做需求方式来逐步对系统进行由点到面的认识。 p> <p> 代码如何去读也是一门学问。 p> <p> 如果乱读一气,抓不住重点,往往使自己陷入焦急的心境之中。我认为比较好的方式是 带着问题去看。 p> <p> 公司级的项目都是有模块划分的,先明确自己想看哪个模块的代码,如果不知道,一是看文档文档没有就问一下周围的同学,向他们请教这个模块大概的作用,基本上态度诚恳谦逊,大家都会乐于帮你的。如果所在的团队有着成熟的命名规范,其实通过项目/模块的名称基本上也能大概猜个八九不离十。 p> <p> 确定了模块的大概职责之后,就去寻找代码的入口,从入口开始看起,层层往下,自顶向下的去读去梳理p>

<p> 如何发现入口? p>
<p> 这里我举几个常见的代码入口的例子: p> <p> 对于业务而言,主要有以上的三种方式,其余的方式注入:线程任务提交、binlog数据同步等相对比较小众,而且都具有显著的特征,很容易找到入口,就不再赘述。 p> <p> 举个例子,比方说,我们找到一个名为auth的包,那么就可以大概的猜想,它应该用户认证相关的业务逻辑,那么就从这个包入手开始梳理p> <p> 梳理的主要目的为明确该模块提供了哪些能力p> <p> 从一个方法开始->每个方法执行了哪些内部的业务处理/计算->调用了哪些外部接口->与哪些基础设施进行了交互(数据持久化了哪些表,写了哪些缓存,发了哪些消息都值得记下来)。边梳理边画个图留作一个重构的依据或者以后反复看的一个依据。 p> <p> 这个过程中最好边梳理边整理文档,必要的时候可以画图,比如使用 visio、processon 等工具。 p> <p> 一般而言,同一个包/Class中的方法都是一类能力聚合,因此我们可以分业务场景、业务能力去看,这样一直梳理下去,基本上就能够对这个项目/模块对外提供能力有一个系统认知p> <p> 这种地毯式读代码的方式往往需要花费较多的时间和精力,如果没有耐心,很可能坚持不下去。 p>
<p> 那么有没有一种方法能够让自己快速了解系统的坑点,锻炼自己的排错能力呢? p>
<p> 当然有,那就是查问题p> <p> 基本上对于新人,往往不会直接让你做流程复杂的需求,我们团队的实践是,新人可以去查问题,通过查问题反向跟踪代码逻辑,发现问题修复问题p> <p> 如果出现了线上问题,通过查看日志分析告警、监控,定位异常点,最后定位到业务逻辑异常,通过异常堆栈反向查找代码,确定问题出现的原因,带着问题去看代码,印象是很深刻的。相信聪明的读者也有类似的体会吧。 p> <p> 这里要多说一句,如果是较为严重的错误或者异常,可以和老员工一起排查,发现问题之后最好是赶紧定位问题,不要发散,不要急着总结。先解决问题,等问题解决以后再复盘整理。 p>

对于复杂业务场景应该如何整理业务逻辑呢?

<p> 太极有阴阳,业务也有复杂与简单。 p> <p> 对于复杂的业务,比如支付、广告、银行等系统,我们应该如何整理业务逻辑呢? p> <p> 首先要明确的是,这个过程不会是三两天,而是需要迭代业务需求过程中不断思考整理总结时间短则一两年,长则三五年,甚至五年以上。 p> <p> 对于新人而言,初次接触复杂业务,如果有条件就多参与业务组的代码走读与串讲分享,如果条件不具备,就找和同组的同学吃个饭聊聊天,对业务的背景大致有个了解,这样心里会有些底气。 p> <p> 有句玩笑话是这么说的,业务不在文档里,都在老鸟的脑子里。其实不无道理,熟能生巧嘛。 p> <p> 具体到如何进行逻辑梳理和走读,我们可以先执行问题分类,对大流程主干的梗概进行罗列,需要明确上下游与本模块有哪些交互,最好落地到一个文档。我始终认为并且付诸实践的就是,好记性不如烂笔头,多做笔记多总结是普通人的良药。 p>
<p> 对于一个复杂的需求,如何梳理p>
<p> 我觉得,细节很重要。 p>
  • 根据PM业务的需求点着手,去思考背后的问题,权衡一下成本,ROI,找一个比较折中经济适用的设计方法,避免过度设计
  • 设计方案进行斟酌取舍,不断在大脑中推演;这是笔者的一个优秀的同事给笔者的建议,他说,当你对一个业务比较了解的时候,就可以自己去推演。基本上能够提前推出哪里有问题和风险,并且能够有充足的时间和PM对接,对需求进行完善。
  • 邀请同组的同学对自己的方案进行check,不识庐山真面目,只缘身在此山中。有些问题,旁观者看的更清楚。
  • 对于需要进行check的点,需要反复check,如上线计划,急停手段;带着主人翁意识去做事,面向失败设计

如何画图来辅助自己熟悉业务流程

<p> 在上文中,我们提到读代码的过程中往往伴随着画图,那么我们应当如何画图来辅助自己熟悉业务流程p> <p> 首先我们应当选择一款适合自己的画图工具,比如visio、processon、亿图图示工具等。 p> <p> 有了工具之后,我们需要了解常用的图例,系统学习UML,对主要的几种图形有所了解,比如泳道图、用例图、流程图、ER图。 p> <p> 画图不在于形式,而在于突出思路和重点,画图的过程中,尽量使图形有层次感,想清楚图是给谁看的,先保证内容契合思路、业务,再进行优化与进一步美化。 p>

应当如何学习掌握领域知识

<p> 我们常说,技术是为业务服务的,技术为业务赋能,而业务又促进了技术的演进和发展。 p> <p> 这里的业务往深了说,其实就是所谓的领域,每个领域都有自身领域知识,用时髦的说法就是所谓的“统一语言”。 p> <p> 我们说,要有深度和广度,单论广度,就是要学习本行业的领域知识,完善自己的对业务体系的认知p> <p> 我们对常见的一些领域进行举例:比如说电商中的订单、 物流、支付、销运、清结算、风控、广告等,都是一个一个的业务领域。每个领域都有自己领域内的统一语言p> <p> 我们需要领域内的统一语言、通用名词进行学习和掌握,这样既能够方便与他人的沟通,还能促使我们用专业的语言描述业务,进而促进代码编写的准确性。 p> <p> 这里我简单介绍几种学习业务领域知识方法p>
  1. 看书,看书是学习领域知识的一个通用方法。随着互联网的发展,业界已经有很多先驱对自己熟悉的领域进行梳理总结,我们如果能够进行学习,就站在了巨人的肩膀上,免去了自己进行探索所花费的时间。比如说,广告行业,基本不错的书籍如《程序化广告》、 《计算广告》、 《信息流广告》,电商领域的《电商产品经理》等书籍都是不错的学习资料;
  2. 和别人交流,进入新的工作环境,周围的同事都是老师。带着自己的思考问题,友好的与同事讨论,沟通,请教,也是提高自己业务领域知识了解的一种方式,大部分情况下,有经验同事会给出一个学习的方向,这是很宝贵的资源。
  3. 多看文档,成熟的企业内部往往都有文档的沉淀。找到这些资料并加以学习,对于自己的提高是相当显著的。如果恰巧你的公司就有这样的条件,那么千万不要忽略。
<p> 对于新人来讲,对一个新的业务领域建立了一个初步的认知之后,基本上能够应对简单的需求开发任务了。否则连需求理解不了,那还谈何开展工作呢? p> <p> 这里我还要多说两句,除了掌握业务领域知识外,最好去了解学习一些 领域驱动设计 的思想和概念,不断促使自己站在系统整体的思想高度去思考设计自己的系统。毫不夸张的说,“领域驱动设计”是开发能力突破的秘诀之一。 p>

对于方案设计有哪些技巧和注意点

<p> 这一部分,我们了解一下一个需求方案设计要注意哪些点。 p> <p> 这部分内容是从笔者的工作抽象总结出来的,去除了工作特征明显的点,提炼出了共性的注意点。基本上需求的快速迭代需要注意的点都包含进去了: p> <p> 方案设计我们主要从以下几个点进行说明: p> <p> 针对配置,我们再补充几点: p> <p> 这里提到的,基本上就是一个方案设计过程需要考虑的点,如果有遗留还请多多见谅。读者朋友也可以基于这些要点发展出适合自己的方案设计模板。 p>

问题排查的大概思路

<p> 最后,来介绍一下问题排查的大概思路。 p>
  1. 快速定位问题经验很重要。同样的问题,不同经验的同学解决耗费的时间是有明显的区别的,因此我们需要不断了解系统设计,了解业务上下游交互链路,并对业务中容易导致问题发生的节点进行重点排查和优化;
  2. 需要公司内部的常见的监控/问题排查组件进行了解,知道使用什么工具解决什么问题,这样在出现问题的时候能够借助工具提升问题排查的速度。对于开源问题排查工具也需要了解,重点吸收工具背后的原理设计思路;
  3. 特殊问题需要特殊处理,如果问题定位困难,先想办法止损。待损失控制之后,再进行进一步的排查,要灵活一些。对于常规问题可以通过沉淀问题排查手册来进行辅助;

总结

<p> 写了这么多技术类的文章,本文应该算是目前最不技术的一篇。 p> <p> 我们主要讨论了“快速熟悉业务逻辑并辅助逻辑”的手段和一些常见的思路,如果你恰巧刚入职场,那么本文中的内容应该能够帮助你快速度过菜鸟阶段p> <p> 如果你觉得文章不错,欢迎点赞转发,祝每位读者都能建立起自己的一套思维框架,在职场中游刃有余。 p>

本文来源:朝闻道,转载请注明出处!

来源地址:http://wuwenliang.net/2021/01/30/%E8%BD%AF%E7%B4%A0%E8%B4%A8-%E5%A6%82%E4%BD%95%E5%BF%AB%E9%80%9F%E7%86%9F%E6%82%89%E4%B8%9A%E5%8A%A1%E9%80%BB%E8%BE%91%E5%B9%B6%E4%BB%98%E8%AF%B8%E8%90%BD%E5%9C%B0%EF%BC%9F/

发表感想

© 2016 - 2022 chengxuzhixin.com All Rights Reserved.

浙ICP备2021034854号-1    浙公网安备 33011002016107号