如何阻止一个员工挟持公司？

我可以做什么来解决这种情况？

没什么，你才来了几个月，这不是你的职责，你除了发牢骚外，没有权力做什么。

你的上级有很多的资源，但7年来都没有用过，所以这个时候你只是在二度猜测他们的理由，分析一个同事，而不是专注于自己的职责和任务。

雇佣两三个你能找到的最聪明的开发人员。把所有的代码交给他们。让他们验证他们确实拥有所有的代码，运行软件所需的一切。让他们学习代码的作用，记录下来，重构它，直到他们达到比A先生更快地解决问题的程度。

我想，以A先生的开发方法，他的代码所做的工作其实比一般七年的开发会产生的工作量要少很多，而且代码是模糊的，但实际上并不难，这让新人的工作轻松了很多。

PS。由于一些评论，我想再次强调一下。问题不光是钱的问题，问题是软件的开发难度大不如前，因为A公司的重点是让开发难度大，而不是改进软件。

简答:简答:你的组织目前正处于公车因素.

这就是为什么你永远不要让一个人掌握所有的知识。这是一个巨大的风险。如果这个人决定退出，或者是真的被公车撞了，会发生什么？如果情况如你所描述的那样，那么整个公司就没了。

开始让其他人通过代码，不管有没有A先生，最好是没有，因为你已经确定了他的问题。剥夺他的权力，这样，如果他真的被公车撞了，你们就不会因为他的出现而无路可走了。

其他的答案都很不错，但还有一件事我会考虑：

我个人的建议是考虑开始寻找其他地方工作………..如果管理层在7年内没有采取任何行动，我不确定这是否是一个你愿意长期工作的地方。在我看来，这是个警告信号，预示着公司有其他问题。

而他反复做坏的决定，故意让软件产品不稳定，难以维护和排除故障

那么，为什么你的团队要让这些 “坏决定 "通过设计评审或代码评审？如果你没有代码评审流程，甚至没有设计评审流程，那么从长远来看，你应该提倡这样做。

但在这之前，你需要知道的一切都在Joel on Software的博客文章中。 Getting Things Done When You’re Only a Grunt

而且他有一个专门的呼声，用来对付bozos。FILE BUGS. Spolsky:

作为一个特警，你的目标是最小化伤害，又名遏制。在某个时候，这些天才中的一个人会花两个星期的时间写出一些代码，这些代码糟糕得令人难以置信，以至于永远无法工作。你很想花十五分钟的时间，从头开始正确地重写这个东西。抵制住诱惑。你有一个完美的机会来中和这个白痴几个月的时间。只要不断地报告他们的代码中的BUG就可以了。他们会别无选择，只能继续苦练，直到你再也找不到任何BUG为止。这几个月的时间里，他们在其他任何地方都无法造成任何破坏。

否则，作为团队中的新员工，你的目标应该是培养自己的优秀声誉。

把这个贴在墙上。(你要改一些名字和地点)。

几年前，我在美国中西部的一家制造公司花了一个星期的时间，在公司内部讲授程序设计课程。在周五下午的时候，一切都结束了。安排这门课程的DP经理从他的预算中掏钱，把我请进了他的办公室。"你有什么想法？"他问道。他是想让我告诉他我对他的操作和员工的印象。"挺好的，"我说。"你那里的人都很不错。" 程序设计课程很辛苦；我很累；员工评估咨询是要额外收费的。不管怎么说，我知道他是真的想把自己的想法告诉我。"

“你觉得弗雷德怎么样？"他问。我们都认为弗雷德很了不起。” “他很聪明，"我说。"他对方法不是很热衷，但他对程序设计很了解。” “是的，"新闻部经理说。他在椅子上转了一圈，面对着贴在墙上的一张巨大的流程图：大约五张大的行式打印机纸，也许有两百个符号，数百个连接线。"弗雷德这样做了。这是我们每周的工资总额的堆积，用于我们的周薪。除了弗雷德，其他人都不懂。” 他的声音降到了恭敬的嘘声。"弗雷德告诉我，他自己也不太明白。"

