1.物理学是一个非常有意思的学科。无论是经典物理学还是现代物理学，时间在绝大多数的定律里面是双向的，不存在着一个唯一的方向。但是现实经验告诉我们时间只有一个方向，比如说我们可以看到瓶子破碎了，但是却不能看到破碎的瓶子复原。
热力学第二定律是一个特例，热力学第二定律告诉我们一个孤立的系统的熵在不断增加。通俗一点讲，一个孤立系统会越来越混乱。
那么怎么样才能够让系统稳定呢?需要新的低熵的能量。这让我联想到了代码开发。自从香农的信息论出来以后，信息熵的概念也大行其道了。所以代码开发这种纯粹的信息系统，其实也符合热力学第二定律。
2.我在微软工作的时候曾经见过一个微软的合伙人级别的领导。该领导是希腊人，年纪很大，有着看起来特别牛逼的简历。这个领导有一个特点，就是不管下面的人怎么苦苦哀求要做代码重构，他问的***个问题总是，这个代码重构能带来新的功能吗?如果回答是否定的，直接枪毙掉。如果回答是肯定的，第二个问题是这些新功能非要代码重构吗?回答否定的话继续毙掉。如果回答肯定，接下来会问到底有多少的程序是给新功能服务，有多少是在代码重构呢?这个时候如果你的选择是老老实实的说，大部分的程序只是代码重构的话，基本上还是会被毙掉。总结来说只有新功能的投资，不愿意投资代码重构。
这位领导以能deliver闻名，去哪里都可以多快好省的deliver很多的东西。这个领导还有一个特点，从来不在一个坑上待超过三年的。他走以后，很多时候整个队伍就被烂代码给坑了。另外，这个领导有个物理学的博士的学位。所以每次想起他来，我都觉得这个人肯定很懂热力学第二定律，并且知道怎么样去使用热力学第二定律。
3.比较庆幸的一点是，我本人从来没有摊上过这样的领导。如果我们遵循热力学第二定律的话，一个封闭的不维护的系统肯定是会越来越混乱的。为了保持系统的混乱程度不至于太糟糕，以至于无法收拾的话，我们就必须持续投入足够多的新的低熵的东西。这个在代码开发上来讲，就是我们得有人专门去给代码重构，让代码保持有序。
纵观整个IT行业里，对于热力学第二定律掌握的***的恐怕是Google。这从Google从代码写的风格到整个review的过程都可以看得出来。而且我们知道，Google这个公司从很小的时候就一直严格遵循这些原则了。很多人说，这样做会妨碍创新，影响开发速度，那么为什么在Google里面这并没有妨碍创新呢?
对热力学第二定律掌握的很差的，但是公司依然很成功的是亚马逊了。DevOps这种开发模式，让开发人员24小时兼任救火队员。我觉得这个是要对自己的系统的鲁棒性多么的没有信心才能做出来的决定啊。从某种程度上来讲，亚马逊的领导层对自己长期处于高熵状态下运行系统是很有自知之明的。有自知之明其实不是坏事。问题是，为了维系这个高熵系统，亚马逊总是需要牺牲一些人的利益的。这些人，当然是在底层当柴火一样烧着的开发人员了。美其名曰有个名字叫做DevOps。
4.那么作为一个开发人员的你，应该做出什么样的选择呢?是希望让代码长期处于高熵值状态，还是希望代码时刻保持低熵呢?很多时候，这个问题其实不好回答。我想一个低熵值的代码库，如果偶尔需要增加熵值来完成一些商业上需要的东西，这并不难做到。一个高熵值的系统，如果也同样需要再挤进去一些商业上需要的东西，后果是什么，就不可以预料了。
这些道理其实是很简单的，我想没有什么人不能理解。但是为什么在我们的IT行业里，有那么多的人依旧信奉永动机呢?又要马儿跑又要马儿不吃草的好事，只存在于梦里。但是我们的领导们很多时候的确是在追寻又要马儿跑又要马儿不吃草。而有些时候这种状态又被冠冕堂皇的包装在能够deliver啊，或者DevOps的创新啊的光环下面。这样一来，面子上看起来光鲜的东西，里子就未必了。
其实领导当然没有那么傻。但是没有那么傻却依然这样做，大致来说有几种情况。***种是学习路易十四的我死后哪管他洪水滔天的精神。第二种情况是其实是有新的低熵的东西被冠冕堂皇的弄进来的。这就是那个24小时on call的你，你，还有你，这些DevOps们。代码虽然熵值高，架不住那么多的DevOps伺候着啊，所以系统从客户角度看起来，还是很稳定的。这个问题我就不展开了，各位看官，可以自己多脑补一下。
【本文为51CTO专栏作者“徐飞”的原创稿件，转载请通过作者微信公众号“飞总聊IT”获取联系和授权】
