软件工程师的进阶：从高级软件工程师到领域技术专家

“屋顶的闪闪星光”这个IP专注软件技术人员的就业指导、职业发展，欢迎大家私信交流具体问题。

我经常讲，软件工程师个人水平基本可以划分为四个段位：入行、初级工程师、高级工程师、领域技术专家。这四个阶段中，个人主观能动性的影响因素特别大，机遇的影响相对会少一些。

至于领域技术专家之后的职业发展，个人主观能动性所起的作用有限，而机遇的影响相对就会更大了。比如，在达到领域技术专家的水平之后，有的人碰到了好的机遇，自己创业或者带团队，走向管理路线，到更大的平台；也有可能没有好的机遇，在公司一干就是多年，成为一个民间口碑很好但做着平凡事的平凡人。

入行到初级工程师这道门槛很低：经验学校计算机类专业的科班毕业，或者转行过来上几个月培训班，找份正经工作，开始开发商业项目拿工资，这就算入行了。

初级工程师到高级工程师的这道门槛也不高：入职两三年的时间里，疯狂吸收新知识，参与项目，尽量多的Coding、解决问题，提升自己解决问题的能力、Coding的质量。直到某一天，我们对软件工程开发中的任何模块级的任务都能搞定，即使有问题，也能清楚地知道如何解决的时候，同时，对于代码质量、设计模式、常用的中间件等基础设施驾轻就熟，对于一般的设计理论也都能了解于胸，那就跳入高级工程师的段位了。

如果说前面两个门槛是完全可以凭借个人的努力奋斗来度过，那么要迈过高级工程师到领域技术专家这道门槛，机遇就开始起作用了。

我们先看看，领域技术专家是什么样子的，接下来再分析一下如何从高级工程师进步到领域技术专家。

我个人的理解，领域技术专家需要具备这几方面的素质：遇到足够复杂的问题、业务理解和预判能力、全局的架构设计能力、资源排布能力、一专多能、高效专业的沟通。

接下来，依次讲一讲：

第一、遇到足够复杂的问题

让一个初级开发工程师每天只做CRUD的话，干上十年也成长不到高级开发工程师。同样，一个高级开发工程师如果没有经历过足够复杂的业务系统，也没有可能成长为领域技术专家。

说到底，软件工程师一门实践科技，无法数学那样推导出先进的生产力，而是要在解决复杂问题的同时让自己得到升华。

这也是平台的重要性，大公司培养出领域技术专家的数量、质量要远高于小公司。无他，业务复杂度不同。

第二业务理解和预判能力

一个软件产品，人设想到落地，一个正常的流程是：商业设计——产品设计——系统架构设计——功能模块实现——功能迭代演进。

一个领域技术专家的工作是从系统架构设计开始的，但在这之前，他必须和负责商业设计的业务负责人、产品设计的产品负责人进行了充分的沟通，完全理解，并能对未来商业逻辑、产品功能的演进做出预判，才能够把系统架构设计的兼具当前阶段的实用性，以及可以支撑未来的业务发展、产品演进而需要具备的扩展性。

第三、全局的架构设计能力

举个简单的例子，我们要做一个电商系统。

为了快速验证模式，1.0版本只有微信登录、商品列表、下单、支付等几个核心环节。但架构师必须预判到，一旦业务模式验证成功，产品能力会迅速扩展，那么1.0版本时虽然只做了上面几个核心的功能，但却要为后续产品功能扩展留足空间。

比如，负责整个系统设计的领域技术专家要把用户域、商品域、交易域、支付域完整构建出来，可以留个空架构，但必须把设计摆在那里，这样才不会出现后面功能迭代要进行框架重构的尴尬。

要做到这个，领域技术专家必须要对电商的平台/自营模式、产品功能等都有深度的理解，清楚地知道，如果业务发展顺利，未来一年、两年之后，系统会是什么样子的。

我们通常所说的“系统架构的前瞻性设计”，绝不是YY，而是基于理解之上的理性判断，这不是意愿，因为人人都想这样，而是一种能力，软件工程师能成长到这一步的，不多。

第四、资源排布能力

系统的各域划分好之后，商品、店铺、交易、支付、履约、逆向等各域分别需要放多少人、几个高级开发工程师、几个初级开发工程师，如何配比才能保证充分挖掘资源的潜力，领域技术专家要清清楚楚。

