最近在思考，我们常说的技术广度和深度，在实际工作中到底指代什么？怎样的工作是有深度？怎样的技术是广度呢？

技术深度到底是指什么？

上一篇 聊技术开的职业发展，其实也有讲到技术深度和广度的问题，但我觉得这个问题可以再进行更多的探讨。

在过去工作的这么多年来，我一直认为：只有在某个技术领域达到足够的深度，才能保持自己在该行业的竞争力。这也是我在某段职业发展规划中的方向，其中的几次换工作，都往“更大的平台和团队”、“更复杂的业务”这样的方向去走。

实际上，在各个团队和项目中的一些经历，让我重新思考起来，我们常说的所谓技术深度，到底是指什么呢？

复杂的业务真的复杂吗？

我们经常会调侃自己的工作，比如切图仔、CRUD 工程师、调参工程师。很多时候，当我们掌握了当前工作涉及的技术和技巧之后，剩余的常常只有重复枯燥的工作日常，比如查 BUG、写 BUG、和产品同学扯皮、和测试同学吵架、用夸张手法写汇报，等等。

当我在做一些自认为简单的业务时，就会向往复杂的业务。在我的经历中，在业务场景比较简单的时候，大家为了晋级和考核，都倾向于将简单的事情变复杂，然后再用“有难度”的解决方案去解决，正所谓“没事找事”。那时候我觉得，如果业务本身足够复杂，就会有足够多的事情值得去解决，而不需要凭空捏造出这些复杂的场景，更不需要为了让解决方案看起来复杂，而特意让业务逻辑变得复杂。

在复杂的业务团队里，的确会有特别多的新知识和技术可以学习，也可以接触到大的业务场景下不同的领域模块。但实际上，对于大多数开发的日常工作，依然是基于某块业务的开发和维护，或是由于业务过于复杂，每天都被各种模块间的耦合相互影响、依赖各种上下游、莫名其妙出现的 BUG 等等，也没有足够的时间去研究。

而当我开始尝试解决以前认为足够复杂的业务场景时，发现再复杂的问题，也依然可以将其梳理并一一拆解，然后再逐个击破去解决。在工程化的业务里，我们用到的 99% 的技术方案，几乎都是通过现有的一些技术方案，进行适配、改造、调整后，尝试在业务中落地。以前我觉得涉及到算法和数据结构的业务，可能会面临较大的挑战、有足够的技术深度。但实际上，我们也还是在参考业界的方案，或是研究已发布的论文，结合业务的痛点去尝试解决。

技术调研、工程落地、项目管理这样的技能在工作中的占比更大，但它们似乎更倾向于职场技巧而不是专业技能，于是我不禁怀疑：怎样的工作内容才能算作是有技术深度呢？

简单的业务真的简单吗？

以前所在的一个业务团队，团队的业务核心偏向后台，于是整体上会对前端不够重视，不管是考核还是晋级都是前后端一起，评委也基本都是是后台开发。

作为前端开发，在这样的团队里成长很局限，包括前端的基础建设有很多问题、整体的技术栈都很落后、前端相关的优化不被重视等等。虽然我也做了很多的事情尝试去推动，但后面被告知需要做一个对团队和业务“更有价值”的事情，才能拿到好的考核。于是，我离开了（当然，技术成长只是团队的其中一个问题而已）。

在走了一段时间之后，同一个大团队的其他小分队找我，问我要不要去他们那边，说很缺有能力的前端开发。当我提到业务比较简单的时候，对方说了一句：都说业务简单简单，为什么就是有很多问题、做不好呢？

于是，我又陷入了沉思。

的确，该类型的业务对前端来说，或许技术栈比较简单，无非就是小程序或是常见的前端框架套件。但实际上由于这块一直被轻视，甚至大家都认为后端开发也能轻松实现一些前端功能，而我看见的常常是“复制粘贴+改变量名”的方式来实现功能，可想而知再简单的业务也能被维护得足够复杂。

再者，业务场景虽然简单，但用户量、安全等要求都比较高，因此对数据上报、监控治理有较大的要求，这方面很少有人愿意去把它做好，而实际上要持续地维护好也并不是那么容易的。

所以，再简单的业务场景，都存在可以优化的地方，“把每一个细节仔细剖析再层层研究”，能做到的人又有多少呢？但要能做到这一点的人，不管在怎样的业务和团队里，都能持续不断地学到新的知识、获得更多的经验，不管是广度还是深度。

技术深度是伪命题吗？

最近会跟一些朋友讨论这个话题：技术深度到底是不是伪命题？

我的想法是，所谓的技术深度，大多数时候都是由自己的工作经历和项目经验决定的。有些开发的工作中接触到的技术范围较广，所以会有“技术广度”；有些开发在工作中一直接触某个领域的业务，那么他便会拥有该垂直领域的“技术深度”。

有个朋友举了个例子，说他认为技术深度的确会存在，因为他们曾经遇到过一个大家都觉得“莫名其妙”的问题，是一位 P8 的技术专家一层层剖析解开，最终发现是某个十分底层系统中使用的网络包存在缺陷。他认为，大多数的开发能力是不足以定位到如此深入和细致的问题的。

我的看法不大一样，或许是这位技术专家以前有过相关经验，不管是曾经遇到过类似的问题也好，还是他对问题定位有自己成熟的经验和方法，这都是由他过去的工作经历决定的。一个一直基于某个领域深挖的技术开发，只要不止步于前，经验和时间的沉淀都会给他带来在这个领域足够的深度。同样的，如果在各个领域间不断转换和研究的技术开发，也可以在广度方向上有足够多的经验和沉淀。当然，对比如今很多只说不做、用漂亮的汇报话术和 PPT 成为技术专家的开发来说，这样能在关键时刻替大家解决问题、而不是指指点点的开发才称得上为真正的专家。

只能说，如今的行业状态是，很多人可以凭借“表现”和“包装”获得好的考核和职级，因此总有一些技术管理或是技术专家并不能真正地让人信服。相比之下，凭借扎实的项目经验和解决问题能力往上走的开发，很多时候则是被大家成为“技术很强”的专家了。大多数时候，我们追求的所谓“技术深度”，大概也便是这样了。

当然，广度和深度的要求还是有差别的。大多数时候追求广度容易“泛而不精”，而追求深度则可能领域外“一窍不通”，对于每个希望成为技术专家的人来说，做好广度和深度的平衡也是职业发展中重要的一环。

在我看来，每个人的技术能力，不管是深度还是广度，都跟自身的经历和成长有关系。简单说来，过去的经验造就了每一个开发，而是否能有效地发挥和吸收这些经验，决定了不同开发的技术能力和成长速度。

所以，在职业规划的时候，也不必太过执着于做的事情是否足够复杂、是否有更好的晋级/考核机会、是否是自己想要的广度或是深度，光是认真而踏实地把手上的每一件事做好，就可以收获足够的成长了。

查看Github有更多内容噢：https://github.com/godbasin
更欢迎来被删的前端游乐场边撸猫边学前端噢

如果你想要关注日常生活中的我，欢迎关注“牧羊的猪”公众号噢

作者：被删

出处：https://godbasin.github.io

本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。