同事代码写的乱怎么办?

想想下面这个问题:

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

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

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

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

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

免责声明

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

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

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

用数据说话

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

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

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

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

问问自己:“我算什么啊?”

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

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

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

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

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

提供替代方案和结果

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

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

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

谦虚和礼节

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

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

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

总结

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

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

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

本文文字及图片出自 www.sdk.cn

你也许感兴趣的:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注