文章目录
  1. 1. 技术深度到底是指什么?
    1. 1.1. 复杂的业务真的复杂吗?
    2. 1.2. 简单的业务真的简单吗?
    3. 1.3. 技术深度是伪命题吗?
    4. 1.4. 结束语

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

技术深度到底是指什么?

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

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

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

复杂的业务真的复杂吗?

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

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

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

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

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

简单的业务真的简单吗?

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

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

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

于是,我又陷入了沉思。

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

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

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

技术深度是伪命题吗?

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

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

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

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

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

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

结束语

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

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

码生艰难,写文不易,给我家猪囤点猫粮了喵~

B站: 被删

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

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

作者:被删

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

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

文章目录
  1. 1. 技术深度到底是指什么?
    1. 1.1. 复杂的业务真的复杂吗?
    2. 1.2. 简单的业务真的简单吗?
    3. 1.3. 技术深度是伪命题吗?
    4. 1.4. 结束语