模块性：保持清晰，保持简洁

软件设计有两种方式：一种是设计得极为简洁，没有看得到的缺陷；另一种是设计得极为复杂，有缺陷也看不出来。第一种方式的难度要大得多。

模块化代码的首要特质就是封装， 养成在编码前为 模块的最佳大小，逻辑行 紧凑性就是一个设计能否装入人脑中的特性。测试软件紧凑性的一个简单方法是：一个有经验的用户通常需要用户手册吗不需要，那么这个设计是紧凑的。

理解紧凑性可以从它的“反面”来理解，紧凑性不等于“薄弱”，如果一个设计构建在易于理解且利于组合的抽象概念上，则 这个系统能在具有非常强大、灵活的功能的同时保持紧凑。紧凑也不等同于“容易学习”：对于某些紧凑 设计而言，在掌握其精妙的内在基础概念模型之前，要理解这个设计相当困难；但一旦理解了这个概念模型，整个视角就会改变，紧凑的奥妙也就十分简单了。紧凑也不意味着“小巧”。即使一个设计良好的系统，对有经验的用户来说没什么特异之处、“一眼”就能看懂，但仍然可能包含很多部分。

评测一个 重构技术中的很多坏味道，特别是重复代码，是违反正交性的明显例子，“重构的原则性目标就是提高正交性”。

要提高设计的紧凑性，有一个精妙但强大的方法，就是围绕“解决一个定义明确的问题”的强核心算法组织设计，避免臆断和捏造，将任务的核心形式化，建立明确的模型。

文本化：好协议产生好实践

数据文件元格式：

使用分隔符来分隔值，例如 适合场景：数据为列表，名称（首个字段）为关键字，而且记录通常很短（小于 互联 电子邮件信息采用的文本格式，使用属性名 适合场景：任何带属性的或者与电子邮件类似的信息，非常适合具有不同字段集合而字段中数据层次又扁平的记录。

适合场景：词以上结构没有自然顺序，而且结构不易区别的文本段，或适用于搜索关键字而不是文本上下文的文本段。

这样的格式。

适合场景：那些类似 这样的格式

适合场景：数据围绕指定的记录或部分能够自然分成“名称 应用协议元格式

透明性：来点光

美在计算科学中的地位，要比在其他任何技术中的地位都重要，因为软件是太复杂了。美是抵御复杂的终极武器。

如果没有阴暗的角落和隐藏的深度，软件系统就是透明的。透明性是一种被动品质。如果实际上能预测到程序行为的全部或大部分情况，并能建立简单的心理模型，这个程序就是透明的，因为可以看透机器究竟在干什么。

如果软件系统所包含的功能是为了帮助人们对软件建立正确的“做什么、怎样做”的心理模型而设计，这个软件系统就是可显的。

不要让调试工具仅仅成为一种事后追加或者用过就束之高阁的东西。它们是通往代码的窗口：不要只在墙上凿出粗糙的洞，要修整这些洞并装上窗。如果打算让代码一直可被维护，就始终必须让光照进去。例如 在“这个设计能行吗strong>”之后要提出的头几个问题就是“别人能读懂这个设计吗 要追求代码的透明性，最有效的方法是很简单，就是不要在具体操作的代码上叠放太多的抽象层。

所有的 胶合层中的“智能数据”却经常不代表任何程序处理的自然实体——仅仅只是胶合物而已（典型现象就是抽象类和混入 太多的 为透明性和可显性而编码：

隐藏细节和无法访问细节有着重要区别。不要过度保护。