这是一个创建于 3256 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们都知道如果将所有的功能都写成 Library ，那么我们在编写应用程序的时候就可以快速便捷的写出想要的功能，因为这些已经事先都实现过了，这样在写代码的时候就可以迅速的将 Library 依赖到我们的项目里。
然而在通常的情况下现实和期望的总是相差很大，在使用 Library 的过程中可能会出现各种各样的问题，这时候我们第一个要问的问题就是，这样的功能应该是一个Library 吗？相信大家在团队开发的时候都会遇到类似的问题。
下面有一些建议能够帮助我们来决定什么样的功能能写成一个 Library ,什么样的不能。
有没有另一个地方使用相同的功能？
首先，相同的功能有没有在另一个地方使用过，不管我们谈论在 UI 界面，还是通过实用工具来帮助你完成某些任务时，在将这些功能从代码里抽出 Library 的时候都要考虑一下相同的功能是否在其他的地方使用过，这个很重要。
如果其他地方没有使用过相同的功能，也别担心，为了解决问题可以针对该问题编写出一个解决方案，因为很有可能在以后会有类似的功能需要实现，这样就可以将这一个功能做成一个 Library 了，这样做也可以提升我们对代码的熟练程度。
有没有其他的 Library 已经实现了？
第二,我们要看看是否已经有开源的 Library 已经实现了我们需要的功能，是否确保我们不是在重塑别人已经造好的轮子，如果我们恰巧碰到了一个质量也不错也能解决我们问题的 Library，这不是一个节约自己时间的很好的机会吗？
如果你遇到了一个类似的开源 Library 但是并不能很好的解决问题，也可以和作者进行联系看看对方为什么没有实现,或者是其他的原因，这样我们就可以 fork 这个项目,并把我们的需求功能增加上，这样我们就对这个开源项目做了自己的贡献了。
功能是否真正一致？
很多时候在开发新特性的时候,我们感觉上在很多的地方都使用到了这样的工能，但其实仔细看的话，在不同的地方使用可能会有一些细节上的不同，这时候我们就要考虑这些细节问题，不能仅在大体功能上一样就抽取出一个 Library ，这样的问题不应该被忽视，不然就相当于起步的时候就走弯路了。
所以我们在将在使用库文件或者将要创造自己的库文件时，一定要问一问自己，是够这样的功能做成 Library 之后真正的帮我们节省了时间。
OneAPM Mobile Insight 以真实用户体验为度量标准进行 Crash 分析，监控网络请求及网络错误，提升用户留存。访问 OneAPM 官方网站感受更多应用性能优化体验，想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
 |
1
xiamx 2015-12-26 09:16:42 +08:00
A library should have high cohesion, low coupling and deferred binding, all put together to solve a well defined problem.
|
Select Language