1.物理学是一门非常有趣的学科。无论是经典物理学还是现代物理学，时间在大多数定律中都是双向的，没有唯一的方向。但真实的经验告诉我们，时间只有一个方向。例如，我们可以看到瓶子坏了，但我们看不到破瓶子恢复原状。一个特例是热力学第二定律，它告诉我们孤立系统的熵是不断增加的。通俗地说，一个孤立的系统会越来越混乱。那么如何稳定系统呢？需要新的低熵能量。这让我想起了代码开发。自从香农的信息论问世后，信息熵的概念也开始流行起来。所以代码开发，一个纯信息系统，其实是符合热力学第二定律的。2、我在微软工作的时候，曾经遇到过一位微软合伙人级别的领导。领导是希腊人，年纪很大，简历看起来特别牛逼。这个leader有一个特点，就是不管下面的人怎么苦苦哀求代码重构，他问的第一个问题总是，这个代码重构能不能带来新的功能？如果答案是否定的，请立即射杀他。如果答案是肯定的，第二个问题是这些新特性是否需要代码重构？如果答案是否定的，继续杀戮。如果答案是肯定的，那么你会问有多少程序在服务新功能，有多少在代码重构？这时候如果你的选择是老实说，大部分程序只是代码重构，基本上还是会被干掉。总结就是只投资新特性，不愿意投资代码重构。这位领导者以交付能力着称，他走到哪里都能尽可能快速、经济地交付很多东西。这位领导者的另一个特点是，他从未在一个坑里呆过三年。他离开后，整个团队多次被糟糕的代码所欺骗。此外，这位领导者拥有博士学位。在物理学中。所以每次想起他，我就觉得这个人一定懂热力学第二定律，知道如何运用热力学第二定律。3.幸运的是，我从来没有遇到过这样的领导。如果我们遵循热力学第二定律，一个封闭的、无人维护的系统肯定会变得越来越混乱。为了防止系统过于混乱而无法清理，我们必须不断投入足够多的新低熵物质。在代码开发方面，我们需要有人重构代码，让代码保持井然有序。纵观整个IT行业，谷歌可能是最擅长掌握热力学第二定律的。这一点从谷歌的代码编写风格到整个审核流程都能看出来。而且我们知道，谷歌从很小的时候就严格遵守这些原则。很多人说这样做会阻碍创新，影响发展速度，那么为什么这在谷歌不阻碍创新呢？是亚马逊对热力学第二定律的把握很差，但该公司仍然非常成功。DevOps开发模式让开发者24小时充当救火员。我认为这是一个只有在你对你的系统的健壮性没有信心的情况下才能做出的决定。在某种程度上，亚马逊的领导层非常自知，它一直在高熵状态下运行系统。自知之明不是坏事。问题是，为了维持这个高熵系统，亚马逊总是需要牺牲一些人的利益。这些人，当然是在底层烧柴的开发者。它的名字叫做DevOps。4.那么作为开发者，你应该做出怎样的选择呢？你想让代码长期处于高熵状态，还是让代码一直保持低熵状态？很多时候，这个问题其实很难回答。我想象一个低熵的代码库，如果你偶尔需要增加熵来完成一些商业上需要的事情，这并不难做到。如果一个高熵系统也需要挤进去一些商业上需要的东西，后果不堪设想。这些道理其实很简单，我想没有人看不懂。但是为什么在我们IT行业，还有那么多人相信永动机呢？想要马跑马不吃草的好事只存在于梦中。但是很多时候我们的领导确实是在谋求让马跑起来，让马不吃草。有时这种状态被包装在能够交付或DevOps创新的光环之下。这样一来，表面光鲜亮丽的东西，不一定是在里面。其实领导肯定没有那么傻。但是还这么干也不是那么傻。一般来说，有几种情况。首先是学习路易十四的精神。第二种情况是，新的低熵的东西，其实是冠冕堂皇的带进来的。这是24小时待命的你，你，还有你，这些DevOps。虽然代码的熵值很高，但是支持不了那么多DevOps，所以从客户的角度来看，系统还是很稳定的。这个问题我就不展开了，大家可以自己补。【本文为专栏作家“徐飞”原创稿件。转载请通过作者微信联系并授权公众号“费总超IT”】点此查看本作者更多好文
