四次选择（技术深度和广度的思考）

---

四次选择（技术深度和广度的思考）

概述

后端架构设计是一门很深的学问，尤其是现在底层技术的持续封装下，衍生出了各类针对不同场景的技术栈以及系统化方法论

就应用侧而言，自底向上需要持续学习的内容很多：
1. 计算机组成原理
2. 操作系统内核
3. 云化技术
4. 容器化技术
5. 大数据体系
6. 应用开发体系
7. …
除了容器化部分以外，这也是大多数大学里会进行知识普及的内容，帮助学生构建知识金字塔，给后续就业提供选择。

但是这种学习环境自工作后开始出现变化，纯技术的环境加入业务以后，开始进行分化，底层开发变得聚焦，应用开发方向，则由于业务的泛化性，广度开始无限扩散。尤其是在传统行业，两极分化尤为明显。

这就触发了两种流派，技术深度优先，专注于非功能性需求，技术广度优先，专注于业务覆盖和组合技巧。

在此，不讨论两种方式的对错，也不讨论具体技术架构，只是想聚焦这些年的经历和选择，给以后进行选择的人一些参考。

初入行业，无差别学习

和大多数计算机系毕业的人一样，初入社会的选择很多，在没有高人点拨，没有前瞻性指导的情况下，大多数人都会直接投入应用开发的怀抱，我也一样。

以具体业务为导向的上层语言开发，开发技巧主要来源于业务系统的组合以及各类语法糖，因为大部分核心代码基本被封装或者依赖开源组件。

在此时，好奇心胜过理性决策，就整个职业生涯而言本身并无太大影响。就思维层面，这时候首次出现的技术深度和广度思考意义也不会太大，应用层的框架五花八门，每一次切换或者集成都会给一个新入行的人极大的成就感，这就够了。

无论是学院派还是实践派，也都支持这种行为，也鼓励多尝试，多了解。

业务转通用开发，首次选择

但是初入行业的好奇心以及海绵式的学习状态无法维持太久。直接导向就是，开始从学习状态转变为自主思考，对技术的选择出现疑惑，真正的分歧点也就开始出现：越往上越重规划，越往下越重研究。

自此首次出现明确的深度和广度差异。

这也就诱发了大多数开发人员的首次选择：继续通过业务的广度来优化组合技巧，还是聚焦单向深度。

反应到现实，就是维持现状或者切换技术团队（大概率跳槽）。

我选择了后者，并从纯业务开发转向大型业务+通用服务，也就是说深度上的选择（起码我是这么认为的）

扩充知识体系，诱发二次选择

可惜的是，首次转向并未明显打破原本的工作模式，虽然也涉及到部分非功能需求，从纯业务组合开发者变为中间层服务的开发者，但是依旧无法解决，框架技术无法渗透的问题，后期随着团队扩大，越明确的分工，这部分问题越明显。

如何打破壁垒，在这个阶段我做了几件事：
1. 买了大量的书籍，进行更加体系化的了解，提升业务的鉴别度
2. 尝试了解各种技术新特性，来增加在团队讨论中的论据
3. 自建测试环境，来提升理论的数据支撑

结果很明显，认可度普遍提升，直接效果在职位上，从开发人员变为产品负责人，但是我忽略了一个问题，我依旧走了广度学习的路线来获得认可。

职位上的提升，一定程度上让我忽略了技术上的深度问题。 直到一次公司的组织架构变动，原本的产品停止维护，我开始考虑个人问题，或者说就业市场给我抛出的问题：架构方向 or 业务方向

我选择了前者，同时也选择了换个环境

开发转传统架构，关键选择

前面两次选择，大约花费了 5 年，明确方向的我，便开始进入加速模式。

新公司给了资深开发+产品技术负责人的 title，新的环境也给了我很大的自由度和思考空间，开始研究框架源码和各种大数据技术，并且痴迷于性能和逻辑梳理。武器库的不停扩充，直接反馈就是职位的变化，单个产品负责人升级为产品线负责人。

