业务复杂度不够，如何深挖

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

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

不要把复杂度想复杂了

其实讨论这个问题首先我们要确定清楚，这个所谓的业务的复杂度，我们到底说的是什么的复杂度。对此，团队同学之前的文章曾作出以下的归纳，比较全面得对复杂度这个事情进行了涵盖：

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

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

所以虽然技术实现本身是立命之本，在讨论这点之前，我们还是应该先跳出来看看，其他几个维度上是否存在问题痛点，是否存在复杂度需要解决，这都是我们作为 Owner 需要去看的事情。

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

复杂来源于变化

从问题去发现复杂度，就是下一步的重点了。说到复杂度，大家最先想到的是什么？我最先想到的是算法的复杂度。算法的复杂度本质是衡量一个算法在资源上消耗的方法，其从时间和空间两个成本出发，去评价一个算法的成本。这个指标的评价方式也是很有意思的，它不是简单直接地去衡量时间本身的消耗总量，而是去衡量其随着处理的数据集大小变化而表现出来的增长趋势。

从算法复杂度衡量的方式中，我们可以得到一个很有趣的启示，当你总是关注与一个小场景下的问题时，你是非常难以评估复杂度的，当你在某些维度上把问题放大的时候，比如算法中的输入数据集大小，你才能够更清晰地抓住主要矛盾。

总结一下在我们日常工作中，可以去扩张思考的几个维度：

• 时间维度：看看随着未来的业务发展或者系统持续迭代，是否有一些问题会被扩大化复杂化
• 链路维度：如果目前处理的业务，是整个链路的一环，那可以跳出来看一下，是不是上下边界存在问题或比较模糊，或者链路怎么调整能够更好的解决问题。切忌一直在屎山上雕花，不破不立，不要拿着锤子看啥都是钉子。
• 规模维度：随着用户量，业务量的增加，是否存在一些问题被持续放大。比如我们去解决每天处理 N 次 1+1 的问题。如果我们的工作确定是每天做 10 次 1+1 的计算，那可能真的是没什么复杂度了。
• 横向维度：当然在这个场景下我们就可以看看，是不是有其他人也要做这个事情，从而提升我们所谓的增长规模。也就是横向维度。看看类似的问题在别的业务中是否存在共性，是不是可以用同一个方案去解决多个业务中的类似问题。

这些都是帮助我们去发现复杂度的方法。所以说复杂更多是来源于去解决未来不确定的变化。一个问题之所以复杂，往往是我们因为我们希望我们的方案在未来依然能够解决这类问题。

为未来做投资

之前有同学曾经提出过一个问题：“很多事情简单做业务目标就能达成，但是技术深度体现不出来，团队同学成长就有限。更优的方案意味着更多的投入，在业务压力较大的情况下，各方也会挑战你的方案，如何抉择？”

这个其实一个比较常见的问题，“这个事情可以简单点搞嘛，不要搞这么复杂”，每每当我们照着上面复杂度分析心法去做了方案之后，总有一些人会跳出来说这些话，抱怨我们没有考虑 ROI 云云。首先，如果是 Leader 和你说这话，你可以在心中先默念一句“SB”，哈哈哈。当然骂归骂，我们还是需要仔细分析一下，对方说得是否有道理。

首先我们一定要再次确认一下，我们的方案是否是用来解决我们已经定义出的痛点问题的，以及方案的复杂度是否是根据我们上面讲到的几个维度去考虑所得出的结论。如果这两点不满足，请你先自己反思一下。如果依然觉得是正确的，那下一步就是把推导的依据和思考做对焦，看是否有一些误判在里面。

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

时机这个问题本身又涉及了“远见”，有时候我们是把未来的投入提前到了现在，从而减少整个时间轴上的整体投入。我们可以先把这方面的考虑尝试和合作方沟通，看是否能达成共识。如果对方比较短视（可以考虑不合作，需要与 TL 对焦），或者有时间上的硬指标，那我们就需要看看是否能得到更多的资源投入。一方面可以是可以自己主动多投入一些帮助自己成长，一方面是和 TL 沟通，看看团队中是不是这个事情更有价值，来投入更多的同学去一起完成。

就像是条条大路通罗马，今天你可以自己双脚踏出一条小路，但是可能过几天就杂草丛生，需要重新开辟一条路径；也可以号召大家建设一条宽广大道，福惠百世。只要你坚信罗马永远是罗马。

作者：ES2049 / armslave00

文章可随意转载，但请保留此原文链接。
非常欢迎有激情的你加入 ES2049 Studio，简历请发送至 [e-mail] 。