论代码之熵

1850年，德国物理学家鲁道夫克劳修斯首次提出熵的概念，用来表示任何一种能量在空间 
中分布的均匀程度，能量分布的越均匀，熵就越大。在克劳修斯看来，在一个系统中，如果 
听任它自然发展，那么能量差总是倾向于消除。 

以上所说的熵的定义可能让大家有点不知所谓。其实代码的混乱程度可以认为是一种熵。代 
码某一处在书写过程中没有清晰的层次，代码的简洁度不够。会影响周边的代码趋向于混乱。 
如果做一件事情总喜欢绕过来绕过去然后再以别扭的处理方式处理整件事情。往往这类代码 
会出更多的问题。因为如果每千行代码平均出50个BUG，那么实现同样的功能混乱代码所用 
的行数远超过结构清晰的代码。所以，代码多，BUG就会多。最好的代码就是清晰代码结构 
降低代码量。 

举个混乱代码的例子： 
把货物放到该位置（货物，位置） 
{ 
    将货物从仓库门口搬到位置 
    将货物信息提交到仓库记录中 
} 

存储货物(货物) 
{ 
    位置 = 找个适合货物的位置（货物） 
    把货物放到该位置（货物，位置） 
} 
  
这只是一个简单的例子，突出了结构混乱代码。其实在现实的代码中比例子更甚者比比皆是 
的。写这样代码的人，能说他办错了事吗？不能，因为程序把该做的事情都做了。然后就 
Good Job。但是，代码怎么样？代码的可读性，可维护性怎么样？ 

没有任何一种约束能够约束程序员写出直截了当，结构清晰的程序。所以，程序员写代码的 
时候除了“高压线”不敢碰，剩下的什么都敢做。要凭自觉以及对整个项目的架构的理解才能 
优雅的处理整个过程，几乎是不可能的。 

这种代码带来的问题是很严重的。根据熵的方式，这种代码会传遍整个项目。例如：我现在 
要维护这段代码。需要新加一个将货物通过某种方式可以移动到仓库门口的方法也记录到仓 
库记录中。 
第一步.我需要先读懂这段代码。因为代码结构问题，读懂代码是比较费筋的。花了很大功 
       夫读懂代码后发现其实功能很简单。 
第二步.了解了代码的处理过程后，就是确定修改位置。由于各种原因（主要是不愿意承担 
       由于修改代码结构造成故障的责任）是不会修改原有代码的结果的。也就是前例中 
       应该将“将货物信息提交到仓库记录中”这个处理过程移动到“存储货物”的处理中。 
       然后就会修改成： 
把货物放到该位置（货物，位置） 
{ 
    将货物从仓库门口搬到位置 
    《do something》 
    将货物信息提交到仓库记录中 
} 
第三步.将代码添加到上一步确定的位置。 

通过以上三步的维护过程，可以看到一个开发过程的缩影。一遍遍的重复着以上的动作代 
码就陷入了无休止的混乱中。说句不好听的最终这些代码只能按坨算，一坨根本没有层次， 
混乱的代码。 

如果说可以通过松耦合强内聚来解决这个问题，没错，可以我绝对支持。但这些代码都出现 
在模块内部。因为在模块间有强制性的接口约束。所以模块间关系还是比较清晰的，但是在 
多次添加新功能后模块间也会出现关系混乱的情况。比如在项目中要新加一个功能，其中A 
模块可以将消息M发送给B模块或者C模块，在架构的层次结构中是ABC，就有架构不清晰的程 
序员，三个负责人商量后，A直接将消息M发送给C。原因是B收到消息后不做操作直接传给C。 
这样更好就可以一月省个好几万去请架构师了。 
再结合软件过程说说混乱代码必定会出现在发布版本中的原因： 
1.大家习惯在没有详细设计的情况下写代码，然后再从代码推导出详细设计。也就是说写代 
  码的人根本就没有想过那些处理可以归类到一起，那些纯粹就不是一类。 
2.写完代码之后不管是组织review还是同行评审。那个会提出代码结构有问题。不提出代码 
  结构问题的原因有1.以一句没时间改结构为由拒绝了这个建议。2.他还在为他那一坨混乱 
  代码发愁呢。还想不要被你提出代码结构有问题要他改结构呢。 
3.客户 and 领导要的只不过就是一个可以完成任务并且少出bug的代码，没人会花费时间去 
  重构。 
4.对项目的业务处理过程思路不清晰导致代码多，代码多就BUG多，BUG多的人就得天天加 
  班。加班多就被领导看见的多，领导看见多就认为BUG多的人勤劳，然后就BUG多的人就加 
  薪升值了。然后思路清晰的就被催了。然后思路清晰的就会向“该”发展的方向发展。然后 
  所有的人都会向着BUG满天飞的境界去努力。这样必然形成恶性循环。 
  
综上，说明了混乱代码的出现原因，以及它是必然出现的原因。结果就是陷入混乱代码的泥 
沼，无法自拔。因为时间都被修复混乱代码带来BUG全部沾满。没有时间思考，学习，休息。 

提出几个解决办法以供参考： 
1.程序员必须学习设计模式，有助于代码结构清晰。 
2.先写设计（哪怕只有一页纸），然后编码。让你想清楚每一步该怎么做之后再去做。也可 
  以边写设计边写代码。 
3.如果没有设计就写代码，那就需要想清楚模块的输入是什么，输出是什么，处理过程是什 
  么。将它们各自封成不同的函数，然后再一个函数内调用这三个函数。这样就清晰的告诉 
  读代码的人，你的过程是什么样的。 
4.奖励做出高质量review的人，而不是处罚写错代码的人。这样会鼓励做review的人，并形 
  成一种对立关系。只有有了对立关系才能形成高质量的产品。