“很了不起，"我恭敬地喃喃自语。我清楚地看到了画面。弗雷德扮演的弗兰肯斯坦，弗雷德是不受控制的怪物流程图的杰出创造者。"可是，简呢？” 我说。"我觉得Jane的表现很好。她拿起程序设计的思路非常快。"

“是的，"DP经理说。"简是带着很好的名声来找我们的。我们以为她会像弗雷德一样出色。但她还没有真正证明自己。我们给她出了几个我们以为会很难的问题，但当她做完后发现这些问题其实一点也不难。大部分都很简单。她还没有真正证明自己——如果你明白我的意思的话？”

“我明白他的意思了。”

• 摘自《软件需求与规范–米歇尔-杰克逊》一书（值得一读）。

答案很简单：开除他。你可能需要在短期内支付一笔不小的费用来修复他所造成的烂摊子，但A先生并不比世界上任何一个人都聪明—-短期内会有其他人会有能力在短期内维护软件，并在长期内使其变得更好。

有一个角度可以考虑，

公司喜欢这样做。如果他们不这样做，7年的时间是很长的。

作为开发者，我们往往会忘记，我们的工作不是写出好的或聪明的代码。我们的工作是把产品 “噗通 "一声变成现实。写出好的代码只会让这个过程变得更好，但你可以用完全垃圾的代码写出一个非常棒的产品。

公司支持他的决定，甚至还把他请了回来。他们 "喜欢 "他和他的做事方式。你不可能改变这一点，即使你以某种方式设法让他被解雇。有可能发生的是，他们会选一个新的人做 "那个人"，然后这个过程又要重新开始。

管理公司不是你的工作。公司已经做出了自己的选择。你需要做出你的选择。向这个人学习（他已经做了7年的工作，他一定是做对了什么），或者继续前进。

不管是好的还是坏的，没有什么_也没有什么人是不可替代的。(有的人可能比别人多，但还是)如果大家知道了解决方案，就可以开始逆向工程了。

我过去不止几次站在你的立场上。在和你最相似的情况下，"A先生 “早就不在了，然而，我在一家电缆公司的后端有一个单一的解决方案，我没有本地开发的库的源代码，而且我在这个行业里还是个菜鸟。我完善了每个模块，然后再去做下一个模块。几个月后，我就把之前的应用干掉了。

不可替代性被夸大了，

处理遗留的东西也不是一件容易的事情，也许你的同事出于惯性，或者因为你的同事不懂，所以才会这么做。

从业务角度来看，基本上有两种解决方案：

1. 渐进式过渡，也就是说，拿一小块功能，重新实施到高标准，并投入生产，然后继续一块一块的做下去，直到旧系统可以完全退役为止
2. 完全建立一个新系统，然后过渡到新系统，可以是一次性的，也可以是逐步过渡到新系统，比如说在新系统上启动新的客户，然后逐步将老的客户转移到新系统上。新系统的功能不一定要像旧系统那样功能齐全，它的卖点可以是更低的价格、更快的支持等。

方案一的优点是不需要大量的前期投入，你的新代码会逐渐得到现场测试，而不是一下子就能完成，而且你会很早就开始看到效益（因为企业花更少的时间和金钱来维护旧系统中不再活跃的部分）。

不过，缺点是新系统的结构可能会受到旧系统的结构的强烈影响，在某些情况下，要更换非常杂乱的系统中的部分真的很难。有时候，有点创意是必要的—-如果其他方面都不行，你的新代码可以模拟旧系统上的按键和按钮点击! 但与旧系统的接口可能会产生很多工作，所以还是选择方案2比较好。问题是，这将花费多少钱，能节省多少钱？试着估算一下上述每个方案的费用，这将有助于决定选择哪种方案（如果有的话）。这将取决于功能需求，现有系统的结构，以及企业是否愿意花钱/使用信贷来预支未来的节约。

作为软件团队的一员，你的工作不是管理公司和员工。

你的工作_是写出好的软件。所以你要担心的是软件，而不是人。

你看到了软件的问题，从你的问题中，听起来你有一些想法来解决这些问题。把这些想法带到你的经理那里去争取。

“经理，这个软件没有经过测试，目前的实现方式是无法测试的。我建议我们努力用一种更可测试的语言重新实现，使用更容易测试的设计模式。”

