小库还是大库？

我不知道这里有多少朋友是积累了自己的一套库的。

嗯……说明白点，比如想读写文件了，操作系统 API 的那堆参数我记不住，也用不着那么灵活，于是自己写一个自己记得住的，下次碰到同样情况继续用，并不断完善。哪天想读写注册表了，想读写 INI 文件了，想读写 XML 文件了，想用个动态数组了，想要个链表、树了，可能都会形成自己的一套东西。这套东西可能是基于已有的第三方库，也可能是纯粹自己一点一滴写起来的。好了，我想现在我大概表达得够明白了，这就是我说的“库”，这个库可能不是非常完备，但起码是自己积累的，有着（起码对自己来说）友好接口的东东。

可能有朋友会说，你要自己的动态数组、链表干吗？STL 很好啊！你要读写文件的干吗？CFile 哪里不好？你要读 INI？不是有 API 吗？……诸如此类。如果有朋友持这样的观点，我想我们是不同的一类人。如果您只是能完成某项任务就好，那么确实，不需要这些玩意儿。但是，如果哪一天这种普通的工作做得麻木了，来思考一下另一个层面的事情，您也许会觉得这些也是比较有意思的事。废话到此。

那么，不知道这些库，是以什么形式存在的呢？稍微极端开来讲，可能有两个做法——

第一种做法。我每写成一个功能模块，都是一个（或几个）.h、一个（或几个）.cpp，它们是自我独立的，不依赖于任何别的东西（或者不依赖标准库以外的东西、不依赖于操作系统 API 以外的东西）——总之是不依赖于当前编译系统以外的东西。以后需要使用，就把那几个文件拷到当前项目来使用。然后一个个这样的互不依赖的功能模块构成了我现在所拥有的库。

第二种做法呢，就是我把这个库作系统的规划，划分为很多小的功能模块，这些功能模块可能会彼此依赖，当库庞大以后，甚至连你自己都该不太清楚谁依赖谁了。要使用这个库的功能，就必须把整个库拿进来。到最后，我将这整套东西编译为一个 .lib，这个 .lib 的源程序会一直维护下去。但使用的时候，我就拿编译好的 .lib 来用。

前一种做法就是标题里所说的小库，后一种做法我称之为大库。我的问题是，作为个人的积累，小库好还是大库好？如果可能，我是比较喜欢小库的。但是，经常会有这样的问题，各个功能模块中可能会涉及同一个基础功能，而这个基础功能我已经做过了的，到底是用还是不用？如果用，“互不依赖”就会被打破，最终会发展成一个凌乱的大库；如果不用，我必须把代码抄一遍，那么这两份完全一样的代码在以后同步更新就比较麻烦了。再说大库，一个规划的很好的大库也是不错。但是前期积累的时候，往往没法规划；就算等到有一定的积累了以后再来积累，也会在模块组织上犹豫不决：我到底要不要来一个统一的 typedef 作为我的类型系统？当我实现了 MyVector，MyString 以后，我的后续代码势必都会使用它们，那么与别人之间的代码交流就成了问题了。

我最近一直困惑于这个问题。而我本人对此的理解也就如上文所述。希望有朋友指教、赐教。谢谢~~！