我们都知道如果将所有的功能都写成 Library,那么我们在编写应用程序的时候就可以快速便捷的写出想要的功能,因为这些已经事先都实现过了,这样在写代码的时候就可以迅速的将 Library 依赖到我们的项目里。
然而在通常的情况下现实和期望的总是相差很大,在使用 Library 的过程中可能会出现各种各样的问题,这时候我们第一个要问的问题就是,这样的功能应该是一个Library 吗?相信大家在团队开发的时候都会遇到类似的问题。
下面有一些建议能够帮助我们来决定什么样的功能能写成一个 Library ,什么样的不能。
有没有另一个地方使用相同的功能?
首先,相同的功能有没有在另一个地方使用过,不管我们谈论在UI界面,还是通过实用工具来帮助你完成某些任务时,在将这些功能从代码里抽出 Library 的时候都要考虑一下相同的功能是否在其他的地方使用过,这个很重要。
如果其他地方没有使用过相同的功能,也别担心,为了解决问题可以针对该问题编写出一个解决方案,因为很有可能在以后会有类似的功能需要实现,这样就可以将这一个功能做成一个 Library 了,这样做也可以提升我们对代码的熟练程度。
有没有其他的 Library 已经实现了?
第二,我们要看看是否已经有开源的 Library 已经实现了我们需要的功能,是否确保我们不是在重塑别人已经造好的轮子,如果我们恰巧碰到了一个质量也不错也能解决我们问题的 Library,这不是一个节约自己时间的很好的机会吗?
如果你遇到了一个类似的开源 Library 但是并不能很好的解决问题,也可以和作者进行联系看看对方为什么没有实现,或者是其他的原因,这样我们就可以 fork 这个项目,并把我们的需求功能增加上,这样我们就对这个开源项目做了自己的贡献了。
功能是否真正一致?
很多时候在开发新特性的时候,我们感觉上在很多的地方都使用到了这样的工能,但其实仔细看的话,在不同的地方使用可能会有一些细节上的不同,这时候我们就要考虑这些细节问题,不能仅在大体功能上一样就抽取出一个 Library ,这样的问题不应该被忽视,不然就相当于起步的时候就走弯路了。
所以我们在将在使用库文件或者将要创造自己的库文件时,一定要问一问自己,是够这样的功能做成 Library 之后真正的帮我们节省了时间。
OneAPM Mobile Insight 以真实用户体验为度量标准进行 Crash 分析,监控网络请求及网络错误,提升用户留存。访问 OneAPM 官方网站感受更多应用性能优化体验,想阅读更多技术文章,请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。