现在，很有可能是：

A.这是一项大工程，公司不愿意投资，因为他们认为没有必要

B.A先生会反驳这个东西，而且会被听从，因为他的资历比较深

如果这种情况发生，那么你试图做好你的工作，却被扼杀了。是时候去找一份新工作了

如果这样一来，他们就会听你的，你签了一吨的工作。

你不能假设背后的意图。

有目的的远离现代软件开发框架

他可能只是最喜欢用他最熟悉的东西？

我曾在大公司工作过，他们的流水线是由古老的和全新的代码拼凑而成的，某些代码 “只是在那里工作"，从未被人碰过。最重要的是，写这些代码的程序员早就不在了，没有人真正理解他们是如何工作的，所以他们只是增加了新的功能来适应不断变化的需求。他们的流水线一直都是活的，所以任何重大的推出都可能会带来灾难性的后果（即非常昂贵的工作和交付中断），所以他们不敢太过触碰。如果没有合适的文档，要么提出创建一个（如果你知道你有资格和时间的话），要么问是否应该创建一个来加快工作的速度。

你应该（就像你已经做的那样）和你的经理谈论适应新技术或改进，但期望他同意你的看法，即使他同意你的看法，也不会有什么结果。

遗憾的是，公司的结构会抵制突如其来的变化，而现代化是一个逐渐消磨阻力或一点一点地实施的问题，除非你能证明你的 "革命性的变化将带来一个没有风险的黄金时期的财务利润"。

就算他是为了保住自己的工作而恶意为之，我看也不是你的责任，尤其是在你的直属上司知道这件事的情况下，你会怎么做？

你会怎么做，是和你的经理谈，还是不和他谈，还是和上级领导谈，还是和当事同事谈？

既然你的经理决定不追究这件事，他很可能不想和他的上级领导谈，不管有没有你，或者说他已经和他的上级领导谈了，并且在那里遇到了封杀。

如果你和他的上级领导谈了，没有他，你就有疏远他的风险。

和这位同事谈，事后肯定会造成很不好的工作环境，他肯定会否认任何指责。

唯一的解决方法就是拿掉A先生的控制权。

首先要得到管理层的认可。

做一个全新的git。

1.导入一个好的、约定好的起点。从那里开始，把代码向前推。

1. 完全不给A先生访问权限（甚至不要告诉他它的存在）

4.把A先生的改动移植到你自己的repo，或者重写。

5.让A先生对他的repo做任何他想做的事情，因为你不会使用。如果有必要，做一些假的代码修改，让它看起来是活跃的，这样就可以把你的新repo隐藏起来。

7.最终代码会偏离得足够远，他就会自动过时。

你需要做一个关键的决定，是保留还是放弃模块策略。

7.模块不一定是坏的，你需要保持它们的同步性和工作状态。

这将是一个很大的工作，因为你必须重写很多现有的代码。对他来说，这将是完全陌生的。

要知道，作为一个非管理者，这不一定是你要解决的问题（除了按照指示去做已经决定好的事情，作为解决方案的一部分）。

还有，千万不要盲目地把 “我们希望XY问题得到解决 "理解成”………..因为XY问题"。在公司政治中，不存在 “一个没有个人目的的无辜的创新者，我们不能对意外的后果负责 "的说法。

如果你这样做，就做_有个人目的的创新者，不管是哪种方式，都要承担后果。

@MightyPizza - 你在浪费你的时间。去别的公司工作吧，那里有更多更美好的未来。如果这家公司是你的最后一站，你应该只花这么多精力去解决这个问题。

这绝对是你能得到的最好的答案。为自己的跳槽做准备。"我想让软件现代化，可维护性和稳定性。"

最好的方法是在第一天，第一行代码，而不是用别人的垃圾热堆。

他在这个位置上呆了这么久，说明企业有意识或不自觉地运用了汉龙剃刀:

永远不要把那些可以用愚蠢来解释的事情归咎于恶意。事实上，A先生似乎让人尝试着去改变一些事情，然后当它们出了问题时，他又英勇地把它们修好了。

