在开发中与别人交流或在程序员社区中，经常会有关于烂代码的讨论，并且为其起了一个打趣的名字”屎山“。

仅从名字上也不难看出，大家对于这种代码是十分的厌恶的。其实随着需求的变化和增加，项目不可避免的会变的混乱，在物理学里有个名词叫“熵增”。

熵增过程是一个自发的由有序向无序发展的过程

既然代码会膨胀，并且会变得混乱，如何做能够尽量的避免这种情况的发生呢？

核心办法就是主动做功，在规划、实施、复盘等各个阶段有意的去做治理，从而避免代码的混乱。

勾勒整体

在需求开发之前，要建立对需求的整体的认识，从整体拆分细节，从细节着手开发。这么做的主要目的就是对需求有一个全局的规划，确定需求边界，就不会再开发的时候迷失方向，导致整个需求的实现变得混乱，代码和思想都没有清晰的表达。

在整体确定，边界清晰的时候，还需要考虑一点：当前需求与已有功能的关系时怎么样的，如何能花费更小的成本将新增需求融入现有系统。

完成上面说的还有一步就是追问，此方案是否为最优方案，是否还存在更为简化更易于理解的放啊的方案，如果回答全部为是，那么关于整体这部分的考量也就到此结束了。

化繁为简

我对专业的定义是：可以将自己领域的复杂问题简单化的能力。把简单的事情做复杂是庸才，把复杂的事情做复杂是通才，把复杂的事情做简单是天才。

在程序开发中，以易读为第一要务。写代码的主要目的是给人阅读，其次才是机器执行。在开发中，应该以代码的可读性为最高优先级，其次才是性能或其他指标。

大道至简，做到简不容易，需要通过不断的练习与反思，才能窥其门径。

好的程序设计应该是立足业务的基础上长出来的，在业务不是很明朗的时候，应该更专注于方案和代码的简单而不是过度设计。

业务不明朗的时候大多数的设计是无用的而且一些设计会带来代码复杂读的增加，虽然可以美其名余曰有更好的扩展性，没有用的扩展性等于没有扩展性。

好的设计应该是以对业务有深入理解后，通过重构的手段展现出来的，而不是在业务一开始就过分的考虑设计。

重构的时机有三种：

重构不应该等”有时间“的时候，”有时间“就等于没有时间。重构应该发生在发现问题的时候，发现问题就解决问题。

就像打扫卫生一样，每发现一个地方乱了，就顺手整理一下，虽然没有刻意的花时间去进行整理，但是整个房间依然会保持整洁。

应该缩小重构的粒度，增加重构的频率，使重构变得小而频繁。

除了上述说的情况之外，保持学习也是很关键。思而不学则殆，通过学习他人项目治理的思想，来增加自身的理解，并在开发中不断的去验证、思考和改进，从而写出更简洁高效的代码。

纸上得来终觉浅，绝知此事要躬行。学习只能是觉知，关键在于实践，知行结合，才是真正把知识内化为己所用。希望本文能对你有所帮助，个人观点难免会有疏漏和偏颇，如果有不同观点，欢迎留言讨论。