**这是一个管理上的问题*。

在部署关键代码之前，应该对其进行版本控制、代码审核，至少要有使用记录。如果考虑到安全问题，选好审稿人，保护好repo和doc。没有理由不立即开始做这件事。

**还有一个比工作安全更严重的问题*。

任何一个开发人员都有可能把恶意代码放进公司，可能是错误的，也可能是他们自己的原因。在最坏的情况下，他们可能会利用自己创造的情况积极地进行恶意行为（勒索、破坏、工业间谍等）。在最好的情况下，他们的不透明性会让所有人都暴露在安全问题上，而且总是给任何审计或问责打上一个问号。如果出了问题，谁又能说他们没有参与其中呢？

你需要为管理层编写一份报告。

写一份简短的文件，概述为什么目前的方法会把公司引向危险的道路（例如被公交车撞到的情况）。

最后但并非最不重要的是，一定要列出要立即实施的建议，比如将代码添加到版本控制中，让所有人都能看到，并将服务器运行在每个人都能访问的虚拟机上。概述这些措施应该不会对这个人的工作造成任何影响，只是会增加整个过程的安全性和透明度–**_明确表示对这些措施没有合理的反对意见。如果你的老板们觉得这个人可能会变得不讲道理，那么你不妨听从@BillLeeper的建议，夺取他的机器控制权，让他无法伤害你的组织。当然，这将由他们自己决定。

可惜的是，你还真没说过是否有人跟同事或管理层说过这些顾虑。是真的有恶意吗？还是你的同事就是瞎了眼了？或者是管理层瞎了眼？

我自己也曾 “那个 "过。

在我之前的工作中，有时为了 "做这个小工具 "或者做一些简单的东西，会有各种副业。事实证明，从来没有资源做内部软件…… 通常情况下是这样的：

—-有人能不能看一下我选的方案，看看我选的方案是否合适？– 来吧，我们只需要一个简单的工具，只需要做这个简单的操作，做了就可以了。

– 我可以在我们的服务器上创建一个虚拟服务器来做这个东西吗？– 伙计，这只是内部使用。只要把它和其他的东西放在一起，放在那个破旧的物理盒子上就可以了。或者把它放在那个能做什么功能的盒子上 Or put it on that box which does we -dunno -what functions. 或者把它放在自己的工作站上。

当然，从来没有时间资源去写文档。除非我选择在空闲的时候去做。当然，当一些工具出现问题的时候，我所能说的都是 "工作上的事"，

然后我决定退出。那是我身边的人第一次意识到，"内部小 "工具其实很重要，"简单 "的东西没那么简单。我花了几个周末的时间，写了几个周末的doc，让同事们少操心。差不多一年过去了，我还是每个月都会接到多个关于内部工具怎么做的电话，

编辑

编辑

有评论指出，我不应该无偿帮助他们。这个说法基本是正确的。我想澄清一下，我并不是把几个小时的时间放在解决他们的问题上，我只是花一分钟的时间来回答一个问题。严格说来，我是在帮助和鼓励现有的做法。

问题是，我不愿意强迫我的前同事们 "更好地研究"，而不是简单地问我 "Veeam在哪台机器上运行？"，如果我可以不假思索地告诉他们名称或IP地址，或者说 "应该写在[…]"，我就不愿意强迫我的前同事们 "更好地研究"。除了和前同事打2分钟的电话，通常是和访问stackexchange一样积极而轻松的分心。

编辑结束

那么我有什么建议呢？你的同事似乎很有能力，不是吗？和管理层讨论一下。不要告诉 "他正在变得不可替代"。只要问他们–如果他离开了怎么办？如果他长期生病了怎么办？让他们相信，问题是真的存在的。他们应该和那个人自己讨论一下，寻找解决方案。也许他只是缺乏资源？也许他需要另一个人在 "内部软件 "团队中，把这一切搞得漂亮漂亮的？

这些答案大多都是在假设的基础上远远超过了涉事开发者的恶意。

在对服务器进行偷偷摸摸的造像，然后把这个人从办公室里赶出来之前，为什么不先喘口气，试着去了解一下到底是怎么回事？

很可能是涉事者工作过度，没有足够的资源，而且更愿意分享知识。也可能是他已经这样做了很长时间了，从来没有收到过他需要做其他事情的提示。最起码，特别是如果他的东西是可行的，他应该有机会解决顾虑，并与同事合作。

我没有看到任何证据表明OP的问题中的任何这一点。在考虑严厉的选择之前，先尝试沟通。如果这个人没有伤害的意图，你可以期待他的合作。

有一些我还没有在其他答案中看到的东西：

随便开始找一份新工作

