https://jackxiang.com/index.php zh-cn https://jackxiang.com/post// jack <xdy108@126.com> Tue, 22 May 2012 05:26:54 +0000 https://jackxiang.com/post//
   在网上找到一个哥们也从这个熵增的角度来描述一个软件系统如何尽量避免熵增，觉得写得有些道理，于是特转些文章！
来源：http://blog.csdn.net/caowenbin/article/details/7308188


     首先我们来了解一下熵增定律，百度百科的描述是：
　　“孤立系统总是趋向于熵增，最终达到熵的最大状态，也就是系统的最混乱无序状态。但是，对开放系统而言，由于它可以将内部能量交换产生的熵增通过向环境释放热量的方式转移，所以开放系统有可能趋向熵减而达到有序状态。”
         “熵增的热力学理论与几率学理论结合，产生形而上的哲学指导意义：事物的混乱程度越高，则其几率越大。”
         通俗点理解就是系统会随着时间的推移变得越来越乱。

         具体到软件系统，随着时间的推移，无论是开发还是维护，都会增加系统的复杂度，越多的代码进入，则越容易造成混乱，软件架构也越容易被破坏。因此，软件架构在设计时就要考虑如何抵制熵增的问题。

         总体而言，我认为可以从四个方面来减少熵增的产生。
         首先，自然是从架构设计本身出发。架构设计中，要充分考虑未来的可变性，将易变部分进行隔离。利用设计原则和架构方法，从软件的整体上把握架构的演化方向，从而提前识别开发和维护对架构的影响。
         其次，架构必须要在团队中取得一致的认识。尤其是技术团队中，任何一名开发人员都应该充分理解软件架构，明确自己的代码在整体中的位置，与其他组件的关系和通讯渠道。无论采用何种开发模型，都不应该因此放弃架构在开发人员认知中的重要性。只有如此，组件开发人员才能在整体架构下进行局部设计，并且能保持架构风格的延续性。否则就易于出现局部结构不符合整体架构，从而引发系统走向混乱。
         再次，设计评审或代码评审也可以有效减少熵增的发生。设计评审是实现之前的预防，代码评审是实现中的质量保证，两者都可以对架构的一致性起到保证作用，而且在具体的实现中可以反作用于架构的调整，是架构师、技术经理经常采用的管理方法。
         最后，就是主动调整架构。架构师不可能预测未来，当变化来临时，要主动的调整架构以适应变化，而不是被动的迁就，靠代码技巧来应对变化。那样的话，就已经从架构上主动进行了熵增，是混乱之源。

         以上四个方面，虽然无法完全抵制熵增，但至少可以减少熵增，值得在架构设计和软件开发中进行足够的重视。

]]> https://jackxiang.com/post//#blogcomment <user@domain.com> Thu, 01 Jan 1970 00:00:00 +0000 https://jackxiang.com/post//#blogcomment