创建一个图书馆什么时候变得值得?[关闭]

静态库也有它们的问题。

• 使用静态库会阻止您解决问题,因为代码在另一个项目中,并且变得麻烦。
• GCC有一个bug,而在类别中定义的任何方法都是在静态库之外优化的。不好如果你 代码由现有类中的许多便利类别组成。

因此,您需要的是一个解决方案,您可以将依赖项添加到实际的源代码中。这样可以避免讨厌的GCC错误,并且 童子军规则 是被鼓励的!

(永远不要在开发人员自己的计算机上构建分发二进制文件!) .

全部的 使用共享库的项目。

构建服务器上的硬拷贝允许对共享库进行版本标记,这样您发送到App Store的v1.0版本就永远可以复制!

http://blog.jayway.com/2010/01/31/continuos-integration-for-xcode-projects/

我会唠叨他写博客和分享基于Rake的依赖系统。它基本上只是几个带有Ruby脚本的行。

我添加了一些我认为合理通用的东西,我可以设想在将来某个时候使用。

毕竟,把它添加到你的库中是没有坏处的,即使你再也不使用它了。

或者,用更像商业的术语来说:当净现值超过净现值时。

如果你想把你的类分发给你的“团队”,那么你就不必担心它们对你的代码所做的更改,从而保持库的一致性。

或者如果你想把你的类作为API出售给另一个开发团队,那么你可以对API用户隐藏源代码。

我有一些“实用程序”类,我发现它很有用,我确实倾向于将类文件放入我的解决方案中,因为我发现它更容易和更快(不是额外的2到3次单击的问题),所以我真的认为我做它是出于habbit比其他任何事情。

这样你就不用担心剪切和粘贴错误了。此外,如果您对这些类进行改进,它们可以被传播到使用它们的其他项目(如果您愿意),但您可以随时回滚到以前版本的bug修复/测试。

在github等站点上发现这样的帮助程序代码是很常见的 example

我有一个独立项目中的静态库。 这样我就可以完全开发这个库,完成单元测试等,然后通过使另一个项目依赖于它而简单地重用它。

这意味着我不需要剪切/粘贴,也意味着如果我发现/修复了一个bug,或者添加/修改了库的一个特性,那么就可以轻松地对它进行回归测试。

所以就我的钱来说,把一组“有用的代码”转换成一个库的时间当然是当你发现你想再次使用它的时候。

(当然,我们都有从以前的项目中复制/粘贴而重用的有用代码片段—这些代码片段不一定适合放在库中。)