当时答主内心想的是：「完了，开发了几个月的产品, 上线后，尽然是这样的，年终奖没了不要说，明年回来，肯定要重新找工作了，我不仅坑了自己，还坑了我的主管」 ，当时的内心可谓极度惶恐。

解决问题的方式

经历过一番内心挣扎后，觉得这样惶恐下去，解决不了问题，然后就冷静下来，尽可能地去查找时序资料库 InfluxDB 相关的分享文章，希望能从中找到一些性能瓶颈相关的资料。幸运的是，在饿了么团队的一次分享中，我找到一点引起问题的线索，然后开始从资料库表结构设计、计算查询优化等方面著手，逐步地进行了优化。并将整个优化过程以文档的形式做了记录(数据已脱敏，感兴趣的同学可以看下)，在组内周报中做了分享。

后续

在后续持续关注 InfluxDB 的过程中，我也在网路博客中，发现了一位 InfluxDB 专家，深入浅出地介绍 InfluxDB 引擎的实现原理。非常幸运的是，这位专家正好是我们网易的同事。

之后我梳理了我们『前端错误监控平台』当前的技术架构、自己在时序资料库方面的优化经验、遇到的难点与痛点等。带著这些问题，与专家约见交流。

回来之后，收获非常大，为了避免自己遗忘，随手就写了一篇《前端性能监控-存储与计算架构展望》，之所以是展示，是因为在当时，由于一些原因没有办法很快落地。

但这次交流，为我们后续平台的技术架构升级，埋下了基础，在19年里当我们再一次遇到存储与计算瓶颈时，帮助我们逐步地完成了技术升级。

总结

• 遇事不要恐慌，要冷静下来，逐步分析。
• 尽可能多地参考业界的文章、分享。
• 解决问题后，要及时进行梳理总结。
• 积累一定实践经验后，也可与领域专家交流，进一步提升自己的认知。

以上。

最近有点魔怔了，看到问题第一反应是：如何定义「复杂需求」。

咱就不讨论什么是复杂需求了，列举以下我最近两年里做过的几段有挑战性的工作：

• 可视化网页编辑器
• BI 系统
• 后端代码静态分析工具

后端代码静态分析工具

这段经历距离最近，印象还没有模糊，就只讲它好了。

大背景是我们正在推广 OpenAPI 的那套开发工作流。

大体意思是 API 是我们大家的，不是后端代码的副产物。因此我们将 API 独立出来形成契约，让前端、后端、QA 都可以围绕契约各司其职高效协作，提升 API 的可靠性。

到了实施层面，我们面临的第一个问题就是，如何让契约发挥效力，而不是一纸空文。

社区中最常见的方案是用 Schema 自动生成 API 的 entrypoint 介面，所有的代码实现都会在介面层面被限制，确保返回的结果是符合定义的。该方案效力很好，但是代价很大--侵入后端代码太多，对现存 API 的改造较多，高成本高风险，立刻就被否定了。

紧接著讨论的是在 API Gateway 上拉 raw response log ，定期检查，发现问题及时抛出。现在想来我提出的这个方案有点蠢，滞后于错误的发生：错误出现了，过几个小时，它才不疾不徐慢慢悠悠抛出警告。基本就只是个问责机制，对于解决问题不太正面。

接下来就是呼应标题了，我们决定对后端代码做静态分析--后端语言是 Java ，可以分析入口函数的返回值类型，难度不大，收益也不错。

好的，终于开始写代码了。

作为一个从没学过编译原理的假科班，我其实并不太慌。毕竟前端圈子玩 AST 不是一天两天了，虽然没接触过相关项目，但概念总归是知道一些的。

整理思路

工程师要解决一个领域的问题时，往往需要掌握以下几点：

• 领域知识
• runtime api
• 常用范式
• 编程素养

在我们熟悉的前端领域，这几点分别可以对应为：

• Web 基础
• 浏览器 API
• 掌握 React、Vue 等常用框架及其对应的范式
• 数据结构、演算法、抽象能力

而我面对的这个需求，已经掌握的情报是：可以将 Java 代码转化为 AST ，它就是一个树的数据结构，我可以遍历它来获得代码的语法信息。

至于这个 AST 怎么来，当然是调包啦。

通过知乎搜索，我找到 Antlr 4 这个由 Java 编写的工具，它可以根据语法定义生成对应语言的解析器，并提供了 JS Runtime ，还提供了 Listener 和 Visitor 两种模式，方便用户高效得浏览 AST 。

