本文原载于jesuisundev.com网站，经原作者授权，由InfoQ中文网翻译分享。

在本文中，我将向您展示一些我见过的最糟糕的代码。它们被称为“魔鬼代码”，会产生严重的后果。然而，我们发现通过一些好的实践，你可以很容易地避开它们。

《魔鬼的密码》

要改进的代码不同于所谓的“魔鬼代码”

无论使用哪种语言，“魔鬼代码”都是不好的，因为它会危及项目的稳定性和可维护性。在我的职业生涯中，我见过很多“魔鬼代码”。

当它堆积起来，你的项目很快就会变成“十八层地狱”的样子。如果你喜欢到处惹事，领导就会对你另眼相看。

模糊和不一致

很久以前，我早上醒来，被末日景象吓了一跳。生产环境出现大错误，所有系统票莫名其妙返回“null”。到处都很乱。每个人都像无头苍蝇一样跑来跑去。

我跑到公司，冲到工作站。第一步是观看基巴纳。但是，没有日志，什么都没有。为了找出原因，我决定追溯一下出票的路径。所以我必须深入研究系统从诞生到现在所创建的内部库。经过一番调查，我发现了一堆文件，这是问题的来源之一。

然后，我看到了这一幕:

// use id and expire to get ticketasync function get_ticket(i, expire) { return CheckisNotExp(expire).then(async function() { var t = await GetTicketModel(i) if (t) { return t } else { logger.error(JSON.stringify(t)) return null } }).catch(async function(e) { logger.error(JSON.stringify(e)) return null})}

复制代码

真的有“我”这个变量吗？这是身份证，不是吗？是整数还是UUID？到底什么是到期？是日期还是时间戳？为什么会有camelCase，PascalCase，snake_case？带promise的异步注释和另一个异步注释？如果失败，我们将返回null？真是个魔鬼！

当时每5分钟就有一半公司同事给我发Skype消息，要求ETA维修。

但首先，需要有人知道这里到底发生了什么。而我意识到，不是一个人，而是三个人要对这个问题负责。很久以前，他们中的两个离开了公司，而第三个今天早上没有来公司。

根据Git的记录，这三个人接触这个文件很久了。因此，他们留下了不一致的代码，不同的风格，不同版本的ECMAScript和不同的处理promise的方式。

反正在这段代码里，一切都是模棱两可的，一切都是不一致的。这是一个极好的反面案例，你要千方百计避免。不用说，代码审查不包括在这里。

为了解决问题，我们必须快速重写，并更改那些变量和函数的名称，这样就不能再有差异了。此外，Async/Await在任何地方都应该以相同的方式进行。

我还想确保不遗漏任何错误，然后返回一个null。如果出了问题，这些错误肯定会破坏功能。异常应该由上层处理。

// hotfix// @todo rewrite the ticket module entirelyasync function getTicket(ticketUuid, ticketExpirationTimestamp) { await validTicketExpiration(ticketUuid, ticketExpirationTimestamp) const ticket = await getTicketByUuid(ticketUuid) return ticket}

复制代码

最好的解决方案是重写这个模块的一部分。这里的验票逻辑很可怕。但这不是最重要的。当务之急是找出并修复错误。

更新代码后，真正的错误开始浮出水面。前一天进行的配置更改改变了票证创建行为。回到之前的配置可以立刻解决这个问题。在接下来的一周里，这个模块被完全重写了。

酱汁意大利面

很久以前，我在做一个代码干净整洁的产品。作为优质产品，一切都是内部优化。该功能是用尽可能少的代码开发的。代码非常重视可读性。由专注于整洁代码的工程师管理的代码审查过程确保产品严格遵循所有最佳实践。固体，干，吻，YAGNI和其他你能想到的缩略语可以在这里看到。

即使在这一点上，该产品的一个特殊部分也会间歇性崩溃。在一次冲刺中，我终于设法安排时间调查了这件事。

很快，我意识到问题不在产品。这些错误只有一个共同点:依赖性。这是通过内部工件处理的内部依赖。

它由另一个团队管理，令人惊讶的是，这些代码并不是免费提供的。你必须得到许可才能看。因此，我要求进入以了解发生了什么。然后，我收到一条Slack消息，询问我为什么要访问源代码。

“你好！为什么您需要访问此存储库？”

“这是什么意思？你知道我在这里工作吗？等等，我在路上了。”

在我突然出现在他面前之后，我终于接触到了这个项目。

