【开发者成长】每个人都在编写草率代码

云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！

所有开发人员都认为自己写的代码完全能让人看懂，然而，他们却无法解密彼此的代码(更不用说维护代码了)。

原因在于他们写的代码都是有效却草率的，看起来很干净，但实际上却很凌乱。草率代码是指就是那些可以正常运行，但因凌乱而不能很好地拓展或通用的代码。

计算机科学家与之不同——他们写的是无法正常运行的漂亮代码。

原因何在?以下的四大理由将为你揭秘。

理由1：对于计算机科学家来说，编码是一项艺术。而对于其他人来说，编码是一种工具

计算机科学家编码是因为他们想编码，而其他人编码是因为他们想完成某件事。开发人员一般会根据自己的第一个想法来构建程序。之后，他们会以之为基础，直到最简化可实行产品出现，通常不会考虑其他方法。

而计算机科学家恰恰相反，他们会考虑实施的每一种选择，并权衡利弊。几周之后，他们会写出一段漂亮的代码，不过由于尚未确定输出格式，代码仍然无法完全正常运行。

开发人员使用简单的工具有组织地扩展代码，从而产生了大量草率代码;计算机科学家则会在一开始建立起一个结构，之后在结构中开展工作。

最有效的就是用有机方法避免编码器的阻碍并按时交付。但是，如果想要编写持久代码，则可能需要把结构放在首位。

理由2：开发人员写代码时不常考虑读者的感受

即使是在合作项目中，开发人员写代码时也往往只考虑到它的功能。实际上，代码也需要维护，不过他们经常会把这件事抛之脑后。

问题在于，这样的习惯会造成意想不到的后果。当三个月后，他们想给代码添加一个功能时，很可能会看不懂自己写的代码。这种情况经常出现，次数之多超乎想象!

其他开发人员按要求实施新功能时，则会更艰难。看懂别人写的代码可能需要几天或几周的时间，这取决于项目的大小。

理由3：即时奖励的谬论

被问题困扰了好几天，最后终于找到了解决方案，是不是感觉特别痛快?

这确实是激动人心的时刻。但问题在于，开发人员对快速修复的渴望往往会让他们忽略那些长期存在的问题。比如，他们可能解除了故障或添加了功能，但他们没有意识到代码结构已经过时了。

这意味着每添加一个新功能，他们都必须要开展更多的工作。相反，从长远来看，对程序进行一次重组会让功能的添加变得更容易。

宁愿快速修复而非解决根本问题的人不在少数。与长期的变化相比，人类的奖赏系统更容易受到短期修复的影响。但这样一来就会累积大量的技术负债。从长远来看，这会消耗人的很多精力。

理由4：风格也是一个因素

每个人的编码风格都不一样。有些人讨厌内嵌注释，有些人却很喜欢这么做。有些人在第一行代码上方添加函数注释，有些人却选择在下方添加。有些人喜欢单值判断，有些人却对此厌恶至极。

这就是为什么同一段代码对一个人来说仿佛洪水猛兽，而对另一个人来说却是小菜一碟。要是独立工作还好说，然而如今的很多软件都是通过合作构建的。因此，在项目的早期阶段确定好风格十分重要。

当然，确保所有开发人员遵守风格指南也是必须的。否则，最后产生的将是混乱代码，毕竟其中混杂着不同的约定。

干净的危害vs.凌乱的危害

一些开发人员声称自己一直在写干净代码的，他们要么是在撒谎，要么高估了自己。话虽如此，开发人员不想写过分干净代码也不是毫无理由的：

有些开发人员整天都在清理代码，只是为了美观。如果是与其他人合作或者代码需要呈现，这当然很有用。但通常来说，完善代码与普通医疗保健提供的外科手术产生的效果一样——看起来不错，但没有解决深层次的问题。
如果他的目标是从头开始编写非常干净的代码，那么他遭遇编码器阻碍的几率就会变大。为避免出现重大阻碍，最好从一开始就自然生成代码。初学者尤其适用。