你也应该考虑到A先生可能患上了邓宁-克鲁格效应，因为他无法看到自己所做的事情是错误的。谁知道呢。你要拿什么作为第一原则，那就是不管他有多气人，你都要把他当做不是恶意的代理人来处理，

你的问题似乎是以他只是追求工作安全为前提，拒绝更新东西来嵌入这一点为假设。你可能是对的，但你不能据此来对付他。

我相信你的一些聪明的想法，一定会遇到 “我们试过一次，由于X的原因没有成功 "这样的阻力。从商业的角度来看，这是有道理的，他们承担了风险，但没有成功，为什么要再试一次呢？

你说的是你的目标。现代**

没有隐含的商业价值。这一点无论如何都是值得商榷的。你说Java 8，别人会说Rust或Golag是现代。只要支持一个系统就没有什么大的更新价值，

2. 可维护

这个也可能很难说得过去。A先生会辩称可维护，因为他维护的是可维护。你必须争辩说，维护成本会大幅下降，以证明完全改变框架是合理的。Stable**

你说你想让系统成为HA，但你也说它

软件监控事件，对事件做一些处理，然后采取适当的行动。

**那么该怎么办？ **

你的系统听起来就像一个[大泥球]

定义的大泥球 > A Big Ball of Mud is a haphazardly structureedly, sprawling, sloping, duct-tap-tape-andbaling-wire, spaghetti-code jungle.

在一个不合作的开发商的管理下，正面处理这个问题将是非常令人沮丧的，很可能是无果而终。

• 如果你不能让系统HA，那就用一个消息总线系统之类的东西来捕获消息，这样如果系统崩溃了，你就不会丢失数据。

• 下次需要执行一些操作的时候，可以将其构建成一个独立的子系统，它可以监听消息总线并执行自己的操作。

• 如果你可以开始影响一些下游的效果（例如封装所采取的动作），那么就把这些放在子系统中。

有一些论点支持majectic monolith优于microservices，但这是假设 monolith是很好的工程化的。在你的情况下，系统可能作为一个工程设计良好的单体是没有问题的，但如果它的工程设计不好，你就需要把东西拆开。这样的方法可以在微服务架构的核心处留下一个实质性的单体，但大多数新的开发都发生在微服务中，而单体相对静止。

然而，与A先生一起玩耍是很重要的，不要告诉他你是在替换系统，而是告诉他你是在 "提高可靠性 "或增加冗余。如果你攻击他所做的事情，他会让你更难实现你的目标。

你可能会被人说你把系统弄得更复杂。这是事实，但如果你要长期前进，这是必要的。

なんでみんなそんなにAさんをクビにしたがるの？彼は何も悪いことはしていないと思います。ソフトウェア開発とは、かっこいいツールやフレームワークを使って新しいものを作ることではありません。ただ「動く」だけの安定したものを作ることです。あなたの会社はAさんが大好きで、Aさんの仕事に満足しています。

わざと現代のソフトウェア開発のフレームワークから遠ざかっている

あなたのシステムは現在安定した状態にあるのに、なぜチームはスクラムやアジャイルのような現代のソフトウェア開発のフレームワークを使う必要があるのでしょうか？

コアビジネスロジックをテストできない言語で書いている

コアビジネスロジックは自動的にテストされなければならないという要件があるのでしょうか？

ソフトウェアコンポーネントを30モジュールに再設計し、複雑さとバージョン認証の問題を追加する

この実装はあなたの会社にどれだけ多くのコストがかかりましたか？

HA（高可用性）機能がないことを確認し、スケーラブルではない方法でそれを設計しました

まだ同じ質問 - この実装はあなたの会社にどれだけ多くのコストがかかりましたか？

私の意見では、あなたがここに書き留めているすべてのことは、彼に対するあなたの不満に過ぎません。彼が多くの「ひどい」ことをした場合、システム自体が最初の1年でメルトダウンしているだろうし、彼はあなたの会社でその長い間滞在していたことができませんでした。

很简单，企业必须给他一个丰厚的加薪，让他把软件的现状和所有的知识都记录下来，然后他们就会解雇他。或者是请一个技术咨询公司来记录所有的东西，他看到墙上的字迹，最后就会离开。