这不是我写的代码

This is not my code

软件如同人一样不完美，总会出问题

一个软件系统难免会存在bug（问题）。然而出现bug之后，不同类型的程序员会有不同的反应。如果你在技术圈混得足够久或常与技术人员打交道，你迟到会听到这句话：“这不是我写的代码”。

细想这句话，至少包含两层含义：一是这个bug不是我的，因为代码不是我写的；二是拒绝对bug做修复，也是因为那段代码不是我写的。再细想这两层含义，前者想撇清问题的责任，而后者不想承担解决的责任。

同其他许多行业一样，在IT/互联网的技术领域，分工也是十分细化，但没有泾渭分明的专业化。尤其在软件与系统的设计和开发行业，许多技术的原理是相同相连的，不存在很高的学习壁垒，只要你能够专心全心投入。如今大量全栈技术人才的涌现，验证了这点。所以从技术层面来看，不存在技术人员无法解决的bug。

出bug地方的代码如果是与这人使用同样的语言和工具，那么这句话明显是对解决bug的推辞。如果代码与这人所擅长的语言与工具不一致，由于各类语言和工具是想通的，那么至少可以去分析一下问题的原因以及可能的修复方案。所以，不论从哪者来看，这么回答的人抱着这样一种思维逻辑：“不是我写的代码，不是我的bug，我没有义务去修改。”或者甚至会有种“事不关自己，高高挂起”的心态。

一个公司、一个组织、一个团队需要分工和协作。对于分工，自从科学管理之父泰勒提出生产分工管理的理论以来，一直被企业、公司和团队广泛使用。所以在实际的工作中，大家都能理解得很清楚和明白分工与专业化的作用，也都能知道自己的职责范围。但对于协作，虽然公司和团队的文化不断强调，很多人仍然停留在纸上和嘴上，没有落实在实际的工作中去。分工的本质在于利用个人技能的专业化提高生产效率，而协作的本质在于合众人之力把事情做完做好。分工关注点在个人的绩效与产出，而协作聚焦在整体的效能。在市场中，一个公司和团队是作为一个整体参与厮杀和竞争，而非单靠其中的一两个人。所以在强调分工的基础之上，协作能够决定一个公司和团队的成败。

一个系统是一个公司或团队的智力劳动成果，如果出现问题，需要第一时间把问题解决，尤其是对于商用产品来说。如果出现问题与责任的推诿，没有任何意义，只能降低客户对系统的满意度和良好的体验。因为外界只能看到系统的bug是否解决，是否已经稳定，而不关注这个问题是由谁以及怎么解决。所以一个问题经由客户反应到商务或运营部门，再反映到技术部门，这中间已经存在一定的时间推延。如果技术人员再次对问题进行责任的划分讨论和推诿，那么这个问题被处理和解决的时间将又会加长。软件系统，尤其是互联网产品的问题，需要能够被快速解决，否则这个问题可能会被无限放大，会给公司带来严重的客户流失和直接的经济损失。一旦造成损失，亡羊补牢，已是晚矣。

从另一个角度来说，这也关乎技术人员自身的职场成长。一个不能主动积极承担责任，勇于尝试解决问题的人，在技术职业生涯和职场上终将走不远。我想没有哪个公司喜欢聘用一个遇到问题喜欢撇清责任和互相推诿的员工。再则，现在个人的名片与影响力在网络上十分透明，几乎可以被任何公司搜索和查看到。所以作为想在职业上取得成就的技术人员，在做好技术的精进的同时，也需要做好团队的协作，打造自己良好的职场声誉。

所以在下次系统出现问题时，作为技术人员的你，如果是你负责的功能模块，那么应该义不容辞地进行立马修复。如果不是，千万不要甩出一句“**这不是我写的代码**”，然后就没有然后了。一定要主动去查找和分析问题，尝试去解决，或者将问题反馈给你所知道的那个人，让他帮忙解决。