论代码之熵
前言：
本文为2013年3月写的一篇文章。现在看还是有意义的，所以转载到这里。几十年前的《人月神话》中说的焦油坑，现在还在不断的重复出现。
原文：
1850年，德国物理学家鲁道夫克劳修斯首次提出熵的概念，用来表示任何一种能量在空间中分布的均匀程度，能量分布的越均匀，熵就越大。在克劳修斯看来，在一个系统中，如果听任它自然发展，那么能量差总是倾向于消除。
以上所说的熵的定义可能让大家有点不知所谓。其实代码的混乱程度可以认为是一种熵。代码某一处在书写过程中没有清晰的层次，代码的简洁度不够。会影响周边的代码趋向于混乱。
如果做一件事情总喜欢绕过来绕过去然后再以别扭的处理方式处理整件事情。往往这类代码会出更多的问题。因为如果每千行代码平均出50个BUG，那么实现同样的功能混乱代码所用的行数远超过结构清晰的代码。所以，代码多，BUG就会多。最好的代码就是清晰代码结构降低代码量。
举个栗子：
把货物放到该位置（货物，位置）
{
将货物从仓库门口搬到位置
把货物放进去位置
看看有没有空位
将货物信息提交到仓库记录中
}
存储货物(货物)
{
位置 = 找个适合货物的位置（货物）
看看临时仓库上有没有位置
看看临时仓库上都是什么货物
把货物放到该位置（货物，位置）
获取放到临时仓库上了吗？
这个货位上都存了什么货物？
}
这只是一个简单的例子，突出了结构混乱代码。其实在现实中比例子里面的混乱程度更甚的代码者比比皆是的。写这样代码的人，能说他办错了事吗？不能，因为程序把该做的事情都做了。而且还需要鼓励这些程序员，因为他们再最快的时间内为你出了功能，满足了系统上线、Bug修复等等问题。
那在这种情况下怎么进行代码维护？ 怎么保证系统的可用性？怎么在团队间进行知识传递？
从各种角度思考后，你会发现没有任何一种方法能够约束程序员写出直截了当，结构清晰的程序。所以，程序员写代码的时候除了“高压线”不敢碰，剩下的什么都敢做。对于要求一个程序员自觉的学习逻辑学，并系统化的认识整个项目、对系统架构有完整理解再去写代码是几乎是不可能的。 更不用提优雅的处理整个过程。
问题后果：
-
不断地传染其他代码：
我们在分析一下这种类型的代码会带来的后果。根据熵的方式，这种代码会传遍整个项目。例如：我现在要维护这段代码。需要新加一个将货物通过某种方式可以移动到仓库门口的方法也记录到仓库记录中。
- 我需要先读懂这段代码。因为代码结构问题，读懂代码是比较费筋的。花了很大功夫读懂代码后发现其实功能很简单。
- 了解了代码的处理过程后，就是确定修改位置。由于各种原因（主要是不愿意承担由于修改代码结构造成故障的责任）是不会修改原有代码的结果的。也就是前例中应该将“将货物信息提交到仓库记录中”这个处理过程移动到“存储货物”的处理中。然后就会修改成：
把货物放到该位置（货物，位置）
{
将货物从仓库门口搬到位置
把货物放进去位置
《do something》
看看有没有空位
将货物信息提交到仓库记录中
}
- 将代码添加到上一步确定的位置。
通过以上三步的维护过程，可以看到一个开发过程的缩影。在实际的项目开发与维护阶段进行着一遍遍重复着，随着这一遍一遍的重复代码就会陷入了无休止的混乱中。说句不好听的最终这些代码只能按坨算，一坨根本没有层次，混乱的代码。好多年前有一个高人除了一本叫做《人月神话》的书，里面描述的焦油坑真是异曲同工。
-
伴随着混乱上线：
对项目的业务处理过程思路不清晰导致代码多，代码多就BUG多。但是，上线时间、交付计划等都会是Deadline。各种各样的计划在催促着尽快上线，尽快抢占市场。所以，在某种妥协下系统就会带着这些代码上线。
这些代码都出现在模块内部。因为在模块间有强制性的接口约束。所以模块间关系还是比较清晰的，但是在多次添加新功能后模块间也会出现关系混乱的情况。比如在项目中要新加一个功能，其中A模块可以将消息M发送给B模块或者C模块，在架构的层次结构中是ABC，就有架构不清晰的程序员，三个负责人商量后，A直接将消息M发送给C。原因是B收到消息后不做操作直接传给C。这样更好就可以一月省个好几万去请架构师了。
总结：
再结合软件过程说说混乱代码必定会出现在发布版本中的原因：
- 大家习惯在没有详细设计的情况下写代码，然后再从代码推导出详细设计。也就是说写代码的人根本就没有想过那些处理可以归类到一起，那些纯粹就不是一类。
- 写完代码之后不管是组织review还是同行评审。那个会提出代码结构有问题。不提出代码结构问题的原因有1.以一句没时间改结构为由拒绝了这个建议。2.他还在为他那一坨混乱代码发愁呢。还想不要被你提出代码结构有问题要他改结构呢。
- 客户 and 领导要的只不过就是一个可以完成任务并且少出bug的代码，没人会花费时间去重构。
- 对项目的业务处理过程思路不清晰导致代码多，代码多就BUG多，BUG多的人就得天天加班。加班多就被领导看见的多，领导看见多就认为BUG多的人勤劳，然后就BUG多的人就加薪升值了。然后思路清晰的就被催了。然后思路清晰的就会向“该”发展的方向发展。然后所有的人都会向着BUG满天飞的境界去努力。这样必然形成恶性循环。
综上，说明了混乱代码的出现原因，以及它是必然出现的原因。结果就是陷入混乱代码的泥沼，无法自拔。因为时间都被修复混乱代码带来BUG全部沾满。没有时间思考，学习，休息。
提出解决办法以供参考：
- 程序员必须学习设计模式，有助于代码结构清晰。
- 先写设计（哪怕只有一页纸），然后编码。让你想清楚每一步该怎么做之后再去做。也可以边写设计边写代码。如果没有设计就写代码，那就需要想清楚模块的输入是什么，输出是什么，处理过程是什么。将它们各自封成不同的函数，然后再一个函数内调用这三个函数。这样就清晰的告诉读代码的人，你的过程是什么样的。
- 进行公司文化导向。奖励做出高质量review的人，而不是处罚写错代码的人。这样会鼓励做review的人，并形成一种对立关系。只有有了对立关系才能形成高质量的产品。
