在职业生涯中，程序员难免会遇到糟糕的代码（bad code)——但是你并不需要成为一个打败这些糟糕代码的“恶人”。

从轻松的角度来讲，糟糕的代码可以创造大量的就业机会。比如：

• 需要从诸多优秀开发人员中找一个人来修复错误代码。
• 需要一两个高级开发人员来做代码审查，确保代码以后不会再次变得糟糕。
• 其他人还需要时不时地去咨询那位糟糕的程序员，以便弄明白这些乱七八糟的代码到底在干嘛。

也就是说，我们都有过类似经历。我们不知疲倦地加班加点，试图去解决一个特别麻烦的错误，这时我们发现一个代码块，而它就是问题的根源。当你试图弄明白这堆一团乱麻的代码的意义时，却发现这段代码根本无法阅读，逻辑混乱不堪，且完全未加任何代码注释，你会倒吸一口凉气，然后开始咒骂：

“这到底是谁写的代码？”

“谁竟然如此愚蠢？”

“怎么会有人写出如此毫无条理、人神共愤的代码呢？”

但我要说，这并不是正确的解决方式。毕竟，我们所有人，在某些时期都会写出糟糕的代码。可以这么说，在这个星球上，每一个开发人员都会在他的一生中制造出安全漏洞、不匹配的 UI 元素，而且绝对不止一次犯下这些错误。不能就此评价说这个开发人员很糟糕。我们都是人，是人就会犯错。

作为一名优秀的开发人员，你对糟糕代码的处理方式与你未来的职业发展有很大关系。优秀的开发人员会抛开个人或群体恩怨，对代码进行更深入透彻的理解，而不是将他们的愤怒情绪一股脑儿发泄到那些编写糟糕代码的倒霉开发人员身上。

优秀的开发人员会尽量避免主观性评价，对糟糕的代码给予建设性的、客观的批评，这样糟糕的代码就不会卷土重来。他们把解决这些糟糕的代码转化为学习和分享的机会，这样每个人都能从中受益。

这里我想分享一些优秀的开发人员处理糟糕代码的方法。

1. 识别问题

美国音乐家“艾灵顿公爵”有句话说得很对：

“问题是让你竭尽全力去努力的机会。”

请带着好奇心和同理心去解决问题。一般来说，代码的问题在于，编写代码有多种方法，而没有一种方法称得上是最好的方法。所以在评估代码前，试着找出这样写代码背后的原因。设身处地为其他开发人员着想，并找出问题所在。

程序员往往很固执。他们不喜欢被别人告知他们自己的错误。所以，正确的方法是对他有足够的同理心，找出是什么原因让他们写出如此随处可见的 goto 语句，如此层层嵌套的 switch 语句，以及如此晦涩难懂的变量命名。只要有足够的同理心，你很快就会弄明白背后原因。

“我必须在 1 小时内完成代码”

“没有可用的 API”

“我的领域知识有限”，等等……

通过识别问题，你不仅可以从代码原作者的角度来看待问题，还可以提出具体的解决措施来纠正代码，而不是在黑暗中对别人进行盲目攻击。

2. 谨慎提问

英国哲学家弗朗西斯·培根有句名言：

“一半的智慧来自于谨慎的提问。”

一旦你识别了代码问题，下一步就是与你的同事坐下来，提出一些更深入的问题。这里的关键词是“谨慎”。最好的做法是确保问答环节不会演变成一场像西班牙宗教审判一样残酷无情的审问。

对历史爱好者来说，西班牙教士托尔克玛达在费迪南德二世国王和伊莎贝拉一世女王的帮助下建立。在西班牙宗教审判所时期，许多人在街上围观人群面前被活活烧死。实际上，西班牙宗教审判所的作用是为了巩固新统一的西班牙王国的君主制，但它却是通过这种臭名昭著的残忍手段来达到这一目的。