内部认可度强化了自信心，促使不停得阅读，以扩充框架性的知识体系，然后再换取认可度，这是一个良性循环。

在此期间，尝试在自由市场走了一圈，也收到一些较好的 offer（现在来看已经搞不清是真的技术起到了作用，还是市场本就如此）

良好的循环，很快走到工作的第 8 年个年头，大量的框架性知识积累，已经不满足于老的技术团队体系，迫切希望一个新的架构和新的团队。
市场再次给了我两个选择：传统行业架构师或者互联网行业资深开发（前者重名后者重利，若以当时的角度看）

我选择了前者

广度优先瓶颈，职责矛盾体现

顺利的入职，顺利的团队构建，顺利的升职加薪，一切都都很顺利。重构一个新的体系远比想象中快速，团队成员组成的年轻化，在没有技术债的情况下，效率是上个团队的好几倍。

个人瓶颈出现在第 3 年，排除疫情影响，广度优先的策略开始出现副作用，主要体现在几个方面：

1. 传统行业的架构职责问题，体系建设、人员管理、项目咨询占用的时间比例很高
2. 维护体系和深挖技术之间的权衡需要花大量时间，为了降低风险，所以宁愿不变。
3. 各种新的框架出现，覆盖面积太大
4. 学习资料不再和以前一样难以获取，对深度的定义开始持续下沉。
5. 大量不同方向的架构理论，偶尔出现自相矛盾的情况

简单来说，就是出现闭环了，我的团队遇到了和我当初入行一样的问题。

再度选择，重拾底层

我开始重拾技术深度问题，花费大量的个人时间来回归底层，虽然公司可能用不到，但是起码对团队有些帮助。
自底向上再一次构建计算机原理、系统内核、容器原理、框架源码的知识体系，庆幸的是，这时候网上的教程以及可参考的书籍早已经不像以前那么难找。有时间都可以去研究，也可以组织内部一起进行深度讨论。

结果出现一个很有趣的现象，团队里的年龄组成不是一致的，也就是说团队里其实是处于不同阶段的人对不同阶段技术的不同需求，深度和广度之间的矛盾在不同阶段本身就需求不同，想用一种方式去解决不同年龄段人的技术焦虑，需要更大的平台。

于是，我们扩大了技术讨论范围，又组织了系统集成方法论、微服务架构模式、敏捷开发、devops等一系列更加上层的广度讨论。

期间，我也收到了一份新的架构师 offer，和之前不同的是这是二线厂的架构师 offer，但是当时痴迷于团队建设，并未放在心上（再次提醒各位朋友，凤尾和鸡头的问题，不要犹豫直奔凤尾，鸡头再大那也是鸡）

该状态持续到公司出问题前 2 个月，因为公司觉得占用了业务开发时间（虽然是周末或者晚上的加班时间）。

总结

转眼间，这是我入行的第 13 个年头，也是我架构设计工作的第 7个年头了。期间四次选择，两次深度，两次广度。

就个人经历而言，仔细回想整个过程：

• 深度的技术学习，就像是挖掘，你不知道会挖到什么东西，这需要由市场来最终决定
• 广度的技术学习，看似在学习，其实是在收割，不停扩大范围去收割。若上个阶段深度没有达到，收割就没有意义了。当然收割完后，发现不喜欢那就是另外一码事了。
• 面对未知的不确定，尽量不要放弃挖掘，不然下次市场迫使你需要收割的时候，将面临无牌可打的尴尬局面

还有，架构的事情真的不用纠结，过早介入架构工作，不一定是好事。因为，随着学习资料的更加完备，学习效率会提升，方法论会更加成熟，你以为积累了好几年技术学习时间差，足够冲击更高的岗位。可能过几年学习周期就会被压缩好几倍。冲击失败后回看市场环境，已经不是原本那个状态了。

最后，再多说一句废话，保持危机感真的很重要。