你对API和依赖关系做好规划了吗？

不知道大家如何认为的，一个编译好的组件，或者模块，仅仅是给其他程序调用使用的吗？这个不是这个问题的本质面，

我认为是这个API或者模块是给人设计的，一般而言，每一个组件或者模块都包含很多文档（也可能是XML注释的形式出现），真至于作者还是写了Demo，但是很多方面，人们并没有按照读者的角度来或者说没有按照API是人在使用的观点来组织这些说明性文件，想当然地会加入很多阅读者不可以理解的部分或者不需要暴露给读者的部分，或者这个API设计的很难理解和使用，毕竟最终需要人把这个模块整合到系统中的，也就是说其他模块会引用它，或者它引用其他模块。更加普遍的事情则是，没有描述清楚模块之间或者模块对外部程序的版本依赖，也没有提供测试这些依赖关系的tool，照成的结果是，如果一个模块依赖于一个版本>3.0 的XML paser,而读者并没有得到明确的指示，而安装了<3.0的版本，那么这个模块一部分功能受到影响，而糟糕的是，这个模块在系统加载了，引用它的所有模块潜在地受到了低版本XML parser的影响，系统的在一些功能上可以是“不完备”的状态！在模块很多，比如好几千个，即使上百个的话，没有一个明确的依赖关系（版本）的检查，

系统的稳定性和可信性将受到使用者的质疑！如果有一个这个版本检查机制，那么系统就不会加载可能存在潜在危险的模块，这样也就挽救了系统，也能给予用户提示（提示它们尽快更新这个依赖），还可以在系统加载的时候，检查版本时，发现被依赖的模块不存在或者版本不满足要求，检查工具可以自动到网络下载相应的版本！为应用的完备性提供了保障！

 

所以，在设计之初，就应该考虑到，我们在设计一个API或者模块或者框架的时候，应该考虑的是，在使用者无需知道更多细节的情况下就能部署或者使用它，并且提供完备的可以理解的为人类阅读的文档，也需要提供一个完备版本控制机制和检查工具！在明确这样的情况下，每一个模块甚至于可以由每个独立的小组或者分布式的小组完成，因为它们有明确的依赖关系、管理以及检查工具，这也为开发带来了便利。

 

以上实际上是谈论了两个问题：如何才是好的API，以及依赖版本的管理必要性。

 

对于，要设计好的API，我们可以使用经验型设计的方式，也就是说，如果一个使用者“使用”它最低的经验就能容易地使用我们的组件，并且可以轻易地满足各种情况，那么这个API至少就是好的，对于使用者而言，他们甚至于可以不去看文档就可以轻易使用这些组件，即使它们能够“乱序”的使用！这些对设计API的人提出更高的要求，因为必须考虑得很“周全”，而且做到“简单就好”，往往对设计人和开发者有更多的挑战！所以往往达不到理想的状态，但是至少核心的组件，应该能做到这样的要求，因为越是复用性强的组件，越是很容易被别的组织拿去用！那么可以将主要精力放在这些东西上！其他的部分，视情况而定！

 

对于好的依赖管理：最好的方式是让tool去检查，开发时让一个集中版本控制机制进行管理，另外可能大多数人会认为往往第一个版本的是容易的，但是事实并非如此，依赖除了版本依赖，还有一个兼容性的依赖关系:

没有开发人员会使用API总在变化的组件或者模块，因为需求的变化，我们往往要升级组件，这会带来问题，

第一：可能API变化，不兼容现有的客户程序了，那么使用它的组织会很恼火！因为他们不得不配合这个组件做对自己产品的变更，成本会比较高！之后就没有任何一个人使用这个组件了！

第二，增加了API，原来的API行为保持不变！这个还比较好，至少使用方的程序，至少现有的程序不受影响，那么对于这个策略，设计者应该是只增加API而不减少和在改进原有API时而不改变其行为！不过我认为这是好的策略中的第二，或者是中策！

第三，最好的办法是，在第一个版本的时候，就尽可能地依赖经验和普遍的原则设计和实现这个第一版本，这也许是可能的，而且这样会减少采取第二策略的可能性，让一个API在长久的使用周期中看起来就像一个百年建筑一样可信！人们就是喜欢使用这样的组件了！不过做到这一点非常困难，的确非常困难，需要大量的提炼和努力，不过也是可以达到的，不是吗！所以不要以为第一个版本就可以轻而易举的实现，我们应该为它做出最好的规划！