精读《为何专家再也不关心技术细节》

1. 引言

本周的精读是有感而发。

笔者接触前端已有八年，观察了很多前端大牛的发展路径，发现成功的人都具备类似的经历：

初期技术热情极大 -> 大量标志性技术项目 -> 转向综合性思考 -> 带团队/关注方法论

也就是专家们变得愈来愈不关心技术细节。须要说明是的，这里说的专家再也不关心细节，不表明成为专家后学不会细节，也不表明专家不了解细节。

早期挺难理解这种转变的，笔者在学校里的知名度来自于前端作得精深，一根筋钻研技术的人眼里是容不下沙子的，因此当初为一些前辈转到管理特别不理解，认为他们背叛了前端。

不过笔者的观念也在逐渐发生转变，渐渐本身也在朝着当初反感的方向发展，以为这必定不是偶然，因此就整理了一下感悟，但愿能够证实这个发展路径的必然性。

2. 精读

首先咱们要明确技术员与科学家的区别，为业务提供技术支持都是技术员，因此前端是一门技术，不是科学。

另外，技术的发展须要商业推进，没有使用场景的国家是很难推进技术进步的，科学除外。

因此业务技术是具有可持续发展的路线，毕竟你们都要吃饭，有业务价值的项目会活下来，附着在业务上的技术才能活下来，才有可能开枝散叶。

本文将从三个点去解释，为何专家看上去愈来愈原理技术细节。

2.1 技术细节对我的的重要性是在变化的

随着工做年限增长，技术细节重要性在慢慢下降，反之技术视野重要性在慢慢增长。

在找工做初期，技术细节是重要的敲门砖

大学毕业的那段时间，技术细节是一块重要的敲门砖，只有掌握好技术，才会有公司愿意要你。

这也是为何说毕业生不要一进公司就谈战略，由于时机不对。

技术不是科学，普通人下功夫能够学会

学习技术不须要很聪明的头脑，只要肯下功夫，拥有不错的理解能力，任何人均可以把技术细节搞清楚。

也就是学习技术细节是没有技术门槛，随着年龄的增长，若是只累积了你们都能学会的内容，那么当旧知识被淘汰后，学习新知识的速度又不如年轻人快，会逐渐失去经验优点。

那么如何利用无门槛的特征，将其变为门槛呢？那就是任何年龄段学习技术细节都很容易，在你须要深刻细节的时候再深刻进去，不须要深刻的时候把时间花在了解宏观架构上。

就是培养高效的学习能力，能准确判断某个技术细节是否有必要掌握，如须要该如何快速掌握核心内容，并在掌握以后不留恋，能够快速抽身出来继续全局性思考。这种思惟是有门槛的，技术专家均可以作到这一点。

作成事不必定要搞懂细节

乍一看有点匪夷所思：不了解细节怎么能作成事？

虽然理解技术细节能够作成事，但作成事不必定须要理解业务细节。

这要看怎么理解业务与技术的关系，好比建设 “数据联邦”，光是了解各个不一样的存储系统技术细节可能就要花好久，而其实是不必将全部技术细节都弄懂的，只要定好一个通用交互规范，各存储系统各自封装一套符合这个规范的交互接口便可。

作成事每每须要宏观的技术思惟，须要将许多技术点连接在一块儿。举个例子，作成事就相似于军官指挥做战，作成的目的是经过制定打法赢得战争，而不是本身冲锋陷阵并测量敌人壕沟的宽度。关心技术细节只最终落实到每一个人具体实施项中的一部分，技术细节的目标累加起来才是作成事。

2.2 搞清楚业务对技术的真实诉求

业务指望经过技术实现功能，因此技术专家要作的是如何更好的实现业务需求，这就意味着理解业务需求是第一重要的能力。试想一个不能理解业务要作什么的人，即使懂得再多技术细节，对业务也是没有价值的。

业务思惟是解决问题，技术思惟是创造问题

拥有技术思惟的人，容易沉迷于解决不切实际的问题，或者是别人解决过的问题。这种思惟对技术学习是很是有帮助的，但若是长期不能转变这种思惟，对公司来讲是没法创造什么价值的。

拥有业务思惟的人，首先要懂业务，只有懂业务，跟着对的业务，才能对将来又信心，知道本身的付出能够换来回报。

懂业务后，才知道如何经过技术帮助业务得到成功。

好比在一家创业公司，老板的眼光很准，进入的时机较早，市场是一片蓝海。你经过分析后，发现要帮助业务占领市场，只要利用某个成熟技术框架快速迭代，就能够在短时间帮助业务赢得市场。可是这个框架定制能力不强，若是新需求来了可能须要花时间重构掉。此时技术思惟的人只会考虑代码维护性，提出自研一套框架，而拥有业务思惟的技术专家会决定先用成熟的技术快速做出原型，等业务稳定后再重构掉。

固然如今互联网市场竞争很激烈，低技术门槛的蓝海基本已都变成了红海，上面提到的场景可能比较少见，咱们更多须要决策的是将来几年内业务的收益是否值得如今投入的研发资源。

两个会写框架的人，不如一个能决策的人