通过问合乎逻辑的问题，你不仅能巩固自己对问题的理解，而且还允许其他开发人员对错误产生自我认识，并以此让他学会运用正确的自我质询来改善自己的代码，他需要在编写代码前用这些问题来进行自省。

通过提问，你也表明了你对他的观点持开放态度。当你的同事感到受到尊重时，他们就不太可能持有防御性态度。

一旦你找到错误和原因，你就有责任在整个团队中传播睿智的话语，这样以后就没有人再编写糟糕的代码了。

3. 抑制重写代码的本能

美国作家 Anthony J. D’Angelo 有一句名言说得很中肯：

“不要重新发明轮子，而是去重新调整它。”

编写高质量的代码会比编写前面所提及的糟糕代码花费更多时间。有时候，更快地“把某样东西做出来”在商业上是有其意义的。

Kimber Lockhart 在一次黑客峰会的演讲中曾经说过，开发人员在处理糟糕代码时所犯的最大错误之一就是去重新编写代码。大多数情况下，重写代码并不能解决糟糕的代码。因此，在采取这重写代码这一步骤之前，不妨先问许多问题：

重写后的代码一定会比旧版本更好吗？

从成本效益的角度来分析，值得付出这样的精力吗？

真的是所有的旧代码都很糟糕吗，或许我们可以重用很多旧代码?

等等……

她提出了一个包含三步骤的方法来处理糟糕的代码。

• 对代码进行优先排序。首先需要解决哪一部分问题？我们能保留代码的其他部分吗？
• 封装处理糟糕的代码。仍然让旧代码保持运行，但通过把它封装在一个模块中使其与其他新代码分离，这意味对于这段代码除了修复外，其他人不能再对它添砖加瓦。虽然旧代码仍然可以被调用，但是对它的封装可以防止糟糕代码的进一步传播。
• 凸显糟糕的代码。显式地标记糟糕的代码，这样就没有人复制这些糟糕的代码让问题变得更加复杂。Lockhart 建议删除糟糕代码，但是要小心地进行删除操作。而且建议为了准确识别要删除的代码，每周花几个小时来创建一个自动化系统，这对于系统的长期清理来说是一个很好的实践。

关键是要从最坏的情况中找出其最好的部分，并以缓慢而稳定的方式来消除最坏情况。并不是所有糟糕的代码都是技术债造成的，如果在这些代码中也有不错的部分，我们应该聪明地对之进行合理重用和适应。

4. 最后，要谦虚

正如美国作家和演讲家 Zig Zigler 所说的：

“谦卑会比傲慢打开更多的大门。”

总所周知，骄傲导致许多悲剧英雄的堕落。

例如，简·奥斯汀的名著《傲慢与偏见》中的达西先生在得到伊丽莎白·班纳特的爱之前，不得不放下他的傲慢。而但丁把骄傲列为七宗罪之一。

我想大家都同意以上对于骄傲的看法。而与之相对的，谦卑的真正定义是一种安静的理解，即使你擅长你所做的事情，但你不期望别人过分赞扬你。

所以，如果你已经修正了代码，也不要让你的自负对你产生影响。不要得意忘形地向整个团队发送垃圾邮件。也不要一有机会就站在高处大声嚷嚷你的成绩。

要知道，你也是凡人，不可能毫无纰漏永不失误。你也可能会写出糟糕的代码并陷入同样的困境，当这种情况发生时，你需要的是每个人的帮助和支持。请永远不要忘记这一点。

简而言之，请以开放的心态处理糟糕的代码，学习，改进，然后你教育其他人去改进。

正如美国作家 Roy T. Bennett 所说的那样：

“要去改进，而不是找借口。要寻求尊重，而不是寻求关注。

作者介绍：

Ravi Rajan，总部位于印度孟买的全球 IT 项目经理。他还是一位狂热的博主、俳句诗人、考古学家和历史狂人。也是一个多产的作家，写作主题从人工智能到爱情，十分广泛。