开发者为什么需要“不良代码”

“从未犯过错误的人也从未有过新发现。” — 塞缪尔·斯迈尔斯

想象一下场景：苏格兰，1928年。可能在下雨，一位科学家不小心让他的培养皿被霉菌污染了，他并不知道这个错误最终将拯救数百万人的生命，这项伟大的发现就是青霉素。这位科学家的名字就是亚历山大·弗莱明，他一个小小的技术失误改变了世界，让人们的生活变得更加美好。

在当下，软件开发领域存在着一种错误的观念，是什么呢？

与弗莱明的屡次失败而发现青霉素的方式类似，在实际开发中，粗糙的代码可以带来意想不到的结果。

在这篇博客文章中，我们将分析“好代码”与“不良代码”的概念，以及为什么开发者们不应该一开始就害怕“不良代码”。

为什么“不良”代码在某种程度上来说是有益的。

让我们明确一件事，本篇博文中不存在“代码质量歧视链”，但开发者们都清楚，市面上的确存在一些不良代码。

这没关系，真正有问题的点是我们对于“不良代码”这个术语的误解。

“好代码”和“不良代码”的概念在过去十年左右已经悄悄进入开发领域，这已经成为一个相当复杂的问题。不是因为我们分辨不出区别，而是因为我们经常过分强调从一开始就写出完美的代码，以至于我们忘记了“初稿”存在的合理性。你可以保证世界上伟大的艺术家、作家和工程师，例如达芬奇、莎士比亚和特斯拉等在没有草图之前就可以创作出伟大的作品吗？如果不能，为什么在编码时开发者们普遍忌讳“初稿”呢？

那我们将如何重新思考代码？从我们的代码词汇中去除“不良”这个词吗？

这很简单：“不良”代码是编写好代码的重要部分。

“但这没有道理！”有些开发者可能要哭了。我们可以这样说，当一个开发者开始编写一个程序、应用程序，甚至一个随机的编码项目的想法时，不应该先考虑代码质量，而是应该关注想法的质量。

这是什么意思呢，这种方式可以让开发者摆脱“创造完美”的压力，不要太关心最终结果。把东西写在纸上，写出一些可行并且有良好基础的架构，将帮助你实现‘好’代码的目标。

毕竟，没有架构你不能创造一个完整的项目。

相关：通过 GitHub Actions 增强 CI 中的代码质量

我们还要坚持认为初代版本的代码是“不良”代码吗？

我们所说的“不良”代码实际上意味着什么？是代码跑不通吗？充满 bug 吗？或者它只是不符合我们的标准？

让我们重新表述原始问题：对你来说，“不良”代码意味着什么？

‘不良’代码对每个开发者来说意味着不同的事情。说实话，这是一个模糊的术语，可能意味着多种不同的事情。对于开发者来说，它只是彻头彻尾的懒惰，一个单词的答案，伪装成不存在的、陈旧的、无味的反馈。

给代码贴上“不良”标签实际上可能弊大于利。他使得开发者们在写代码的时候、在进行开发工作时候畏手畏脚，甚至不惜一切代价避免“不良”的标签。所以，我们应该从整个行业的视角作出改变，不再使用“不良代码”这个术语。

毕竟，即使是“不良代码”仍然可以起到作用。“不良代码”真的会造成不良结果吗？

事实上，让我们重新思考这个术语，并创造一些更有生产力的概念，一些更有可能提高开发者信心、生产力以及开发速度的概念。

相关：如何提高 C++ 代码质量

我们的目标是编写可用的软件，逐步提高代码质量，从初稿进化成为好的代码。

不要误解。我们并不是说开发者应该变得自满，随意输出低质量副本，然后满不在乎地耸耸肩就离开。从应用程序速度、安全性到维护方面等诸多层面上讲编写好代码至关重要，过分强调‘不良’代码将使最终编写好代码变得更加困难。

这篇博文能提供给开发者最大的启发是：我们不应该害怕输出‘不良’代码。只要我们明白它只是一个起点，开始就是成功的一半。

对于那些正在审查我们团队代码的人，我们需要找到更科学合理的代码评价方法，而不是只，说一句“这的确很糟糕”。更加具体反馈可以使开发者从持续改进的代码中获得更好的结果。这是一刀切的否定所达不到的效果。

点击了解 Incredibuild 加速 C/C++ 构建编译的解决方案，并获取试用 License！