[阅读报告]关于软件设计与实现的透明性与可显性

资料名称	Transparency: Let There Be Light
作 者	Eric S.Raymond
作者单位
出 处	The Art of UNIX Programming
阅读时间	2008.12.20~2008.12.25
主要讲述内容
这篇文章介绍了关于软件设计的两个重要的品质： 透明性和可显性。作者首先用通俗的语言定义了这两个性质，并且分别从用户和开发人员的角度阐述了透明性和可显性的重要。 本文用较大的篇幅分析了几个展示透明性和可显性的Unix 设计实例。这些实例包括了audacity 、fetchmail 、GCC 、kmail 、SNG 、Terminfo 、Freeciv 等Unix 软件。在介绍完全部实例后本文尝试从中总结经验，在总结的同时，作者讲述了他的设计方法与理念，如数据文本化、将机制与策略分离、减少抽象层的厚度、模块化编码等。
涉及到的问题
什么是透明性和可显性？ 软件设计为什么要满足透明性和可显性? 为透明性和可显性编码的原则? 怎样在设计时带来透明性和可显性?
作者的观点
作者在文中试图定义透明性和可显性。作者认为透明性是一种被动品质。如果能预测到程序行为的全部或大部分情况，并能建立简单的心理模型，这个程序就是透明的。另一方面，如果软件系统所包含的功能是为了帮助人们对软件建立正确的“做什么、怎样做”的心理模型而设计， 这个软件系统是可显的。 定义了这两个性质之后，文章讲述了软件设计要满足这两个性质的必要性。作者首先从美学的角度说明。软件之美在于其是力量与简洁的结合，这种结合也可以看作是一种优雅(elegance) 。从用户的角度来看，优雅的软件意味着简单直接的GUI 界面，平缓的学习曲线。从软件开发者的角度来看，优雅的代码意味着不仅将算法传达给计算机，同时也把信心和见解传递给阅读代码的人, 优雅的代码也给软件系统带来稳定性和可维护性。 作者在第二节中讲述为透明性和可显性编码的原则，具体包括八条原则： 1 ＞ 程序调用层次中最大的静态深度一般不超过四。 2 ＞ 代码具有强大、明显的不变性质(invariable) ，编码时用前置和后置断言来实现。 3 ＞ API 的函数调用满足正交性和紧凑性。 4 ＞ 存在一些顺手可用的关键数据结构或全局唯一的记录器，捕获了系统的高层级状态。 5 ＞ 数据结构和它们所代表的外部实体之间存在清晰的一对一映射。 6 ＞ 函数和模块简单易懂。 7 ＞ 尽可能减少特殊情况和隐含的冲突。 8 ＞ 代码的魔数( 意义含糊的常量) 太多，限制（如关键缓冲区大小）太明显。 本文在最后几节总结了一些面向透明性和可显性的一些设计方法，主要包括如下几点： 1 ＞ 不要在具体操作的代码上叠放太多的抽象层。 2 ＞ 将数据文本化，这样能使得数据更易读取和维护。 3 ＞ 将数据（策略）和引擎（机制）分离出来，这个观点主要是从Freeciv 软件实例中总结得到。
自我评价
通过阅读这篇文章，理解了软件设计中透明性和可显性的定义和重要性，掌握了评价软件实例的基本方法。
提出的待改进和提高之处
这篇文章虽然提出了一些有价值的观点，但部分表述有一定的局限性。 1 作者在设计时崇尚数据的文本化，但现实中并不是所有的应用都适用这一原则。比如说对实用性要求高的嵌入式应用和网络应用。 2 作者对文中选取的几个软件实例的评价不准确。比如作者推崇audacity 软件的界面，认为其界面清晰自然。查看audacity 软件的截图后，我觉得audacity 的界面布局缺欠美感，功能展示得不明确。 3 文章在总结部分提出了很多观点，但阐述得过于零散，没有条理。
阅读者的观点
经过前面一段时间的努力，今年的项目任务已经基本完成，我想结合自己今年的项目经历，对软件的设计和实现方法进行总结，于是我选择阅读了<<UNIX 编程艺术>> 书中讲述软件设计的这篇文章。 回想起今年的项目经历，这篇文章提出的很多观点得到我的共鸣。比如说数据文本化和策略和机制分离的软件设计方法都在我们的项目中得以体现。在宣武项目中，我们的案例数据统一采用XML 格式以文本的方式组织存储，给开发和维护带来诸多便利。另外，在栗老师上次介绍的工作流软件中，我们正是采用了类似于文中介绍的Freeciv 实例采取了数据（策略）与引擎（机制）分离的方法设计，服务器维持共享状态而客户端专注于GUI 表现，流程的逻辑保存在XML 文件中，在服务器启动时读取。在我设计的数据库模块中，也运用了将数据库基本函数与数据业务逻辑分层的设计方法，但按本文的观点，我的设计有不合理之处，在具体操作的代码上叠放的抽象层太多，以至于我在图像特征提取模块中程序调用层次达到四层，所以我的设计在透明性方面还得继续改进。