『埃尔法哥哥』为什么你写的代码别人看不懂？( 二 ) 好的事物都是在结构和混乱的健康平衡中

如果你更喜欢快速修复而不是解决潜在的问题，没关系，这样的人很多。人类的奖励系统更容易受到短期修正而不是长期变化的影响。但这样一来，我们就欠下了“技术债” 。从长远来看，这会让我们付出更多代价。
整洁vs混乱的危险
声称自己总是编写整洁代码的开发人员要么是撒谎，要么是高估了自己。也就是说，我们不想编写太整洁的代码是有原因的：
如果你的目标是从头开始编写整洁的代码，那么你就增加了CoderBlock的风险。为了避免主要的Block发生，最好是在一开始时就有机地增加代码。这尤其适用于初学者。
一些开发人员会花一整天的时间来清理他们的代码，只是为了美观，而没有其他原因。当然，如果还有很多其他协作者，或者代码可以以任何一种方式来呈现，这都是无可厚非的。但通常情况下，润色代码的效果就像一般的医疗整形手术一样——可能看起来很不错，但并不解决任何更深层次的问题。
另一方面，我们也不希望代码太混乱。太混乱会使我们的代码无法维护。缺乏维护会导致代码“腐烂” ，从长远来看，项目将会被丢弃，因为它们的弊大于利。
因此，我们需要的是在快速拿结果和代码可维护性之间维持健康的平衡。大多数开发人员都会陷入代码混乱的困境，所以提高整洁度才是解决之道。好消息是，一些好的习惯可以对开发人员的代码整洁度和生产力产生巨大的影响。

文章图片
技巧1：尽早进行测试并提高测试频度
一些开发人员对他们的技术非常有信心，以至于他们在不运行任何测试的情况下就构建完了整个项目。但是，除非手头的任务是完全无关紧要，否则只会适得其反。
当他们尝试编译或执行程序时，屏幕上就会充满各种错误消息。或者，更糟糕的是，直到几个月后，当用户意识到程序没有按照预期运行时，错误才会被发现。
这些都是不好的做法。如果在技术部门工作可以教会我们什么的话，那应该是：
如果你没有对所有场景进行测试，就永远不要假设某些东西能像预期的那样运行。
尽可能快速地构建一些可执行的代码。即使它非常非常的简单。一有机会就测试一下它。这样你就可以在错误构建完之后能立即修复它们了。
技巧2：结构良好但格式混乱
只要代码的底层结构是好的，追求快速修复也是可以的。但实际情况是，开发人员试图在混乱或过时的代码结构中实现快速修复。
在这种情况下，最好花时间重构代码。如果需要修复的代码没有正确的注释，或者变量命名词不达意，那也不是没得救。但是，试图在充满bug的代码中构建一个干净的特性却是浪费时间和资源的，不管怎么样，我们可能需要重写很多其他特性。
因此，在代码整洁度和速度之间进行选择的一个很好的折衷方案是保持底层结构的整洁和更新，但在细节上可以容忍混乱。

文章图片
把“恶魔”留在细节，图片来自Unsplash由AlvaroReyes上传
技巧3：为重构分配时间
每次你搞得一团糟，你都是在制造技术债。就像货币债一样，你借贷的时间越长，它的成本就越高。
另一方面，花上几天甚至几周的时间来清理代码，对一般的开发人员来说，并不能受到鼓舞。这就是为什么建立一个每天都能还一点债务的习惯是非常有用的。
一个好的开始方法是每天花费15%的时间来进行重构。我称之为时间规则。你会为你能改进的代码量感到惊讶的！
技巧4：留下比你发现时更整洁的代码
我把这叫做“厕所规则” 。如果每个人在离开公厕时，公厕至少要和他们进入时一样干净，那么他们将会处于无可挑剔的状态。