想想下面这个问题：

“如何开始使用单元测试？”

作为一个技术问题，你身边的人肯定会一脸狐疑的看着你，然后告诉你：“首先，写一个单元测试。然后，运行测试。”

然而，当有人问你这样一个问题的时候，很显然他们想要的并不是这样的回答。

他们真正想问的是，应该是：“如何整理多年来累计的杂乱代码库。我的一个同事，已经工作了40年了，他排斥所有新的技术，而且管理层没有足够的预算让我们去写 ‘额外’的代码。在这种情况下，如何使用单元测试？”这个问题，才是真正难以回答的问题。

经常有人问我这种看上去很简单，但是实际上非常复杂的问题。“我团队中有一个人写的代码极其纷乱复杂，根本无法维护。我该怎么办？”

先说明一点，对于“我同事代码写的乱怎么办？”这个问题，每个企业和机构的态度都不太一样。

例如，有的企业可能会帮你和那个开发者进行沟通。但是也有的企业，其态度会是：“不管你喜欢还是不喜欢，你所抱怨的那个开发者就是公司的高级开发者。”在这种情况下，你可能会觉得自己很无助。

因此，我需要事先说明，我的这些建议，可能在你所在的公司内并不适用。

那个同事写的代码让你忍无可忍，格式混乱，难以阅读。他的代码让你在心理和身体两方面都感到恶心。你甚至觉得，他这么写代码，就是为了针对你。

尽管你讨厌他写的代码，但是你确定他的代码真的不好吗？你说他的代码乱，有什么证据吗？你凭什么说他的代码写的乱？你是否将他的入口点和出口点绘制成图了？你是否用图表分析了代码中的依赖？你不喜欢他的代码，是否只是因为他写代码的方式与你不一样？

质疑你的并不是我，在没有证据的情况下，大部分人都会质疑你的想法，尤其是你批评的那个人。除非你能够用数据说明他的代码真的有问题，否则你的“指控”就是苍白的。

在指责别人之前做一点功课，用数据说话，给你的观点拿出论据。

为什么要问自己这个问题？因为公司里的其他人会这么想。没错，你拿出了证据，证明了那个人写的代码太乱。但是这就够了吗？

有这样一种可能：你所指责的那个人，他可是公司的元老！他是公司第一个开发者，他加入公司的时候，电子邮件还没出现呢，他们之间还用信鸽通信呢。公司第一版的软件就是他凭借一己之力写出来的。你能跟这样的人叫板吗？

我没开玩笑，这个问题很重要。你需要考虑一下自己的角色。如果在团队中，你扮演的是领导人或是导师的角色，而对方是一个新员工，你直接指出他的问题，这样不会有大的差错。但是如果你是团队中的新成员，或是初级工程师，这样说团队中的元老，你的好日子也就到头了。

你一定回想，在事实和正义面前，角色的差异并不重要。老实说，这也是我的信仰。但是我猜如果你这么做了，公司的HR一定会好好和你“谈一谈”。

“以下犯上”会让你陷入被动的局面——即使你说的是对的。如果你一定要挑战一下，一切后果请自负。最好的结果就是，即使你胜利了，也是一场“惨胜”。

假设你拿出了足够的证据，对方也接受了你的看法。团队内的其他人也没有提出异议。

但是如果你没有给出替代的方案，人们依然不会完全接受你的意见。假设有一个人向你走过来说：“我做了很多研究，发现你的代码写的太乱。”然后转身走开，你会怎么想？因此，你需要在提出问题之后，给出相应的解决方案。

除了替代方案之外，你还要想对方证明你所提出的方案能够产生更好的结果。例如，你可以在团队中找一个人（另外一个团队的人更好），让他比较新旧两种代码编写方式，看看哪个更容易理解。

你收集了证据、提出了问题、给出了替代方案。这样依然不够。

一定要注意自己的态度，不要让人觉得你的态度是“我的方式是正确的，你的方式是错误的”。

不要变现的好像你更优秀、更有经验，即使事实的确如此。你们两个之间的对话方式，应该是探讨一个问题的两个平等的同事。

在文章的开头，我谈到了这个问题，但是我还是想要重申一下。“同事代码写的乱，我该怎么办？”这个问题看似是一个技术问题，实际上是一个人际关系问题。

取决于你的做法，你可以和平的解决这个问题。或者，你也可以逼迫他采用你的做法。你可以给他发一封愤怒的邮件，撤销他提交的代码，在code review的时候把他的代码批的体无完肤，事事和他作对。但是这样做，不仅会激怒他，还会影响团队中每一个人的进度。

简单说，如果没有良好的沟通，你无法改变对方的习惯。因此，无论你打算走哪条路，你都要明白，这是一个需要你进行说服对方的人际关系问题，而不仅仅是一个技术问题。