当然，这是在假设你已经和你的经理谈过这个问题的基础上。其他的答案已经提供了为什么这不是你的问题，而是你的经理的问题的原因，他们也给出了如何与你的经理进行这种对话的指针。

现在，我看到的情况是，你已经和你的经理谈了这个问题，然后在合理的时间过后，这件事没有发生任何事情。

这时你就会感觉到，你的经理并没有像你知道的那样认为这是一个很大的问题。不管你的经理只是不认为这是个问题，还是他根本就不太了解这个问题，看不出问题的所在。(而且我说的不是 “私下 "的代码，而是经理不作为的问题。)

这样的问题，是你从开发人员的岗位上不可能改变的。不过，还有其他公司，他们也没有这样的问题，所以你可能会想换个雇主。

从积极的方面来看，不过，现在你的压力并不大。你确实有一份工作，而且你并不期待失去这份工作。为了能够继续支付房租/房贷/生活费，你不需要妥协。你可以随随便便地开始四处寻找，在找到那份自己真正喜欢的工作之前，不要放弃现在的工作。

看来这里有一些很好的补救措施，可以防止以后出现这种情况，但不知道现在该怎么处理，

1. 对电脑进行安全防护。要么让管理层和IT专家在无人值守的情况下，让管理层和IT专家过去，或者去要求他解锁机器并授予访问权限。然后把这个怪物从网络上弄下来。马上给HD做一个图像，以防他有一个死人开关。

2. 立即开除这个人。把他送出大门。不用担心原因，他的电脑上会有很多证据。如果公司不放心，让他们的律师出手，那是他们的专长。把团队召集起来。解释一下事情的经过。这个人的行为很鲁莽，很不专业。他将公司置于危险之中，因此被解雇了。这将需要我们所有的资源来解决这个烂摊子。

3. 利用团队的力量，在安全的机器等方面，把这项工作重新建设和部署得妥妥当当。团队要一个个的APP，把事情处理好。不要马上担心重写，只要确保没有后门等等，然后在新鲜的、可控的硬件上把服务搞起来。

5.找一个安全专家进来。这个家伙很可能不会悄悄地走，会试图 “黑客 "回来破坏或以其他方式进入他的系统。他也可能有与他互动的系统的全局密码，或者随着时间的推移获得个人密码。IT部门应该对所有用户进行强制密码重置，并在一段时间内阻止任何外部访问（如VPN）。

目前所有的回答和大部分的评论都只是陈述了目前的情况，或者提出了采取极端措施的建议。

只想总结一下。有两种可能的情况。一、同事是故意这样做的，这种情况下，他们有这样或那样的恶意，那么就需要采取极端谨慎的措施。或者是同事只是没有看到潜在的和实际的问题和危险，他们所造成的，那么他们是 “友好 "的，但应该被劝说做得更好。

所以，下面的路线图同时尝试两件事：1）如果是恶意的，尽量减少这些同事可能造成的潜在伤害；2）如果是友好的，尽量让他们留在公司里（这样他们将来可以发展成合作的同事）。

(btw: 我知道，你不是老板，但有了这些信息，别人提供的信息，我想你会有一切都在你的手中，说服你的老板，把这个线程很认真，所以这个路线图解决的是你的老板可以做什么，而不是你会做什么。你唯一能做的就是引起老板的注意，btw2：如果你老板还是不听，那就找一份新工作，找到新工作后马上辞职。因为那个同事都是定时炸弹，不管他们是友好的还是恶意的–这根本不重要)。

1.) 默默地对所有可以访问的东西进行备份。在这个过程中不要关闭系统，关闭系统可能会触发一些诱饵陷阱。

2.) 构建一个理由，即工作站需要关闭。如果你有需要，可以私下联系我

3.) 提取硬盘，做一个完整的图像，放回去。这样做一个周末左右，

4.) 如果系统有BIOS级别的入侵检测东西，而你无法规避这些，那就构建另一个原因，为什么那些入侵检测系统会被烧毁。

那些同事们是在为内部的东西创建工具，对吧？所以他们不需要访问客户系统之类的东西？

5.) 如果他们有访问系统的权限，他们不需要，修改密码，确定，有没有那种公钥登录，检查端口是否允许非标准登录的进程。检查cron/at作业，检查inetd，检查当前运行的一切。对于每一个pid，你必须能够回答，为什么这个进程会运行。

6.) 找一些新员工（真的是新的，完全不知道。他必须是一个真正的好专家，因为他必须能够，如果有必要的话，可以单独接手他们的工作一个月。你不能随便找一些毕业的学生（甚至不是成绩最好的学生），你需要一些从来没有去过大学但还是什么都懂的人），把他插入到那个团队中去支持他们。尤其是既然他们对其他工友造成阻拦，那就更容易说得过去了。他的正式工作是支持他们，他的真正工作是学习，他们是如何操作的。

