TOP

程序员的术与道

道：“道可道，非常道” 程序员的道亦如此，存在自己的心间，说不清道不明。

术：程序员的术则非常浅显，精通某项技术，熟悉其运用，了解其生态，即为术。

先看一份简历

XXX 智能交通项目：前端开发工程师

技术栈：Vue3 + TypeScript + ECharts + MapLibre GL + MQTT + … + Qiankun + Monorepo

职责与成果：

微前端架构设计，利用 Qiankun + Monorepo；
高性能地图引擎，基于 MapLibre GL 开发了 XXX 核心模块；
封装 ECharts 通用组件，通过 Vue3 API 实现响应式分析，减少重复代码 50%；
业务功能模块开发，开发 XXX 状态监控，减少业务成本 40%；
多协议视频接入，接入成功率 99%；
信号灯识别，集成 TensorFlow.js 和 YOLO 运行算法；
智能构建优化系统，分包按需加载；
业务功能开发，支持毫米差分析。

从经验上看，如果这是一个刚入行的开发工程师（例如1-3年）的简历，那我会毫不犹豫地邀请其参加面试。这份简历展现出的技术广度、对新技术的敏感度以及将技术应用于解决实际问题的能力，对于一个初级工程师而言已经完全够了。这份简历能清晰地勾勒出一个积极学习、动手能力强、能快速产出成果的新人形象。然而，如果这是一位拥有八年工作经验的前端工程师的简历，那么我就会在心里打上一个问号，甚至不会让其参加面试。

核心原因并非否定其技术能力，而在于“术”与“道”的层面差异，以及初级与高级工程师在思维模式、价值输出和解决复杂问题深度上的根本不同。

术与道，初级到高级的晋升

这种态度的转变直接出于以下几个关键维度的考量：

技术深度与原理挖掘的缺失——知其然，是否知其所以然？
- 初级视角：简历中罗列的技术点，更多体现的是集成运用的能力。这对于初级工程师是合格乃至优秀的，表明他们能快速学习和应用新技术。
- 高级视角：我期望看到他们不仅是用了什么，更能知道是为什么这么用、业务上如何做得更好以及背后的原理与挑战。
  - 微前端：在Qiankun+Monorepo的架构设计中，是否考虑了应用通信的复杂度与性能瓶颈？如何处理样式隔离与全局污染？Monorepo的依赖管理策略（如npm/yarn/pnpm workspace, 版本冲突解决）是怎样的？如何进行主子应用的协同开发与CI/CD？遇到过哪些微前端特有的坑（如沙箱逃逸、资源加载失败），又是如何解决的？这些才是架构设计的核心挑战。
  - 地图引擎：MapLibre GL的性能优化做了哪些具体工作？是图层合并、数据简化、瓦片优化，还是WebGL渲染管线层面的调优？“高性能”是如何量化的？面对大规模实时数据流（如交通路况），如何保证地图的流畅交互与低延迟渲染？
  - AI集成：集成TensorFlow.js和YOLO，是简单调用API，还是针对交通场景（如不同光照、角度、遮挡下的信号灯）进行了模型选型对比、量化压缩、推理性能优化？如何解决客户端算力限制与识别精度的平衡？有无考虑过边缘计算与云端协同的方案？
问题解决能力与复杂系统设计——是解决了点上的问题，还是面上的问题？
- 初级视角：简历上陈述的都是非常具体的、可量化的成果，体现了良好的工程化意识和业务贡献意识，值得肯定。
- 高级视角：在这个职级上的工程师需要展现出定义问题、拆解复杂系统、权衡取舍并驱动落地的能力。
  - 「减少重复代码50%」：是基于怎样的代码分析和抽象思维？通用组件的扩展性、灵活性、易用性如何保障？是否建立了组件设计规范与文档？如何推动团队复用并解决复用过程中的阻力？
  - 「减少业务成本40%」：这个成本的降低是如何归因到【XXX状态监控】模块的？该模块的设计如何精准命中什么成本痛点？在监控数据的采集、传输、存储、告警策略上有哪些考量？如何平衡监控的全面性与系统性能开销？
  - 「多协议视频接入成功率99%」：这背后必然涉及复杂的编解码、网络适配、容错重试机制。面对纷繁复杂的多协议，是如何进行抽象建模的？设计了怎样的插件化/适配器架构来应对未来可能出现的新协议？99%的成功率是在何种网络环境和设备条件下达成的？那1%的失败是如何分析和处理的？有无建立完善的日志追踪与诊断体系？
架构视野与前瞻性思考——是满足于完成任务，还是引领技术方向？
- 初级视角：简历中的工作内容更多是响应性的，即需要什么做什么，实现了什么功能。
- 高级视角：高级工程师应具备一定的技术前瞻性和架构规划能力。
  - 微前端架构设计：为何选择Qiankun而非其他方案（如Single-SPA, Module Federation）？Monorepo的引入是为了解决什么问题？它对团队的开发模式、协作效率带来了哪些深远影响？未来随着业务增长，该架构如何演进以应对更大的规模和更复杂的团队结构？
  - 智能构建优化系统：分包按需加载的策略是如何制定的？依据是什么（如路由、组件、用户行为）？如何评估优化效果？除了分包，还有哪些构建优化手段被考虑或实施？
  - 技术选型：每一项技术的引入，是否有做过技术调研、可行性分析、风险评估和收益预估？例如，选择MapLibre GL而非高德/百度地图API或Cesium，是基于开源可控、定制化需求还是成本考量？
术与道的层面差异——是工匠，还是工程师/架构师？
- 术的层面：指的是具体的技术技能、工具使用、API熟练度、代码实现能力。简历中大部分内容都属于“术”的范畴，这对于任何级别都需要，只是初级更侧重于此。
- 道的层面：指的是软件工程思想、设计原则（SOLID, DRY, KISS等）、架构模式、方法论、问题分析与解决的一般性思路、技术领导力、沟通协调能力以及对业务价值的深刻理解。

一句话总结

术与道，初级与高级：

初级工程师通过掌握“术”来高效完成具体任务。
高级工程师则运用“道”来指导“术”的选择与应用，能够设计出健壮、可扩展、可维护的系统，能够带领团队攻克难关，能够从业务战略高度思考技术投入的成本与产出。

那么你现在是在哪个阶段呢？如何评价你的术与道？