软素质: 如何快速熟悉业务逻辑并付诸落地？
本次我们不分享技术，我们来聊聊软素质，具体点说，我们来聊聊新人程序员如何快速熟悉业务逻辑并付诸落地。
一个新人程序员，经历了面试的层层磨炼，终于尘埃落定入职心仪的公司。初来乍到，对周围的一切都不熟悉，业务不熟悉，同事也不熟悉。
这其中关系最大的就是对业务和代码的熟悉，如果能够掌握快速熟悉业务逻辑的方法，就能够很快进入到工作角色中，从容不迫的开展新的工作。
那么我们本次分享就从这几个方面展开：
- 如何通过读代码建立对系统的全局观，cover链路上下游
- 如何画图来辅助自己熟悉业务流程
- 应当如何学习掌握领域知识
- 对于方案设计有哪些技巧和注意点
- 问题排查的大概思路
PS： 由于大部分的开发者都是面向业务，因此本次讨论对于中间件类的开发不做进一步展开，后面有机会再分享。
如何通过读代码建立对系统的全局观，cover链路上下游
不可否认的是读代码本身不是一件轻松的事情，这意味着我们需要强迫自己站在写代码人的角度去揣摩他当初的想法和意图。
而这恰恰就是问题的矛盾点：一段代码质量的高低和当事人当初的心境、所处的环境、经验的高低，甚至和当事人的性格都是息息相关的。
这就造成了即便是同样一个需求，由不同年龄、不同背景、不同工作经验的人来写，最终的效果也是风格各异。
但是基本上每个人都有一套自己对于好代码的评判标准，这里不细说。重点还是要站在代码角度去思考业务。
既然代码不得不去读，那么我们首先要明确的是，读代码的目的是什么。
私以为看代码的主要目的是，通过读代码，从代码中梳理上下游之间如何进行交互，以及内部业务逻辑是如何处理以达到某种具体的目的。
读代码基本上都有目的，明确从何处开始读以及怎样读很重要。
如果拿到需求就直接冲到代码细节中去，这往往都得不偿失，其实最好先了解下背景。比如说看一下公司内部有没有成熟的文档，这能够让我们对当前的所做的业务有一个全局的认识；尤其是当文档中还画了系统的架构图、主要业务逻辑的流程图，那简直就是雪中送炭，乐不可支了。即便随着时间推移，项目迭代，有些设计已经发生了变化，但是他也能为加深你对系统的理解起到重要作用。如果运气不好，没有图，也没有文档，那就只好自己去摸索梳理了。
那么如何对新业务新系统进行摸索梳理呢，这里主要指出两个大方向，一个就是通过系统的读代码建立认知，一个就是通过查问题/做需求的方式来逐步对系统进行由点到面的认识。
代码如何去读也是一门学问。
如果乱读一气，抓不住重点，往往使自己陷入焦急的心境之中。我认为比较好的方式是 带着问题去看。
公司级的项目都是有模块划分的，先明确自己想看哪个模块的代码，如果不知道，一是看文档，文档没有就问一下周围的同学，向他们请教这个模块大概的作用，基本上态度诚恳谦逊，大家都会乐于帮你的。如果所在的团队有着成熟的命名规范，其实通过项目/模块的名称基本上也能大概猜个八九不离十。
确定了模块的大概职责之后，就去寻找代码的入口，从入口开始看起，层层往下，自顶向下的去读去梳理。
如何发现入口？
这里我举几个常见的代码入口的例子：
- RPC 接口
- Http接口
- 消息生产、消费
对于业务而言，主要有以上的三种方式，其余的方式注入：线程池任务提交、binlog数据同步等相对比较小众，而且都具有显著的特征，很容易找到入口，就不再赘述。
举个例子，比方说，我们找到一个名为auth的包，那么就可以大概的猜想，它应该是用户认证相关的业务逻辑，那么就从这个包入手开始梳理。
梳理的主要目的为明确该模块提供了哪些能力。
从一个方法开始->每个方法执行了哪些内部的业务处理/计算->调用了哪些外部接口->与哪些基础设施进行了交互（数据持久化了哪些表，写了哪些缓存，发了哪些消息都值得记下来）。边梳理边画个图留作一个重构的依据或者以后反复看的一个依据。
这个过程中最好边梳理边整理文档，必要的时候可以画图，比如使用 visio、processon 等工具。
一般而言，同一个包/Class中的方法都是一类能力的聚合，因此我们可以分业务场景、业务能力去看，这样一直梳理下去，基本上就能够对这个项目/模块对外提供的能力有一个系统的认知。
这种地毯式读代码的方式往往需要花费较多的时间和精力，如果没有耐心，很可能坚持不下去。
那么有没有一种方法，能够让自己快速了解系统的坑点，锻炼自己的排错能力呢？
当然有，那就是查问题。
基本上对于新人，往往不会直接让你做流程复杂的需求，我们团队的实践是，新人可以去查问题，通过查问题反向跟踪代码逻辑，发现问题修复问题。
如果出现了线上问题，通过查看日志、分析告警、监控，定位异常点，最后定位到业务逻辑有异常，通过异常堆栈反向查找代码，确定问题出现的原因，带着问题去看代码，印象是很深刻的。相信聪明的读者也有类似的体会吧。
这里要多说一句，如果是较为严重的错误或者异常，可以和老员工一起排查，发现问题之后最好是赶紧定位问题，不要发散，不要急着总结。先解决问题，等问题解决以后再复盘整理。
对于复杂业务场景，应该如何整理业务逻辑呢？
太极有阴阳，业务也有复杂与简单。
对于复杂的业务，比如支付、广告、银行等系统，我们应该如何整理业务逻辑呢？
首先要明确的是，这个过程不会是三两天，而是需要在迭代业务需求的过程中不断思考整理总结，时间短则一两年，长则三五年，甚至五年以上。
对于新人而言，初次接触复杂业务，如果有条件就多参与业务组的代码走读与串讲分享，如果条件不具备，就找和同组的同学吃个饭聊聊天，对业务的背景大致有个了解，这样心里会有些底气。
有句玩笑话是这么说的，业务不在文档里，都在老鸟的脑子里。其实不无道理，熟能生巧嘛。
具体到如何进行逻辑的梳理和走读，我们可以先执行问题分类，对大流程主干的梗概进行罗列，需要明确上下游与本模块有哪些交互，最好落地到一个文档。我始终认为并且付诸实践的就是，好记性不如烂笔头，多做笔记多总结是普通人的良药。
对于一个复杂的需求，如何梳理？
我觉得，细节很重要。
- 根据PM业务的需求点着手，去思考背后的问题，权衡一下成本，ROI，找一个比较折中经济适用的设计方法，避免过度设计。
- 对设计方案进行斟酌取舍，不断在大脑中推演；这是笔者的一个优秀的同事给笔者的建议，他说，当你对一个业务比较了解的时候，就可以自己去推演。基本上能够提前推出哪里有问题和风险，并且能够有充足的时间和PM对接，对需求点进行完善。
- 邀请同组的同学对自己的方案进行check，不识庐山真面目，只缘身在此山中。有些问题，旁观者看的更清楚。
- 对于需要进行check的点，需要反复check，如上线计划，急停手段；带着主人翁意识去做事，面向失败设计。
如何画图来辅助自己熟悉业务流程
在上文中，我们提到读代码的过程中往往伴随着画图，那么我们应当如何画图来辅助自己熟悉业务流程？
首先我们应当选择一款适合自己的画图工具，比如visio、processon、亿图图示工具等。
有了工具之后，我们需要了解常用的图例，系统学习UML，对主要的几种图形有所了解，比如泳道图、用例图、流程图、ER图。
画图不在于形式，而在于突出思路和重点，画图的过程中，尽量使图形有层次感，想清楚图是给谁看的，先保证内容契合思路、业务，再进行优化与进一步美化。
应当如何学习掌握领域知识
我们常说，技术是为业务服务的，技术为业务赋能，而业务又促进了技术的演进和发展。
这里的业务往深了说，其实就是所谓的领域，每个领域都有自身领域的知识，用时髦的说法就是所谓的“统一语言”。
我们说，要有深度和广度，单论广度，就是要学习本行业的领域知识，完善自己的对业务体系的认知。
我们对常见的一些领域进行举例：比如说电商中的订单、 物流、支付、销运、清结算、风控、广告等，都是一个一个的业务领域。每个领域都有自己领域内的统一语言。
我们需要对领域内的统一语言、通用名词进行学习和掌握，这样既能够方便与他人的沟通，还能促使我们用专业的语言描述业务，进而促进代码编写的准确性。
这里我简单介绍几种学习业务领域知识的方法：
- 看书，看书是学习领域知识的一个通用方法。随着互联网的发展，业界已经有很多先驱对自己熟悉的领域进行了梳理和总结，我们如果能够进行学习，就站在了巨人的肩膀上，免去了自己进行探索所花费的时间。比如说，广告行业，基本不错的书籍如《程序化广告》、 《计算广告》、 《信息流广告》，电商领域的《电商产品经理》等书籍都是不错的学习资料；
- 和别人交流，进入新的工作环境，周围的同事都是老师。带着自己的思考和问题，友好的与同事讨论，沟通，请教，也是提高自己业务领域知识了解的一种方式，大部分情况下，有经验的同事会给出一个学习的方向，这是很宝贵的资源。
- 多看文档，成熟的企业内部往往都有文档的沉淀。找到这些资料并加以学习，对于自己的提高是相当显著的。如果恰巧你的公司就有这样的条件，那么千万不要忽略。
对于新人来讲，对一个新的业务领域建立了一个初步的认知之后，基本上能够应对简单的需求开发任务了。否则连需求都理解不了，那还谈何开展工作呢？
这里我还要多说两句，除了掌握业务领域知识外，最好去了解学习一些 领域驱动设计 的思想和概念，不断促使自己站在系统整体的思想高度去思考设计自己的系统。毫不夸张的说，“领域驱动设计”是开发者能力突破的秘诀之一。
对于方案设计有哪些技巧和注意点
这一部分，我们了解一下一个需求的方案设计要注意哪些点。
这部分内容是从笔者的工作中抽象总结出来的，去除了工作特征明显的点，提炼出了共性的注意点。基本上需求的快速迭代需要注意的点都包含进去了：
方案设计我们主要从以下几个点进行说明：
- 需求背景与目标：交代一下这个需求要解决什么问题，达到怎样的目的。这部分内容一般都是PM直接提供的；
- 概要设计：为了满足产品需求，我们主要需要从哪些地方进行设计，主要有哪些功能点，这里尽量提供一个全流程的泳道图；
- 详细设计：对概要设计中提到的功能点进行细化，针对每个功能点，给出流程图；不一定非得细化到伪代码级别，但是关键的条件判断和分支都需要体现，能够促使我们提前对逻辑进行深入的思考，也能提升编码效率；
- 数据结构：重要的领域模型是如何进行建模的，类如何设计，在这部分展示。一般需要提供类图/ER图；
- 接口设计：如果需要对外提供接口，那么我们就需要提供对外的接口文档，作为对外交互的依据；
- 配置设计：配置设计主要是针对关键逻辑的降级开关和某些业务阈值，如果线上确实出现问题需要紧急降级，那么我们就可以在文档中快速获取到开关配置，短时间内通过配置急停开关对问题逻辑进行快速下线；
- 灰度计划：对于重要的项目，我们都不会直接全量，都会通过灰度计划逐步将新逻辑推到全量；提前设计好灰度计划，能够让自己在灰度的过程中从容不迫；
- 监控指标：对于关键业务逻辑，我们需要设计一些监控告警指标，比如通过钉钉告警，飞书告警，短信告警 电话告警，保证出现严重问题能够感知到，缩短处理问题的时间。对于监控而言，可以考虑使用CAT进行打点上报；
针对配置，我们再补充几点：
- 关于灰度，笔者之前发过一篇文章，专门进行过讲解，感兴趣的读者可以点击查看
- 急停开关，本质上是面向失败设计，让我们能够在不进行代码打包和重复上线的前提下，实现代码逻辑的热下线操作；
这里提到的，基本上就是一个方案设计过程中需要考虑的点，如果有遗留还请多多见谅。读者朋友也可以基于这些要点发展出适合自己的方案设计模板。
问题排查的大概思路
最后，来介绍一下问题排查的大概思路。
- 快速定位问题，经验很重要。同样的问题，不同经验的同学解决耗费的时间是有明显的区别的，因此我们需要不断了解系统的设计，了解业务上下游交互链路，并对业务中容易导致问题发生的节点进行重点排查和优化；
- 需要对公司内部的常见的监控/问题排查组件进行了解，知道使用什么工具解决什么问题，这样在出现问题的时候能够借助工具提升问题排查的速度。对于开源的问题排查工具也需要了解，重点吸收工具背后的原理和设计思路；
- 特殊问题需要特殊处理，如果问题定位困难，先想办法止损。待损失控制之后，再进行进一步的排查，要灵活一些。对于常规问题可以通过沉淀问题排查手册来进行辅助；
总结
写了这么多技术类的文章，本文应该算是目前最不技术的一篇。
我们主要讨论了“快速熟悉业务逻辑并辅助逻辑”的手段和一些常见的思路，如果你恰巧刚入职场，那么本文中的内容应该能够帮助你快速度过菜鸟阶段。
如果你觉得文章不错，欢迎点赞转发，祝每位读者都能建立起自己的一套思维框架，在职场中游刃有余。
版权声明：
原创不易，洗文可耻。除非注明，本博文章均为原创，转载请以链接形式标明本文地址。