在实际的摸索和学习中，我熟练掌握了 JS Runtime API 的使用，也大体了解了 Java 语法树的关键字和规则。范式方面我选择了简单易上手的 Listener 模式。

至此，前三个要素就齐备了：

• 知道 AST 是什么、Java 语法树有哪些关键字、大致规则
• JS Runtime API
• 掌握 Listener 模式

解决问题

已经学会了解析处理 AST ，接下来就该解决问题了。

这时候思路已经很清晰了，分为三步：

1. 找到入口函数，获取 path、method 等元数据
2. resolve types
3. 和 Schema 中定义的类型做比对

这里 1、3 两点都很简单，值得一说的是 *resolve types*

可以分为三个小点说一说：

• 中间 DSL
• 范型解析
• 类型容错和扩展

中间 DSL

将 Java 的类型解析为中间 DSL ，再拿中间 DSL 去和 Schema 做比对是一个非常符合直觉的做法。一定要说为什么不直接解析为 OpenAPI 规范的 Schema ，我觉得可以讲出以下几点：

• OpenAPI 的 Schema 不止有类型，还有一些相对于 Java 类型来说冗余的东西，如 number 类型有最大值最小值。
• OpenAPI 的 Schema 升级之后，我也得跟著升级，在后端使用的 Java 版本几乎不变的情况下，这是不应该发生的。
• 有一天 OpenAPI 也可能被取代掉。

于是我定义了如下 DSL 来表示 Java 类型：

// 基础类型
string, integer, number, any, null, boolean, void

// 复合类型
// object
{
str: string,
num: number
}

// array

// string[]
[string]

// {str: string}[]
[{ str: string }]

范型解析 类型容错和扩展

这两点拿来一起说，算是我在写工具过程中碰到的有一定抽象高度的环节。

有一些类型并不在该 Repo 的代码里，而是来自 jar 包。jar 包是二进位的，我手里的工具一时半会处理不了。即使花精力处理了，收益也较低。因此，我需要处理一些类型不存在的情况。

还有一类情况是，Java 代码中类型被序列化为 JSON 是由第三方库完成的。这个第三方库有自己的转换规则，我既需要适应这个库对类型的处理，又不能完全针对这个库写特化的程序。因此，我需要加上一些扩展能力。

如下 Java 代码：

@data
public class CommonRet& implements Serializable {
private String code = SUCCESS;
private String message;
private MessageDetail messageDetail;
private T data;

public CommonRet() {}

public CommonRet(T data) {
setData(data);
}

}

我需要面对如下情景：

• CommonRet& 中的 long 直接映射为 DSL 中的 number 基础类型
• CommonRet& 中的 Long（注意首字母大写）也映射为 number 基础类型，即使 Long 本身不是 Java 的基础类型
• CommonRet&&> 这里要处理好范型
• CommonRet&&> 的范型解析应该在 List& 处结束，把 List 映射为基础类型

为了达到如上列举的效果，我做了如下设计：

定义一系列终点类型的函数，该函数直接输出 DSL 定义的类型：

const finalResolvers = [
String: () =&> string, //String =&> 『string』
List: t =&> [t] //List& =&> [string]
]

终点类型可以跟随 DSL 随时扩展。

解析范型一定是一个递归的过程，递归的终点即当前 Symbol 是 finalResolvers 的一员：

function resolveType(type) {
const [symbol, ...params] = handleType(type) // List& =&> [List, String]
if (finalResolvers[symbol]) {
return finalResolvers[symbol](...params.map(param =&> resolveType))
}
}


这样，就成功建立起一个解析的核心机制，将 Java 代码中的 Symbol 递归解析到我们定义的终点类型，终点类型映射到 DSL 中定义的类型。并且我们可以轻松地随时扩展这两种类型。

例如我们已经有 boolean 作为终点类型，代码中的 boolean 都会转为终点类型 () =&> boolean 。有一天突然发现有一个未定义的新类型：Boolean ，我们只需将 Boolean 加入扩展即可。

收尾

上述经历不是在告诉大家「xxx不过如此」，我只是粗浅入门解决了一个非常简单的问题。

从中可以窥见的是，面对未知领域时，存在一些通用的解决问题的办法。而我们在学习工作中磨练起来的编程素养，将是最值得依靠的保障。

看了各位大佬的回答，我决定不把我的需求说出来，仿佛我是一个切图仔，连切图都切不好的仔