第六步特别重要，因为这样一来，你就有机会，真正弄清楚，那些同事是否有恶意。

如果新来的人被很好地融入到团队中，那么你可以假设他们是友好的，新来的人应该能够实施必要的改变，而不需要告诉那些人，有任何怀疑他们的嫌疑。学会一切，发现他们在做什么，觉得很酷等等。给他双倍的钱，因为他要付出双倍的努力，因为他一回家，就得把学到的东西都写下来，然后发给一些新组建的团队，只要有足够的知识转移，他们就应该马上接手这个工作。

如果恶意的家伙不整合他，那么你唯一的机会就是希望，你有足够的数据备份（只是为了以防万一），然后炒掉那个团队。然后你可能需要两个或更多的超级专家，我在上面说的超级专家，让一个新的团队非常快速的融入到代码中去。

我希望，这个路线图对你有帮助–至少是对如何处理这个问题的灵感来源。也许，在你的公司里，你有一些方案，是我无法考虑的，也许，有一些文化上的差异，所以你还是要考虑一下，也许调整一下计划。

在这种情况得到解决之前，不得给该程序员任何新的工作。所有新的需求都必须交给另一个开发者/团队，他们必须遵循适当的源控制和同行评审程序（如果需要的话，新的雇佣者）。有关的程序员可以继续忙于修复缺陷或 “救火 "他现有的遗留问题。必须分配资源对现有的遗留问题进行逆向工程，并通过适当的流程重新实施。这样做的成本必须由现有的风险来论证–如果这个程序员所做的一切都突然失去了，企业会付出什么代价？或者更糟糕的是，什么专有的（公司）数据容易被竞争对手丢失？

也许值得问这个员工。"如果你被公交车撞了，或者决定环游世界一个月，我们会怎么样？"并衡量一下他的反应，以决定他是否会心甘情愿地交出代码。如果是合作的话，就没有必要把情况变成对抗性的；如果他方面没有任何关心公司的迹象，那就该忙着把他所接触到的一切都保住了。

如何与管理层沟通这件事，

说，最好的做法是不允许这样做，原因很多。

专业的程序员应该知道，这不是经营企业的方式；如果管理者不知道其他的事情，他们至少应该知道（程序员应该告诉管理者和/或管理者应该告诉程序员）。它们包括 “备份"，即如果你失去了程序员（或者如果他们被重新分配到其他地方），或者如果程序员失去了他们的机器，你就有麻烦了。

至少你有_个 "公司版本控制"，所以你不需要打这场仗；只要把它作为工作/流程要求，让它实际使用就可以了。第一步可能是坚持：

• 用户不能与开发者的机器进行网络连接
• 软件在生产服务器上运行
• 在生产服务器上运行的软件必须由其他人（或由构建机器）构建，从源码控制

实施时需要检查源代码，发布构建说明。我建议你把它作为半紧急事件来做。允许开发者不允许写访问生产服务器或构建机（以验证生产代码是否可以从版本控制中构建）。

做完这些之后（在你知道源代码在版本控制中，构建指令发布之后），然后其他开发者可以考虑检查源代码并帮助维护。

请注意，Get Rid Of Indispensable Programmer As Quickly As Possible是Gerald Weinberg在1971年**发表的（所以，真的，现在大家应该都知道了）。IRC的原话是，

"如果一个程序员是不可缺少的，那就尽快把他赶走。”

这不是你的问题，这是管理者的责任和作用，你只是一个同事，可能没有掌握所有必要的信息。我更多的是担心自己的任务，而不是想和同事们扯上关系。我看不出你对你的同事大吵大闹会有什么积极的结果，

你会和他为敌，你会向经理展示你的无能，给人的印象是你的工作这么少，没有人要求你，也没有权力发起内部调查，你有时间发起内部调查。

现在的问题是，你有多想摆脱这种恶性循环？因为我们不要可爱了，这样做会让公司付出代价，

1. 事务所要花钱雇人写出事务所控制的代码
2. 公司必须向编码员索要代码，并在必要时提供法律帮助。我要指出的是，代码是公司委托的，编码员在写代码的时候从公司拿了工资，所以代码是公司的。如果编码员没有制作出代码，最坏的情况下会被认为是偷窃，这将是一种刑事犯罪。

自由不是自由。如果公司不愿意耗费资源去做这个人的自由，那么你们所做的一切都是在拍马屁。你们都要正视这种情况，因为如果这名编码员搬走了，或者被卡车碾压，事务所就SOL了。

考虑一下他们这样做的原因。完全有可能是为了配合时间限制、绩效目标和持续增加的要求而偷工减料。这往往会导致技术债务和一个压力很大的程序员，他们没有选择的余地，只能把每一个问题都解决掉。

