熵是物理学的概念，代表一个系统的混乱程度。一个孤立的系统，会从有序到无序发展。生命体也有这样的现象，从有序到无序，最终走向老化死亡。熵越高的系统就越难精确描述其微观状态。

软件世界的熵增，就是软件系统在没有进行维护、保养、整理的情况下，也会逐渐变得混乱、无序。最后维护不下去了，软件系统走向死亡。

这就要求我们平时的开发，需要主动去抵抗熵增，做到熵减，减速系统老化的过程，为软件系统续命。如果平时开发中，遇到某些软件模块有这样的问题，就可以考虑着手进行重构和优化：

是否已经越难越来理解代码，我只想了解一个功能的实现，却要学习整体的设计？

是否高度耦合，关联模块过多，修改几行代码，却引发和很多其他模块的异常？

是否想简单地删除一个功能，却动到了许多的类，每一处修改就意味着多一份可能产生 bug 的风险。

是否想增加一个需求，却要做大量的修改才能把需求加入，而不是通过扩展的方式。违背了软件开发中的开闭原则，即对扩展支持，对修改限制。

这就像在给一辆老旧的车更换零部件，上润滑油，可以让它多跑几年，做得好的话，整个项目可以在高强度的需求变动下，依然保持优雅。

所以，软件开发就是需要一个熵减的过程，帮助这些模块从混乱到有序。比较常见的处理方式有：

2.1 统一代码规范

统一的命名方式

命名首先要有意义，最好从命名就可以理解代码的作用。大家习惯不一，但在同一个项目需要统一风格。如果大家风格各异，那么每次在阅读代码的时候，都停顿个 0.5s 去理解对方的习惯，那么一个项目几十万行代码，积少成多，量变导致质变，会浪费掉很多时间。最好能够做到，就是项目看起来就像是一个人写的。

整齐的编码方式

这个从另一个维度对代码规范做出要求，那就是排版问题。希望能够有工整、对称的排版。放在类前面的字段功能内聚，或者按作用域内聚。类中的方法也按功能内聚，而不是散乱在各个类中，结果只有通过 IDE 能找到它们的相似方法。就把它当成自己居住的房间吧，是喜欢衣服乱扔的房间，还是干干净净整整齐齐的房间？

清晰的方法设计

各个方法单一职责，使用者只需要关心输入输出，而不用纠结内部实现。实例方法体减少对成员变量的依赖和外部环境的依赖，这样可以便于对方法单元进行测试。

2.2. 清理冗余代码

需求变更，不再使用的代码及时清理

经常使用的代码和算法，抽取成业务工具类。

2.3. 进行解耦和内聚

应用设计模式

应用分层架构

功能内聚

2.4. 进行性能优化

要关注性能优化，这是因为软件运行的硬件环境资源有限。尤其是手机开发更要重视。而性能其实关注的就是一些硬件在现实中的瓶颈，比如

CPU 频率有限，核数有限。

硬盘的 IO 读写慢。

内存大小有限，不能挥霍。

针对这些，就有必要对项目进行优化，比如：

IO优化 

加快数据解析速度

检查发生在主线程的耗时操作

判断是否可以建立缓存减少IO操作，用空间换时间

----泰安软件开发----