1. 引言

本周的精读是有感而发。

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

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

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

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

不过笔者的观念也在逐渐发生转变，渐渐自己也在朝着当初反感的方向发展，觉得这一定不是偶然，所以就整理了一下感悟，希望可以证明这个发展路径的必然性。

2. 精读

Warn：本文所说的技术专家，仅针对研究上层技术的专家，不包括底层技术专家。
在 Google 底层专家人数极少，大部分专家都要走业务技术的路线。

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

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

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

本文将从三个点去解释，为什么专家看上去越来越远离技术细节。

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. 技术最终为业务服务，懂技术细节和让业务先赢没有必然的关系，所以在深入技术细节之前，要先理解业务，把握方向，防止技术细节出现路线问题。

special Sponsors

• DevOps 全流程平台

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