“我做的事件，复杂度不太够，可怎么办呀”这样一句感叹，可能是大厂前端局部同学在工作中总有一天会听到的心声。因为在这里，有有数的人会问你：“做成这个事件，你在外面做了什么？”“你做和他做，有什么不同？”等等。每个人都想做牛逼的事，一举成名，可仿佛牛逼的事件就这么多，我手上的事件怎么就牛逼不起来呢，听起来就像一个三线小厂的新人也能自若应答。

那么，这个复杂度，咱们怎么“深挖”呢？留神这里为什么用挖这个动词，因为复杂度其实就埋在了咱们本人的陈见之下。上面就让咱们一层层地去刨开来看看。

不要把复杂度想简单了

其实探讨这个问题首先咱们要确定分明，这个所谓的业务的复杂度，咱们到底说的是什么的复杂度。对此，团队同学之前的文章曾作出以下的演绎，比拟全面得对复杂度这个事件进行了涵盖：

• 形容这件事件有多艰难 ：事件所处业务背景的复杂程度。
• 产生这件事件有多艰难 ：事物所牵扯的各方利益、业务边界、生产力关系的复杂程度。
• 实现这件事件有多艰难 ：具体实现事件，面对的技术挑战的复杂程度。
• 证实事件正确有多艰难 ：具体掂量事件的价值的复杂程度。

我晓得，其实同学们常说的复杂度可能是第三个，实现上有多艰难。很多前端同学如魔怔般得在这一点上往下刨，还记得已经有几年，每个团队都想搞个本人的大而全的框架，尽管也和过后时代背景无关，但多多少少还是有些过于“钻”了。

所以尽管技术实现自身是立命之本，在探讨这点之前，咱们还是应该先跳进去看看，其余几个维度上是否存在问题痛点，是否存在复杂度须要解决，这都是咱们作为 Owner 须要去看的事件。

那么如何去判断某一维度是否存在复杂度呢，第一步就是要可能讲清楚现状，不论是理分明业务概念业务逻辑，还是理分明单干形式单干边界，还是理分明架构模式等，有了清晰的全局感，能力帮忙咱们更好地去做剖析。第二步就是去定义痛点，不论是从本人 / 合作方 / 用户任何视角登程，咱们能够去被动寻找痛点，依据痛点去筛选，哪些是重点问题，从问题自身去发现复杂度。毕竟咱们作为工程师，实质上的职责就是通过剖析问题，筛选合乎问题场景的技术进行组合调参，从而解决问题。不论是哪个工程畛域，都是一样的。

简单来源于变动

从问题去发现复杂度，就是下一步的重点了。说到复杂度，大家最先想到的是什么？我最先想到的是算法的复杂度。算法的复杂度实质是掂量一个算法在资源上耗费的办法，其从工夫和空间两个老本登程，去评估一个算法的老本。这个指标的评估形式也是很有意思的，它不是简略间接地去掂量工夫自身的耗费总量，而是去掂量其随着解决的数据集大小变动而体现进去的增长趋势。

从算法复杂度掂量的形式中，咱们能够失去一个很乏味的启发，当你总是关注与一个小场景下的问题时，你是十分难以评估复杂度的，当你在某些维度上把问题放大的时候，比方算法中的输出数据集大小，你才可能更清晰地抓住主要矛盾。

总结一下在咱们日常工作中，能够去扩张思考的几个维度：

• 工夫维度：看看随着将来的业务倒退或者零碎继续迭代，是否有一些问题会被扩大化复杂化
• 链路维度：如果目前解决的业务，是整个链路的一环，那能够跳出来看一下，是不是高低边界存在问题或比拟含糊，或者链路怎么调整可能更好的解决问题。切忌始终在屎山上雕花，不破不立，不要拿着锤子看啥都是钉子。
• 规模维度：随着用户量，业务量的减少，是否存在一些问题被继续放大。比方咱们去解决每天解决 N 次 1+1 的问题。如果咱们的工作确定是每天做 10 次 1+1 的计算，那可能真的是没什么复杂度了。
• 横向维度：当然在这个场景下咱们就能够看看，是不是有其他人也要做这个事件，从而晋升咱们所谓的增长规模。也就是横向维度。看看相似的问题在别的业务中是否存在共性，是不是能够用同一个计划去解决多个业务中的相似问题。

这些都是帮忙咱们去发现复杂度的办法。所以说简单更多是来源于去解决将来不确定的变动。一个问题之所以简单，往往是咱们因为咱们心愿咱们的计划在将来仍然可能解决这类问题。

为将来做投资

之前有同学已经提出过一个问题：“很多事件简略做业务指标就能达成，然而技术深度体现不进去，团队同学成长就无限。更优的计划意味着更多的投入，在业务压力较大的状况下，各方也会挑战你的计划，如何抉择？”

这个其实一个比拟常见的问题，“这个事件能够简略点搞嘛，不要搞这么简单”，每每当咱们照着下面复杂度剖析心法去做了计划之后，总有一些人会跳出来说这些话，埋怨咱们没有思考 ROI 云云。首先，如果是 Leader 和你说这话，你能够在心中先默念一句“SB”，哈哈哈。当然骂归骂，咱们还是须要仔细分析一下，对方说得是否有情理。

首先咱们肯定要再次确认一下，咱们的计划是否是用来解决咱们曾经定义出的痛点问题的，以及计划的复杂度是否是依据咱们下面讲到的几个维度去思考所得出的论断。如果这两点不满足，请你先本人反思一下。如果仍然感觉是正确的，那下一步就是把推导的根据和思考做对焦，看是否有一些误判在外面。

通过这些步骤，咱们至多能确认计划自身是具备合理性的。那这里除了计划自身的复杂度是否正当之外，就还有一个“机会”的问题。有些时候你发现了 规模因素、老本点，然而有些状况是在很长一段时间内其实并不会产生增长，这时候你过早地做了计划，一方面可能会因为业务变更被废除，另一方面可能也并看不太出成果。就像 1+1 的运算，执行 1 次和执行 10 次，对于古代 CPU 来说感触不到区别。

机会这个问题自身又波及了“远见”，有时候咱们是把将来的投入提前到了当初，从而缩小整个时间轴上的整体投入。咱们能够先把这方面的思考尝试和合作方沟通，看是否能达成共识。如果对方比拟短视（能够思考不单干，须要与 TL 对焦），或者有工夫上的硬指标，那咱们就须要看看是否能失去更多的资源投入。一方面能够是能够本人被动多投入一些帮忙本人成长，一方面是和 TL 沟通，看看团队中是不是这个事件更有价值，来投入更多的同学去一起实现。

就像是条条大路通罗马，明天你能够本人双脚踏出一条小路，然而可能过几天就杂草丛生，须要从新开拓一条门路；也能够号召大家建设一条广阔小道，福惠百世。只有你深信罗马永远是罗马。

作者：ES2049 / armslave00

文章可随便转载，但请保留此原文链接。
十分欢送有激情的你退出 ES2049 Studio，简历请发送至 caijun.hcj@alibaba-inc.com。