经验丰富的开发人员，为何会写出如此恐怖至极的代码！

我感到兴奋莫名。相较于普通代码维护工作，这类移植任务往往拥有更多创作自由与发挥空间，且在乐趣层面远远超过修改他人留下的代码烂摊子。

然而在开始实际工作之后，这种兴奋感迅速消失。虽然我已经拥有15年的编程从业经历，但其中的遗留代码仍然相当恐怖，甚至可以说是我所见过的最糟糕的代码库之一。原作者构建起自己的框架，且其模式与完美一词基本背道而驰：关注点未进行拆分、缩进时乱用空格/tab、同一概念拥有多个名称、来自内容几乎相同的不同方法的同一数据多次覆盖变量以及魔幻般不可解读的字符串……这一切都证明，这套代码库绝对是之前某位码农通过复制谷歌查询结果拼凑出来的成果。

然而，这种彻底违背编程规范的状态反而引发了我的兴趣，并促使我写下这篇文章。经过几个月的工作之后，我发现原作者实际是一位经验丰富的高级开发人员，且拥有出色的技能水平。那么到底是什么原因导致这位主管人员编写出如此垃圾的代码？立足于此案例，我整理出一份原因清单。其中条目为即使是经验丰富的团队中也普遍存在的种种坏习惯，其会直接体现在最终产品当中，且任何静态代码检查工具或者开发方法都无法对其加以纠正。

1、对重要性太过高估

此项目中的一大缺陷在于过度关注截止期限，甚至以损害代码质量为代价。如果开发者过度关注项目本身的重要性与交付时间，而非编写良好代码，那么其最终结果绝对会令企业管理者更加头痛。造成这种问题的根源有二，其一为过度估量、其二为过度承诺，而二者皆会增加开发者负担。

2、不重视项目相关知识

随着项目的推进，团队对于业务、其深层概念以及各元素间的联系方式亦更为了解。与此同时，各成员亦更为明确如何编写代码，这种循序渐进式的认知与问题解决途径是种必然。某些业务领域甚至存在着固有复杂性，要求开发团队拿出大量时间进行消化。

这一点在对旧的代码进行完整重写方面体现得尤为突出，也反映出您的团队是否了解项目相关知识。如果您身处某个大型项目内且其中包含无人了解且无人可以解答的功能模块，那么结果无疑相当危险。重写代码的价值完全取决于您业已掌握的专业知识，因此知识就是力量所言非虚。

3、关注错误的指标取向，例如“已解决问题”或“每天提交数量”

古德哈特法则：当衡量变成目标，其就不再是良好的衡量方式。

在尝试进行项目提速时，有人问我既然快速交付非常重要，为什么其他开发者能够比我更快进行代码提交。然而可以想象，我马上就从他的一行代码中找到了四处bug。专注于代码提交数量这种不可靠的指标会彻底毁掉整个项目，并使得成员面临更为巨大的开发周期压力。

4、假设良好的流程能够弥补个人错误

我们需要拥有出色知识储备及良好心态的人员，他们会在进程缓慢时及时发出提醒。每一款构建工具、每一种静态检查工具乃至每一类通讯工具都存在优势与弊端，大家需要结合各方面意见，而非盲目引入看起来不错的选项。

5、忽略代码审查与单元测试等最佳实践

6、雇用那些完全没有“人际”技能的开发者

这并不是说开发者就无法与他人交流。我自己也曾经相当害羞内向，但通过强迫性训练，如今我已经能够较为顺畅地完成沟通甚至演讲。

问题在于，当人们压根不想尝试沟通或者为此而烦躁时，结果必然极为糟糕。身为开发者，我们必须刻意培养自己的交流能力，甚至将其视为位于开发技能的重要事务。只有这样，大家才能在工作环境中获得更为热情且清晰的意见交换结果。交流对象身在何处并不重要。一通Skype语音即可将复杂的编码难题转变为简单的五分钟小问题。

原文作者：Christian Maioli Mackeprang

原文标题：How terrible code gets written by perfectly sane people

原文链接：https://www.linkedin.com/pulse/how-terrible-code-gets-written-perfectly-sane-people-christian

感谢  ·  转发欢迎大家留言