这个人很可能是以只有他们自己能解决的方式来写东西，因为他们没有时间去记录、版本和维护代码，所以他们没有时间去及时地记录、维护代码。相信我，当我说这对任何一个发现自己处于这个位置的人来说都会产生彻底的负面影响。

如果像你的标题所说的那样，他们不是在解决问题，那就没有问题了。你就会直接扔掉这个代码，把他们所有的代码都扔掉，因为没有用。

防止出现这样的情况，是一项极其基础的管理任务。由此可见，意识到问题的管理者是没有能力的，有能力的管理者是没有意识到问题的。

可惜的是，像这样的情况的解体，是一项非常困难的管理任务。所以，既然这个开发商的管理者连预防这种情况的能力都没有，那就不要指望他们有能力解决这种情况，

*唯一的办法就是上报上级管理部门。 ** 如果他们有兴趣并且有能力解决这个问题，你甚至不需要解释什么比你向我们解释的更多的东西–只需要把重点放在程序上，以及程序的问题上，而不是程序员，让它变得不那么个人化。如果你这样做了，即使成功了，开发人员和他的经理（他很可能也是你的经理）也会吃亏，知道你要负责任。你这样做的唯一好处是，你（可能）遵守了自己的职业道德和荣誉准则，但你可能会因此丢掉工作。

经过他自己的自我评估，他既决定了他没有机会晋升，公司要留住他的唯一理由就是他隐瞒代码，

我不知道你是否同意这个说法，但如果你同意的话，可能代码可能会被更好的人做。或者如果你不解释为什么这样的行为能保证他永远不能升职，

我想，这要看这种情况是否值得解决，以及如何解决。

这是管理部门的任务。首先，管理层应设法发现这种情况是否是故意的。如果是，就应该制定计划，开除违规人员。如果不是故意的，就应该制定计划对违规人员进行培训。

他们设计的程序………..这样他们的程序就会逐渐变得更难被取代。

如果我是老板就不会！

这里有两个问题：

1.程序员不好。程序员不好！

1. 2.不称职的管理。

当然，这是在假设你所代表的情况是正确的。有一丝机会，你可以解决#2的问题。这个轻微的机会是，如果老板因为某些原因根本不知道发生了什么事情。去找老板，告诉他你看到的问题以及为什么这些问题对公司不利。这样做很可能会失败，因为老板已经知道这个问题，并没有能力解决这个问题，或者说他对软件和管理软件工程师的了解太少，甚至连了解问题的能力都没有。

真正的解决办法是从解决#2的问题开始，而你最多只能在其中扮演一个次要的角色。

然后，新的经理与这个程序员坐下来，让他解释一下架构，并告诉他停止任何新的开发，并将所有的协议记录下来。同时，他找了一个新的工程师，让他在那里 “帮助 "第一个工程师记录协议，把软件放到源码控制中，并确保代码本身被很好地记录下来。这个新的工程师会做任何新的开发工作，并希望对现有软件进行bug修复和小的增强。他可能会退出，发脾气，大声反对，或者更糟糕的是，破坏事情。这就是为什么做备份是第一要务。如果能从第一个工程师顺利过渡到第二个工程师就好了，但不要指望会发生这种情况。计划是，如果第一个工程师不辞职，或者先转（更多的）对公司有破坏性，最终会被开除。

你根本就不能让这种无厘头的事情继续下去。时间越长，最终要修复它就越痛苦。不修复，因为已经会很痛苦就不修复，这绝对是错误的思维方式。

在这里我用的是 "你 "的修辞手法。要回答这个问题，你个人能做什么，先从我上面说的，把你的顾虑带到老板那里开始。同样的，这不太可能产生什么有用的结果。

下一步要看你没有告诉我们的事情了。越过老板的头顶，可能是非常危险的。如果是这样的话，那么除了评估你是否真的想继续在那里工作之外，你也没有什么别的办法了。如果这是一家足够小的公司，你可以放心地和上级领导谈，那就去吧。很有可能上级领导已经感觉到低级软件经理不称职，当然他们当然不会告诉你。这可能是他们采取更果断的行动的补充信息。

另一个遥远的可能性，如果你的主要目标是把这个烂摊子搞定，而你认为自己在这个地方是个长期的老手，那么你可以提出自己承担一些内部工具开发的工作。这应该会让你有合理的理由去和第一个工程师交流，了解事情是如何工作的，代码在哪里，等等。最终，你会成为工具开发的人，管理层就可以摆脱第一个工程师。然后，你可以要求他们雇佣一个人担任这个角色，这样你就可以过渡到你想做的事情上。还是那句话，这不是我认真建议的，但如果你真的想做并且愿意的话，这也是一种选择。