另外一个简单的例子就是，假如技术专家只会一头扎在技术细节里，对各类前端框架的实现了如指掌，你们都能造出优雅、易用、可维护，并且还带有各自 “特点优点” 的框架或者轮子，那么团队很容易陷入两个专家屁股决定脑壳的技术纷争中。这种状况下，两名技术专家的产出甚至不如一个实习生大，毕竟实习生直接拿来开源框架上手，99% 的状况可靠性比前端专家本身造的轮子更好。

从另外一个方面来讲，现阶段前端界能写出 React、Vue 框架的人太多了，已经写出来的类 React、Vue 的框架也数不过来。去掉为了练手而作的项目，真正但愿推广出去给别人用的还占绝大多数，这是开源界典型的问题：重复低水平造轮子不须要理由，推广给你用也不须要负责任。因为框架属于互联网虚拟资产，边界成本为零，这决定了框架市场必定是个大寡头市场，不可能有相似的项目经过一些不痛不痒的特点分一杯羹。那么就算招 10 个会写框架的人进入公司架构组，最后只有两种可能：要么架构臃肿，每一个人都把本身的一部分功劳加入进去；要么就是选择一个更很差的方案，这样不会损害任何一位架构师的利益。

因此如今公司更倾向于内部培养人才，由于内部的人了解业务须要什么，创造的价值每每比空降的架构师更大。

宽广的技术视野更容易借力

如今技术点愈来愈多，若是什么技术细节都要详细了解，最终必定不能有很好的全局视野。比较好的状态是找几个重点深刻了解，其余的技术点在掌握了全局技术视野后再考虑深刻。

在互联网初期，不少技术框架还不完善时，技术借力的意义不大，毕竟也没有多少东西可用。

可是如今不管前端仍是后端的技术、轮子已经眼花缭乱了，能掌握这些已有技术的人，价值已经逐渐大于会完整了解某些技术细节的人。一个优秀的专家应该能快速定位要解决的业务问题是否有成熟的技术方案，如何以最小的投入产出比实现，同时保持良好的维护性应变业务维护。

2.3 仅仅技术好是没法成为专家的

技术专家真的表明技术壁垒很强的人吗？是的，但只有技术能力是不够的。

为何开源项目后期要寻找协做者？

我作开源项目的初期，全部框架和源码都事必躬亲，以为本身有更好的点子能够赛过其余框架。初期不多有贡献者参与，固然我也不肯意其余贡献者参与，毕竟他们不了解设计理念，只有我本身的修改可让我满意。

还有谁比做者更了解他的开源项目呢？那为何一个大型开源项目运做到后期，基本都是协做者在维护？

由于开源是一件系统化的事情，若是你想长期维护他，必须创建好文档系统，让你的思路可复制，让他人可参与。若是开源项目只有你一我的懂，那么同时维护两个、四个、六个的时候，你定会发现力不从心。

至于一些开源大神一人维护几百甚至上千 Repo，背后必定有更多的贡献者支持，一我的就算辞职在家专职作开源，也很难同时维护超过 10 个开源项目。你须要拥有开放的心态让更多人加入进来，将成就感和荣誉感分一些给贡献者，他们才会持续为项目贡献。

可以调用资源才能成为专家

开源界就是项目抢占关注度的游戏。假设开源社区总人数为 100，你的项目可以吸引到 10 我的浏览，5 我的使用，2 我的贡献，基本就能存活下来。而开源社区至少有 100 个项目，社区总人数不足以支持每个项目，只有得到足够关注度的项目才能保持长青。

公司内也是如此，专家级以上的 Title 会要求协做能力，能够调动身边甚至其余部门资源的人才能在公司发挥更大的价值。

CEO 经过顶层设计调动了全公司资源，而业务线总裁经过任务拆解调动了整个业务线的人，经过层层目标拆解，并保证每一层都能充分调动下一层全部资源，公司才能高效的运转。

若是一直关心技术细节，你永远是一个孤立节点，在任何维度的组织中都是最底层，就算 24 小时不睡觉，也最多算两我的力资源。想要突破一天 24 小时的限制，就要花时间让别人认同你的设计，并朝着一个方向努力，你的节点才能上移，但随之而来的是承担更多风险，好比分配给别人的任务给弄砸了，为公司带来了不良影响，那么负责人就要背锅。

3. 总结

总结一下，本文的观点是：

1. 技术细节学习难度不大，在须要深刻的时候再深刻了解最佳。
2. 想要作成事，须要更宏观的技术思惟，因此专家渐渐变得眼光宽阔，格局很大。
3. 专家拥有快速学习技术细节的能力，只是这已不是其核心竞争力，因此与其写技术细节的文章，好比写方法论的思考带来的价值更大。
4. 指引方向比走路更重要，专家都要逐渐成为引路人。
5. 技术最终为业务服务，懂技术细节和让业务先赢没有必然的关系，因此在深刻技术细节以前，要先理解业务，把握方向，防止技术细节出现路线问题。

讨论地址是： 精读《为何专家再也不关心技术细节》 · Issue #153 · dt-fe/weekly

若是你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

<img width=200 src="https://img.alicdn.com/tfs/TB...;>

special Sponsors

• DevOps 全流程平台

版权声明：自由转载-非商用-非衍生-保持署名（ 创意共享 3.0 许可证）