到这里，我们理想的应用程序的轮廓应该很清楚了。应用程序应该基于无绪原则来开发，尽量让最终负责集成的相关人员不需要深入了解系统也可以把集成工作做好。所以，我们理想的应用程序应该基于模块化架构来开发，可以由散布在世界各地的独立开发团队分别负责编写相应的模块。他们可以按照自己的日程来安排工作，以达到最终的目标。但这种做法却存在一个重要的问题，那就是模块间的关联关系。
大多数模块并不能孤立存在，它们要依赖于其他模块提供的环境。只有少数模块才可能完全不依赖其他模块而独立对外提供功能。实际上，大部分模块化的组件都需要其他组件为其提供服务。这就意味着这些模块的开发人员需要去发现和了解如何使用外部模块提供的API。而这样的模块也是由其他的开发人员编写的，所以还会出现一个隐藏的问题，即该模块又依赖于另外的模块。
API不是给计算机用的
我花了很长的时间才明白，API的第一受众并不是计算机，其实是人，是我们这些开发人员，这恰恰与我最初的想法相反。可以设想一下，对一个编译好的程序来说，它的第一受众或者说唯一用户就是计算机，编写好的代码是用来编译和执行的，所以可以把程序看作是人类和计算机沟通的一种方式。
但这个想法对API来说并不正确。要知道，API中往往包含了大量的内容，还有相应的说明文档，其实对于要运行程序的计算机来说根本不需要这些东西。在我认识到这一点后，我发现从学校里学到的那些编码技巧其实并不足以教导我来设计API。API的设计与这些技巧简直风马牛不相及。从来没有人教过我如何设计API，我估计其他程序员也没有受过这方面的专业教育。
共享功能库和不同框架的作者需要和他们的用户进行交流。他们还可能需要与那些无意中①使用了他们库的用户进行沟通。交流的方式有很多，比如说可能通过电子邮件，或者参与电话会议之类的方式，但这些方式都需要面对面或者耳对耳地进行交互才行。所以最常用的方式还是通过API自身以及相关的文档。API的用户在开发过程中研究最多的肯定是API的文档。如果想成功且高效地开发模块化应用程序，就需要有清楚、易于理解的说明文档，而且API自身也尽量可以自描述。这样做有助于开发人员完成各自的工作，无论他们身在何处。
API应该建立在普遍适用的基础知识上，这样其用户可以很容易理解接受该API。如果API是可靠的，它就必须能避免用户误用，而且可以在未来被加以改进：要知道很少有哪个API在第一个版本就能做到完美。本书中讨论的问题，大部分都与如何避免错误有关，只有避免了相应的错误，才可能让API在未来得以改进。
最重要的方式就是分解（separation）。要做到分解，就需要为设计和维护API制定相应的规则。如果不能分解，那么整个产品就是紧耦合的，一旦这个程序被开发完成后，也就不需要对外提供一个API了。但是，现实世界中的产品开发，往往是以模块化的方式进行的，可以让分散的团队基于这样的组件架构来开发产品，各个团队完全可以根据独立的时间表来开发自己的项目，当然这样做的前提就是需要有一个稳定的契约，来保证这种沟通的有效性。
并非所有项目的质量都要高得像API
前段时间我同表哥聊了一些我们工作上的内容，说到我们所做的项目，以及我们如何组织和管理这些项目。我给他介绍了无绪这一概念，并说到如果能够做到针对性无绪的话，就能开发出更可靠的软件系统。虽然他和我的观点还是有少许的不同，但在大部分内容上，我们还是取得了一致。
有时，特别是开发的应用程序是给最终用户②使用时，代码质量似乎没有必要像API的代码质量那么高。对于这样的系统，其用户只有人，而人与自动化系统相比，是可以容忍一定错误的。而且在应用程序部署完成后，都不会有什么大的变化。它会持续运行多年，直到确有必要时，它才会被另外一个程序来替代，而这个替代的程序是完全可以被重写，或者重新组装而成的。
这与使用API来编写一个模块是完全不同的。这样的应用程序就像恒星一样，会始终存在，不会轻易地被新软件替代。这也说明，本书中给出的各种原则，并不适用于所有的项目，它们更适用于系统中的那些关键的可复用组件。而对于其他非核心的功能模块来说，则完全不用去担心未来的情况，它们的开发过程完全可以适用“开发一次，然后弃之不管”的软件方法论③。
然而，这些外围的功能通常都是围绕一个核心组件建立的，这个组件才是整个系统的灵魂所在。这样的组件是本书的关注点，应该基于API设计的最佳实践来开发这样的组件。事实上，我的表哥也承认他所开发的系统中同样存在一个核心库，必须正确地设计和开发这个核心库，才能保证程序能正常运行很多年。
① 这里所说的无意中，是指某个程序员使用了某个模块，然后该模块又使用了另外的模块，所以程序员也必须使用另外的模块，但这个程序员可能没有意识到这一点，这种是不自觉使用，也可以说是被强迫使用。——译者注
② 这里的最终用户就是指最后使用软件的人。——译者注
③ 这里的意思是指，开发此类复用性不强的软件时（如某个财务系统），只需要将注意力集中在核心组件上，如数据库、算法等，这些内容要考虑复用，而提供交互的用户界面，则不用太关心。——译者注
大多数模块并不能孤立存在，它们要依赖于其他模块提供的环境。只有少数模块才可能完全不依赖其他模块而独立对外提供功能。实际上，大部分模块化的组件都需要其他组件为其提供服务。这就意味着这些模块的开发人员需要去发现和了解如何使用外部模块提供的API。而这样的模块也是由其他的开发人员编写的，所以还会出现一个隐藏的问题，即该模块又依赖于另外的模块。
API不是给计算机用的
我花了很长的时间才明白，API的第一受众并不是计算机，其实是人，是我们这些开发人员，这恰恰与我最初的想法相反。可以设想一下，对一个编译好的程序来说，它的第一受众或者说唯一用户就是计算机，编写好的代码是用来编译和执行的，所以可以把程序看作是人类和计算机沟通的一种方式。
但这个想法对API来说并不正确。要知道，API中往往包含了大量的内容，还有相应的说明文档，其实对于要运行程序的计算机来说根本不需要这些东西。在我认识到这一点后，我发现从学校里学到的那些编码技巧其实并不足以教导我来设计API。API的设计与这些技巧简直风马牛不相及。从来没有人教过我如何设计API，我估计其他程序员也没有受过这方面的专业教育。
共享功能库和不同框架的作者需要和他们的用户进行交流。他们还可能需要与那些无意中①使用了他们库的用户进行沟通。交流的方式有很多，比如说可能通过电子邮件，或者参与电话会议之类的方式，但这些方式都需要面对面或者耳对耳地进行交互才行。所以最常用的方式还是通过API自身以及相关的文档。API的用户在开发过程中研究最多的肯定是API的文档。如果想成功且高效地开发模块化应用程序，就需要有清楚、易于理解的说明文档，而且API自身也尽量可以自描述。这样做有助于开发人员完成各自的工作，无论他们身在何处。
API应该建立在普遍适用的基础知识上，这样其用户可以很容易理解接受该API。如果API是可靠的，它就必须能避免用户误用，而且可以在未来被加以改进：要知道很少有哪个API在第一个版本就能做到完美。本书中讨论的问题，大部分都与如何避免错误有关，只有避免了相应的错误，才可能让API在未来得以改进。
最重要的方式就是分解（separation）。要做到分解，就需要为设计和维护API制定相应的规则。如果不能分解，那么整个产品就是紧耦合的，一旦这个程序被开发完成后，也就不需要对外提供一个API了。但是，现实世界中的产品开发，往往是以模块化的方式进行的，可以让分散的团队基于这样的组件架构来开发产品，各个团队完全可以根据独立的时间表来开发自己的项目，当然这样做的前提就是需要有一个稳定的契约，来保证这种沟通的有效性。
并非所有项目的质量都要高得像API
前段时间我同表哥聊了一些我们工作上的内容，说到我们所做的项目，以及我们如何组织和管理这些项目。我给他介绍了无绪这一概念，并说到如果能够做到针对性无绪的话，就能开发出更可靠的软件系统。虽然他和我的观点还是有少许的不同，但在大部分内容上，我们还是取得了一致。
有时，特别是开发的应用程序是给最终用户②使用时，代码质量似乎没有必要像API的代码质量那么高。对于这样的系统，其用户只有人，而人与自动化系统相比，是可以容忍一定错误的。而且在应用程序部署完成后，都不会有什么大的变化。它会持续运行多年，直到确有必要时，它才会被另外一个程序来替代，而这个替代的程序是完全可以被重写，或者重新组装而成的。
这与使用API来编写一个模块是完全不同的。这样的应用程序就像恒星一样，会始终存在，不会轻易地被新软件替代。这也说明，本书中给出的各种原则，并不适用于所有的项目，它们更适用于系统中的那些关键的可复用组件。而对于其他非核心的功能模块来说，则完全不用去担心未来的情况，它们的开发过程完全可以适用“开发一次，然后弃之不管”的软件方法论③。
然而，这些外围的功能通常都是围绕一个核心组件建立的，这个组件才是整个系统的灵魂所在。这样的组件是本书的关注点，应该基于API设计的最佳实践来开发这样的组件。事实上，我的表哥也承认他所开发的系统中同样存在一个核心库，必须正确地设计和开发这个核心库，才能保证程序能正常运行很多年。
① 这里所说的无意中，是指某个程序员使用了某个模块，然后该模块又使用了另外的模块，所以程序员也必须使用另外的模块，但这个程序员可能没有意识到这一点，这种是不自觉使用，也可以说是被强迫使用。——译者注
② 这里的最终用户就是指最后使用软件的人。——译者注
③ 这里的意思是指，开发此类复用性不强的软件时（如某个财务系统），只需要将注意力集中在核心组件上，如数据库、算法等，这些内容要考虑复用，而提供交互的用户界面，则不用太关心。——译者注