我在里面看到一个300KB大小的文件。300KB文本，就那么大。好几年没碰了。我不认识上次碰它的人。是最可怕的魔鬼。

这是我一生中见过的最大的意大利面条代码。由于篇幅有限，我没有把所有代码都放在这里。以下代码只是其中的一部分:

// Thousands of lines of spaghetti codesif (global.Builder){ module.exports.buildPgs = function(pgs, options, limitNodes = 0) { var config = options.config || {}; var builded = []; pgs.each(function(pg) { var supported = pg.prop('tagName') == "INPUT" && pr.attr['name'] == "file" && options.pgs.rel.active == "" && global.FileReader; if (!supported || !pg.f || pg.f.length == 0) return; for (var i = 0; i < pg.f.length; i++) { builded.push({ file: pg.f[i], instanceConfig: _.extend({}, config) }); if (isFunction(options.before)) { var returned = options.before(pg.f.path); if (typeof returned === 'object' && global.status.in_progress) { if (returned.action == "skip") { var needsSkip = (typeof global.status.in_progress === 'boolean' && global.status.in_progress) || _.hasAny("cancel", Global._quotes.BAD_DELIMITERS) || str.indexOf(Global._delimiter) > -1; if(needsSkip) return; } else if (typeof returned.config === 'object') { var LOCAL_BUILDER = new global.Builder("/builder/" + options.module + "/" + options.module + ); for(var s=p,a=p.matchIndex(o),shift=0,i=0;i<a.length;i++){ var deepcopyfile = JSON.parse(JSON.stringify(pg.f[i].getRawValue())); LOCAL_BUILDER.build(deepcopyfile) LOCAL_BUILDER.onmessage = global.Notification("buildPg", deepcopyfile); } } } } } }); }}// Thousands of lines of spaghetti codes

复制代码

我甚至不敢碰它。

在这种情况下，代码中找不到解决方案。我召开小组会议，向他们介绍具体情况。我的计划也很简单——我们不碰它。

我们用已经可用的开源模块替换了这种对撒旦的依赖。和往常一样，这是一个大问题，必须做一些准备工作才能正确插入新的依赖项。

起初的快速调查变成了持续几天的艰巨任务。

在会议桌的另一端，Scrum主任很生气。我们谈论得越多，我就越觉得不去碰那该死的东西会很困难。当我表明我们的情况时，讨论结束了，答案是否定的。

“你只需要把这个模块移动一点点并修复它，然后我们会继续我们原来的工作。”

因此，我在代码质量和项目可持续性方面做了额外的工作。我说不，我甚至准备辞职。他们显然问过其他开发商。所有人都拒绝了。

因为这个问题的严重性，我得到了更换这个模块所需的时间。我为开源依赖开发了一个小型适配器。然后，我摆脱了那种被诅咒的依赖。

之后产品一切顺利，工作正常。

开发人员经常抱怨代码杂乱无章，这是有充分理由的。这是你见过的最糟糕的代码。不过可以保证的是，你不需要很大的投入就可以避免这种情况。

驱除

在开始，本文想写一个最佳实践的列表。

"作为开发人员，为什么以及如何应用最佳实践."

但是，上面这个标题很容易让人像吃了大剂量安眠药一样昏昏欲睡。另外，我改变计划有两个原因。

首先，对我来说，尤其是对你来说，先说说后果会有趣得多。对于开发者来说，这很重要，因为这是魔鬼代码的起源。另外，如果你能为我的遭遇微笑，那太好了。

其次，网上有很多关于这个话题的文章。他们都有一个共同点，就是他们的内容都是从两本书里摘录的。这两本书培养了几代开发者。——罗伯特·马丁的《代码清洁》和史蒂夫·麦康奈尔的《代码百科》。

真的要缩短代码审核时间，再也不想出什么魔鬼代码吗？直接看原始资料就行了，花点时间看完这两本书。

我发现代码百科的方法更具可读性和实用性。然而，尽管代码整洁很复杂，但它教给我的知识并不亚于甚至超过代码百科。前者用的代码是Java和C++，但具体是什么语言谁管呢？你在这本书里学到的是规则和编程概念。

使用代码审查来验证代码是一件好事。但是，如果你不确定为什么是好代码，你经历过的魔鬼代码最后还是会出现。

原始链接:

https://www.jesuisundev.com/en/the-worst-pieces-of-code? file guid = vwdYpVcQyqDCYhCr