技术人员重复造轮子现象分析报告
本文围绕“为什么技术人员（不限于程序员）倾向于重复造轮子”这一现象展开了调研。内容涵盖互联网技术领域中该行为的动因、心理与组织背景、行业结构性机制、以及跨行业中的类似现象，并尝试查找是否有相关的理论研究或实证数据来支持分析。
# 技术人员重复造轮子现象分析报告
## 现象概述
在互联网技术领域，经常可见不同团队、开发者各自实现相似功能或工具的情况。例如，多个项目团队往往独立开发日志系统、监控平台、ORM框架等基础组件，而非共享通用库。。一项针对 GitHub 项目的实证研究发现，工程师对字符串处理、集合操作、日志记录等通用功能库的**重用**和**重写**都很常见：前者提交数是后者的2.5倍，后者往往因为库依赖过重或功能过剩而被替换成自实现方案。从企业层面看，大公司常出现“部门与部门之间隔阂太多，同样的技术多个团队在做”的情形。总之，开发者/架构师和平台工程师在工作中**重复造轮子**表现为：各部门/团队各自研发近乎相同的基础平台、组件或工具，导致资源浪费和系统重复建设。
## 心理动因
* **好奇心与学习动机：** 许多工程师喜欢从零开始构建系统，以深入了解技术原理、锻炼分析能力。一位工程师指出：“重新造轮子可以让你**独立思考**、获得实用的掌握技能”；另一位也认为，重新造轮子是**学习和成长**的过程：“我是个好奇的人……通过造轮子去学习和探索，总有收获”。这种求知与自我完善的驱动力，促使技术人员愿意亲手实现已存在的功能来积累经验。
* **成就感与自我价值：** 完全从零开发一个工具或框架，能带来明显的**成就感**和认同感。工程师往往为自己“亲手打造”的代码感到自豪，认为这能提升个人影响力和职业竞争力。同时，一些工程师在项目之外参与开源或副项目，往往更愿意“自己干一套”，这满足了他们对创新和贡献的心理需求。
* **自主控制与定制需求：** 自行实现可获得更高的**可控性和灵活性**。当现有库或工具无法精细满足需求时，工程师宁愿自己编写代码。正如有观点指出的，市面上的开源库为了通用性往往非常臃肿、灵活性不足，如游戏项目中可能只需要简单的增删改查功能，却不得不使用复杂的 ORM 框架。在此情境下，开发者更倾向于编写精简定制的实现以掌控细节。此外，对第三方库的**不信任**（担心质量、维护或授权问题）也会驱动工程师自主构建解决方案。例如，当意识到使用库只是其中一小部分功能、依赖链过于复杂或项目被弃用时，开发者会转而用自写代码替换该库。
* **心理偏见与**“**自生源头**”倾向：\*\* “Not Invented Here”症候群是常见心理现象。人们可能因为对外来技术不熟悉、不认可或简单的“主场文化”，而倾向于自己重新实现已有方案。研究表明，这种偏见源于对外界成果的低估或抵触，甚至夹杂妒忌和部落主义思维。在高压竞争环境下，有些人只关注“自家贡献”而轻视外部资源，认为唯有自己开发的技术才可称得上“核心能力”。
## 组织动因
* **KPI与绩效考核驱动：** 在许多大厂，**技术产出**被直接纳入绩效评价。公司往往奖励可量化的“技术贡献”，如搭建了哪些通用组件或平台。腾讯内部就曾提出：稳定业务期如果只是做常规功能，要晋升和加薪比较难，只有“打造通用能力的轮子”才能获得上升通道，被工程师戏称为“以能定级、以轮定能”。于是即使已有可用方案，个别团队为了绩效或职级考核的需要，也会自发开发新工具以获得“创新”业绩。
* **部门壁垒与协作不足：** 组织层面的沟通障碍导致重复劳动。大型互联网公司往往划分为多个事业部或团队，各自独立研发、自行决定技术方案。当信息不互通时，即使不同组在解决相似问题，也倾向于各自搭建解决方案。腾讯就曾反思“公司内部技术壁垒太多、部门之间隔阂太大，同样技术多个团队在做”，因此才推动内部开源协作以打破壁垒。若组织未能提供统一平台或技术共享机制，各团队即使能力相当，也会因内部竞争或担心被比下去，而**重复造轮子**。
* **资源分配与内部竞争：** 在单线评价体系下，下属更在意上级考核指标，不愿落后于他人。文章指出，如果自己不“造轮子”，别人会做，而自己最终承担低绩效的风险，于是“不同部门间重复‘造轮子’，同部门不同团队重复‘造轮子’”成为常态。出于“演员式”的绩效博弈，轮子往往成为展示能力的道具。此外，项目周期紧凑或任务分散时，缺乏纵深规划（“黑暗森林法则”）也使团队倾向于当前需求对应地临时构建组件，而非等待成熟方案和谐演进。
## 行业文化与生态因素
* **工程师文化与创新精神：** 软件/技术圈崇尚**自主创新**和“亲自造轮”的精神。许多技术社区认为，自己动手改造或重写系统能够体现创新力，一定程度上推崇“不满足于现成答案”的探索态度。这种文化鼓励开发者主动提出新方案，但也容易滋生重复建设。
* **开源生态影响：** 开源文化一方面提倡代码共享和复用，但另一方面也强调**社区贡献**。企业内部推行“开源协同”时，既要避免重复造轮子，也要满足各团队差异化定制需求。例如，腾讯明确提出：“开源的目的是减少重复造轮子，协同的目标是去中心化”。不过，当公司将开源贡献列为**KPI**时，也曾引发争议。不少开发者批评“KPI 开源”违背了开源精神，容易为了指标而盲目建设无用项目。这些机制反映了行业文化在实际执行中的两面性：既鼓励分享复用，又有可能通过制度驱动来推动新造轮子。
* **招聘与评价导向：** 在招聘和人才评估时，对具有独立造轮能力的工程师往往加分。简历中的**个人项目经验**或“从0到1”开发案例，体现了候选人的技术实力和创新潜力。在这种导向下，工程师容易形成“造轮子能证明价值”的观念，从而在工作中倾向于自行构建功能。此外，部分公司和团队也强调对“核心技术”的掌控，担心过度依赖第三方会缺失自身竞争力，这种思维也助长了重复造轮子的行为。
## 跨行业对比
“重造轮子”的现象并非软件行业独有，在其他技术领域也可见类似情形。维基百科指出，“重造轮子”一词常出现在软件开发或其他工程领域中，其本意是指重复创建已有且优化完善的方法或组件。在科研领域，专家也提醒学者要警惕“忽视现有理论而盲目造轮子”的极端做法，建议在研究过程中与已有文献对话。在工业设计、机械设计等领域，成熟的标准部件和成熟技术被反复使用以避免资源浪费，但有时为了适应特殊要求，工程师会修改或改造标准设计；若缺乏共享与沟通，也可能不同团队独立做出相似改动。总体而言，跨行业研究表明，当问题普遍存在时，相似的“重新发明”动机会出现，例如对已有成果信息不对称或对标准方案不信任，就可能导致在多领域重复开发。
## 理论解释
* **Not Invented Here (NIH) 症候群：** 该理论用来解释组织或个人抗拒外部解决方案、偏好内部开发的倾向。NIH 症候群指出，人们可能因对外来技术了解不足、对授权费用的忌惮、对外部成果价值的不认同，甚至部门利益之争，而回避现有方案。这一现象正好对应了重复造轮子时不愿采纳现成工具的心理偏差。
* **路径依赖 (Path Dependence)：** 这一经济社会学概念强调“历史路径”对当前决策的约束作用。在技术研发中，团队往往沿用既有架构和技术栈，新增功能时更倾向于在当前路径上做演进，而不是完全切换至外部方案。当组织已在自有方案上投入大量资源时，即使出现更优选择，路径依赖也会降低转向外部的可能性。因此，过去的决策会固化团队倾向于扩展原有“轮子”，而非采用全新轮子。
* **创新扩散理论：** 罗杰斯(‘Everett Rogers’)的理论指出，不同个体对创新的接受程度不一，一部分人偏好尝试新方案（创新者），另一部分人则倾向谨慎跟随。这意味着在同一行业内，部分开发者可能会尝试从头实现新工具，而其他开发者则愿意复用现成方案。这种群体差异导致了并行出现“重复造轮子”的现象。
* **技术债务与演化观：** 在敏捷迭代或快速发展阶段，架构设计难免产生局限性，后续往往需要**重构**。有时团队为求快速完成任务，会累积技术债务，即便事后意识到问题，也只能在原有架构基础上打补丁或演进，这在形式上类似于自己再造轮子以弥补最初设计的不足。文献提醒，技术债务也具有债务红利的双重性，即短期内加速交付，但长期必须偿还。这种视角从动态层面解释了为什么团队有时选择在旧方案上反复修补，而不是采纳全新的外部方案。
## 实证研究与数据
目前针对工程师重复造轮子的**学术实证研究**较少，但已有研究提供了部分数据支持。例如，新加坡管理大学对 GitHub 项目进行静态和动态分析后发现：重用（reuse）比重新实现更普遍，重用的提交数是重写的2.5倍；重写多发生在只用到库很小一部分功能或库依赖复杂时。更重要的是，该研究还发现**重用可以显著提高代码质量并减少缺陷**，而自行实现则往往降低质量。尽管这项研究专注于开源软件库，但其结论暗示：在互联网开发者群体中，对基础功能重写（重复造轮子）虽然降低效率，却确实存在，并且主要原因包括**对外部库认知不足**、**依赖复杂性**以及对现有方案的不适应。目前还缺乏大规模问卷或行业调研数据专门统计跨行业的造轮子频率，但可见上述经验与动因分析具有一定代表性，为理解该现象提供了实证依据。
**参考文献：** 本报告援引了技术社区和研究文献中的观点和数据等，以确保论述的可靠性和权威性。