比如，按照公司的现有的人员水平，一个高级开发工程师如果只能带两个初级开发工程师的话；带少了，高级开发工程师占比过大，项目成本上升；带多了，高级开发工程师天天指导别人，没有时间做核心模块了，项目的进度和质量都会受影响，风险提高。

再比如，资源有限的情况下，各域建设时的优先级可以分先后，依照各域之间的关系，如何安排保证整体效率最高？

第五、一专多能

上面说了那几条，大家心里可能在想，这个领域专家要把一个系统的各个领域都精通，这不得干上十几、二十年才行啊？No！

所有达到了高级软件开发工程师水平的人，应该都会有这样的印象：我们在做第一个需求时，因为不熟悉套路，问题频发，速度很慢，比如，有问题的逻辑没看出来，需要技术调研的没有评估出风险等等，可一旦第一个搞完，再搞第二个时，速度就会地快很多，再搞第三个时更溜。

对于领域技术专家的成长史来说也是类似的逻辑：只要在一个域内做到精通，对于上下游的其它域，无需深度参与开发，可以通过业务逻辑、产品能力的交流快速理解各域的职业、解决的核心问题。

所以，要当好一个领域技术专家，要“一专多能”：“一专”是指对一个域具备特别深厚的理解；多能，是指对上下游各域也兼而能之。

第六、高效专业的沟通

几年前我带过的团队中有两个小兄弟，他们的性格特别有意思。小A平时幽默诙谐、能说会逗，讲起技术问题来也像聊天，思路天马行空、用词飘忽不定。小B平时沉静内敛，除了工作，一天也不见几句话，但讲技术问题来，用词专业、逻辑清晰、重点分明。

这样极端性格的两个碰在一个团队，关系还处得很好，也是很难遇到了。这里重点想讲的是，我们工作中最需要的是小B这样的沟通能力。

工作之余，当然大家都欢迎小A这样的人，我们更希望所有人都能像他这样给团队带来欢乐。但我们同样也希望所有人都能在工作中有小B这样的沟通能力，因为这才是专业而高效的沟通方式。

以上，讲了领域技术专家需要具备的素质 。接下来讲一讲，要从高级工程师成长到领域技术专家，需要怎样学习。

我一直认为，软件工程是一门实践科技，而作为领域技术专家最核心工作的“系统架构设计”，更是无法像数学那样，用精准的语言、理论来推衍、解构、量化，只能描绘出一些抽象的、特征化的描述，甚至，除了一些常识之外，都无法区分好坏，只能等到出现问题的时候，才能看出来。

所以，要想具备到这样的能力，大部分只能从实践中来，再配合上一些理论牵引。

那么，一个对模块开发十分熟练的高级开发工程师要成长为领域技术专家，我认为最重要的有这么几条：

第一、基本功扎实。

以极大的技术热情，把模块化的开发工作做好，并不断反思、改进；对于Coding技巧，语言特性等充分掌握，设计模式等，烂熟于胸；对于缓存、消息、RPC之类的常用单点技术如何使用清楚分明，并对其中一、两个做过源码级的深入研究；对于工程结构划分、服务治理等驾轻就熟，对于“给奔跑中的汽车换轮子”这种高危工作也有章法、有套路。

第二、了解上游的业务、产品。

和客户、业务人员、产品经理频繁沟通、交流，知道自己在开发的功能会给谁用，用于什么样的场景，横向对比优缺点如何，有什么问题，并能快速反馈优化。

这个过程，对于锻炼研发人员的“业务、产品理解能力”非常重要。

第三、扩宽视野。

每个高级开发工程师所做的模块，都是更大的系统中的一环，除了把自己的模块做好之外，还要关注整个系统中，自己的上下游各模块、上下游各域的职责、核心能力，自己与他们之间的关系。

每个人的精力有限，一个电商系统的高级工程师不可能有机会、有精力把商品、店铺、营销、交易等各域都开发上几年。所以，这里最重要的是用深耕自己的域时所获得的方法论去快速理解整个系统的上下游。

第四、理论学习

软件工程以实践为主，但在实践的同时辅以理论学习，会让成长过程更迅速，少走弯路。

比如，大家都知道复杂系统要划分出合理的域来，如何让各域之间高内聚、低耦合，也有现成的工具、方法可以使用。那我们直接学习、应用到这些工具方法就可以了，没必要自己从头摸索，过了半年之后才恍然大悟：原来应该这样。

以上，讲了领域技术专家应该具备的素质，以及高级开发工程师如何才能成长到领域技术专家。个人从业十几年的一些浅薄的看法，希望能给到大家帮助。