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

 

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

 

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

 

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

四大理由

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

理由3：即时奖励的谬论

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

1、有些开发人员整天都在清理代码，只是为了美观。如果是与其他人合作或者代码需要呈现，这当然很有用。但通常来说，完善代码与普通医疗保健提供的外科手术产生的效果一样——看起来不错，但没有解决深层次的问题。

 

2、如果他的目标是从头开始编写非常干净的代码，那么他遭遇编码器阻碍的几率就会变大。为避免出现重大阻碍，最好从一开始就自然生成代码。初学者尤其适用。

但反过来讲，开发人员也并不想让代码过于混乱，这会让代码变得难以维护。缺少维护会导致代码腐烂，从长远来看，这样弊大于利，项目会被放弃。

 

因此，开发人员需要在立竿见影和可维护代码之间找到平衡。很多人都深陷混乱的困境，因此提高清洁度是必由之路。

五项技巧

 

养成一些良好的习惯，可能会对开发人员的清洁度和生产力大有益处。

技巧1：尽早测试，经常测试

 

有些开发人员对自己的技术很有信心，甚至到了不运行测试就构建整个项目的地步。但是，除非手头的任务完全微不足道的，否则会后悔的。

 

他们一开始编译或执行程序，屏幕上就会显示错误信息，情况可能还会更糟。几个月以后，用户发现程序无法正常运行，错误才被发现。

 

从事技术工作会获得如下经验：

 

“如果没有经过所有情况的测试，永远不要认为程序会正常运行。”

 

尽快构建可执行文件。只要有机会，就进行测试，一旦出现错误就可以立即进行修复。

 

技巧2：结构合理，格式随意

 

只要代码的基础结构良好，就可以进行快速修复。而现实是，开发人员常常面对的是结构凌乱或过时的代码。在这种情况下，最好花些时间重构代码。如果修复程式未正确注释或存在隐藏变量名，也没什么大不了。

 

但是，在错误代码中构建干净的功能完全是浪费时间和资源——开发人员可能必须要重写很多功能。

 

因此，保持清洁度和速度的折中方案就是保持基础结构的清洁和更新，在细节上尽可能让内容混乱。

技巧3：让代码保持干净状态

 

笔者称之为厕所法则。如果人们使用完的公共浴室（至少）像使用之前的一样干净，那这公共浴室的状态就堪称完美。从大多数公共厕所的状态来看，现实并非如此。维持厕所法则需要所有人遵守纪律——还需要一位优秀的管理者。

 

遵守这样的纪律是值得的，因为从长远来看获得的回报是巨大的。通过完成不可能的事情来实现不可能，这是天方夜谭——做出明智的决定，每天前进一一点点，不可能才会实现。

 

技巧4：为重构分配时间

 

每一次混乱都在产生技术负债。像金融一样，时间越长，产生的债务就越多。

 

对于普通开发人员来说，花上几天甚至几周时间清理代码听上去并不是那么美好。这就是为什么要养成每天偿还一点债务的习惯。

 

一开始可以每天抽出15%的时间进行重构，这是个不错的方法。笔者称之为时间规划，长此以往完善的代码数量将令人惊叹！

技巧5：要求审查

 

有时候，代码出现混乱是因为开发人员不知道该怎么完善。比如，某个代码可能使用了switch语句，但使用映射会容易得多。在这种情况下，高级开发人员的建议至关重要。

 

建立代码审查例程有助于创建反馈环路。这会帮助年轻开发人员改善学习曲线，形成健康的讨论文化。

 

例程是关键，这与厕所法则以及时间规划是一样的。初级开发人员应养成要求审查的习惯，而高级开发人员也应提供建议。理想情况下，审查时间应该是开发团队核心过程的一部分，每次讨论也应总结关键建议。

 

平衡结构与混乱

 

过多的清理会浪费时间和资源，编写草率代码比受到编码器阻碍而完全无法交付要好得多。但同时，草率代码不灵活且难以维护。

 

这五大技巧能帮助你有效清理代码同时节省时间，在混乱和结构之间找到平衡点。

 

快去实践一下吧！