『No22: 如何梳理代码逻辑』

大家好，我叫谢伟，是一名程序员。

最近状态不是很好，输出少了...

本节主题：如何梳理代码逻辑

在日常工作中，作为初中级程序员，大部分的工作是在实现业务逻辑，但有可能整个项目的代码，你不是第一个接手的，即代码结构不是你设计，前期的需求讨论你也没有参与，最常见的情况是，你接手的是半成品的项目。

这个时候需要你不断的完成需求。

那么如何快速的熟悉的项目，之前我讲过的一个方法是：使用相同的技术栈实现一个类似的项目。

上述的方法可以让你快速的熟练技术栈，比如技术选型，比如项目的组织，比如代码的风格。可以快速让你避免对技术的不适感。

但是存在什么问题？

即：你熟练了技术栈，但是对业务实现并没有实质性的帮助。怎么说？你借用相同的技术栈，需求的提出是你自己，需求的实现也是你自己，这样的总体实现起来，当然比较容易，你理所当然知道如何实现需求。

现实中的需求呢，常常是变动的，特别是创业公司，为了卖出产品，可能会在项目内完成一些客户提出的满足自己需要的需求，需要你定制，这个时候的需求来自客户，客户的需求可不管你的实现的难度和合理性。

这个时候，需要你对一个或者多个项目的实现细节比较熟悉，不然来的需求，你可能会不太清楚实现起来可能会遇到什么样的问题、实现的难度是什么。当然这些问题，随着你经验的越来越丰富，你会越来越熟练，越来会知道实现中的问题，以及时间的评估。

本节，讲述的是你经验不是那么足，如何快速的了解的项目并且快速实现需求。

1. 一个工具：思维导图

这个工具，有人用来梳理想法、有人用来拆分思维观点...

有手写的，也有借助APP等客户端设备的。

当初我用这个工具的想法很简单，即梳理想法，比如想写一篇文章，初期我会借用思维导图来梳理角度，列举文章的主要方面，比如先写什么，后写什么，想表达什么，用什么样的实例来辅助证明我的观点等。

前期也还纠结于如何手绘思维导图，把时间都纠结在绘制好看的思维导图层面，现在回头看看有点本末倒置了。

随着自己思维不断的演练，思维导图的功用越来越和列表差不多。

当然因人而异。

思维导图的功用是用来梳理想法之类，很多使用者使用经常用来提炼书籍的主要观点。

所以，理所当然可以用来梳理代码的逻辑。

2. 怎么用

• 理解项目结构
• 找到主程序入口
• 阅读源代码
• 再读一遍
• 边读边绘制思维导图
• 数据库（增删改查）

如何借用这个工具来梳理代码逻辑？

1. 理解项目结构

项目结构这事，我总是反复说，项目清晰的划分一定程度上体现在项目结构上，随着接触项目的越来越多，项目划分、项目结构都存在一定的共性。

比如，项目的配置信息、中间件、模型的定义、项目的入口、第三方包、编译脚本等

理解项目的结构是第一步，知道项目的哪个部分是用来做什么，哪些是辅助性的功能，哪些是核心实现的功能。

1. 主程序函数入口

在Go 语言中，主函数入口，就是 main 函数，但一般main 函数都不是那么明显，不是一眼可以看出功能来。

比如API 主函数，只是启动 Web 服务，开始监听端口，真正的函数入口有可能是设备捕获头像信息，将头像信息入库，成为数据库原始数据。

1. 阅读源代码

比如API 服务，这个好办，一个个接口看，看如何实现资源的增删改查，对应的动作是什么。绝大多数接口都只是完成对资源的简单操作，比如删除，比如获取，比如更新等。

这些不是我们进行思维导图的重点，重点应该是理解项目的原始数据的入口。

比如说这是一个机器视觉项目，摄像头是数据采集器，核心应该是在关注原始数据采集这块。

比如采集到的参数有哪些，涉及到的模型有哪些，对应的数据库内表有哪些，采集到一条数据，涉及哪些表操作等。这些才是我们需要阅读源代码的重点。

1. 再读一遍

没什么。书读百遍其义自现。

1. 边读遍绘制导图，不断修缮

• 传入的参数是什么
• 涉及的表有哪些
• 表为什么这么设计
• 表之间的关系是咋样的
• 中间件起到什么样的作用
• 程序结束的标志是什么

磕磕碰碰，中间可能还有不懂，实在琢磨不透，问问有经验的人。

3. 理解业务

• 根据思维导图更改代码实现需求

当你绘制完了，你对整个项目的理解更进一步了，这个时候最好的办法是不断的实现需求。根据自己的能力先想想如何自己实现需求以及对应的时间评估。

尽早完成需求，不断的向比自己高段位的程序员求证，需求的实现是不是正确的，delay 了 容易给人不靠谱的印象。有可能别人只要和你提个点，你就能更好的完成任务了呢。

4. 抛开代码理解业务

• 从商业的角度
• 从产品经理的角度

其实这个阶段的事不必单独抽出来，在实现需求的过程中都是不断的理解的。

因为需求，就是根据这些商业的需要才得到。你理解了商业的需要，你就知道需求，知道了需求的本质，产品经理给你的需求，你自己就可以考量，是否合理，需求是否是过度的，或者说换个角度，需求是不是更合理？

比如说，这是一个机器视觉项目。所有的数据源是图像，拍摄到的图像，进行算法识别，入库，再根据库内带有信息的图像进一步分析，得到一些商业价值。

都是识别场景，机场需要的识别场景可能和线下新零售的识别场景不一致。机场更多的识别人和物的安全性。新零售识别人，更多的是针对人给出商品推荐。

所以，在编写代码的过程中，你需要理解需求的来源，从商业和产品经理的角度思考需求。

你可能会觉得自己水平还不行，给需求就乖乖实现得了。

技术只是手段，最终的目的是完成好的产品，多思考合理性也许能不断的使产品更好，参与一款好的产品的过程，为什么不呢？

5. 反复和优化

• 爆炸式增长
• 渐进式增长

简单的实现业务需求，对一个后端工程师来说，这些远远不够。

只能实现需求，你的可替代性就强，核心竞争力就弱。因为随便找个对语言熟悉的人，都可以完成你的任务。

后端工程师，技能的精进，和数据量的大小还是有一定相关的，比如数据量只有10万级别，你可能怎么实现都可以，也不太会遇到难题，瓶颈等。

那假如 100万呢，1000万呢，1亿呢？这对后端工程师的要求显而易见吧？

通常来说，只要你不是做外包的，基本上你会持续的接触一个或者多个项目，项目会随着需求不断的变更。当然随着数据量的增多，项目的整体设计也可能需要变更。数据量的增多，有爆发式的，这种情况，没有一定的知识储备，解决起来非常的难，第一，你需要经验；第二，你需要团队。比如某APP 用户量瞬间从百万级到亿级，这种情况，没有足够的积累，不好意思，解决不了的。

再一种是渐进式，比如你卖出一个设备，数据量大概增加5万，这种渐进式呢，原则就是遇到问题，解决问题。或者提前储备知识，进行项目优化。

具体的过程，等我技术上升一个等级再来细说。

6. 总结

本节讲述的是如何进行代码逻辑的梳理。借助思维导图进行梳理。没有具体的使用实例，只是大概讲述了制作思维导图梳理代码逻辑的要点。

原因有二：

1. 我自己接手的项目不宜公开
2. 开源的项目大多不是偏业务型，都是框架类或者第三方库类。这种不太有承前启后的逻辑梳理。

希望大家喜欢。可以在实际的项目内多尝试。

谢谢，我是谢伟，再会。