对于书中提到的一点印象最为深刻, 其实在 《人月神话》也有提到, 那就是:
软件设计与开发的核心就在于 控制复杂度
这句话的核心其实包括几个问题:
软件开发的本质问题性难题是 复杂度 ？
如何可以一定程序的降低复杂度 ？
其中, 书中对于软件设计必须控制复杂度的解释原因是:
没有谁的大脑能容得下一个现代计算机程序, 也就是输, 我们不应该试着在同一时间把整个程序都塞进自己的大脑, 而应该试着以某种方式去组织程序, 以便能在同一个时刻可以专注于一个地方. 这么做的目的是尽量减少同一时间所要考虑的程序量. 你可以把它想做是一种心理上的杂耍(边抛边接: 通过轮流抛接使两个或者两个以上的物体同时保持于空中)- 程序要求你在空中保持的(精神上的)球越多,你就越可能漏掉其中的某一个, 从而导致设计或者编码上的错误
当我读到这一段的时候, 感觉这本书的作者真是说出了软件开发者心中的痛点, 我也认为这段话可以说真本书的一个核心, 其实代码大全的所有部分都是在围绕『如何降低软件开发中的复杂度』. 作者用这种, 杂耍抛球的方式非常形象的比喻了, 我们的大脑（生物结构上）本质的局限性导致的. 曾经美国人有一个非常有名的调查, 人类的大脑短期记忆能够容纳最多的不连续信息数就是5到9
具体可以参考心理学上被引用最多的一篇论文之一:魔数七, 加二或者减二: 人类处理能力的局限性.
而现实问题域中，我们要处理的变量何止是7!
所以我们根本不可能同时让这么多变量一起出现在我们大脑中.
降熵
其实，软件的复杂度从某种意义上, 用物理学第二定律来理解和加强. 物理学第二定律又叫做,熵定律:
自然过程中，一个孤立系统的总混乱度（即“熵”）不会减小。
软件的熵总是倾向于最大化的，程序员们称之为“软件腐烂”。
程序员只有在开发过程中,不断的通过 外部做功(思考, 主动性的思考和改代码), 不断进行代码重构与整理, 通过外部系统注入能量,来降低整个软件系统的熵, 是整个软件达到有序的状态.
为此软件开发行业提出了一些列的原则和指导方法, 重构/单元测试/ 模块化设计/ KISS原则/ 面向接口编程/模式设计/分布式系统… 等等如此,其实你都会发现, 这些方法和指导原则,都是 告诉程序员, 在软件开发的过程中, 通过这些方法降低软件系统整体的复杂度, 以便后期更好的维护与开发. 当软件复杂度可以得到很好的控制，而不是让软件的熵无限的增长, 那么这个软件系统的寿命也就会很长,得到更好的维护性.
所以, 最后, 我们知道:软件开发中的本质难题是 复杂度, 那么我们在之后开发中 应该时刻的主动思考和做功: 如何通过不断的代码重构降低整体的复杂度. 保持我们的代码熵的最小化