我们都知道如果将所有的功能都写成 Library,那么我们在编写应用程序的时候就可以快速便捷的写出想要的功能,因为这些已经事先都实现过了,这样在写代码的时候就可以迅速的将 Library 依赖到我们的项目里。

然而在通常的情况下现实和期望的总是相差很大,在使用 Library 的过程中可能会出现各种各样的问题,这时候我们第一个要问的问题就是,这样的功能应该是一个Library 吗?相信大家在团队开发的时候都会遇到类似的问题。

下面有一些建议能够帮助我们来决定什么样的功能能写成一个 Library ,什么样的不能。

有没有另一个地方使用相同的功能?

首先,相同的功能有没有在另一个地方使用过,不管我们谈论在UI界面,还是通过实用工具来帮助你完成某些任务时,在将这些功能从代码里抽出 Library 的时候都要考虑一下相同的功能是否在其他的地方使用过,这个很重要。

如果其他地方没有使用过相同的功能,也别担心,为了解决问题可以针对该问题编写出一个解决方案,因为很有可能在以后会有类似的功能需要实现,这样就可以将这一个功能做成一个 Library 了,这样做也可以提升我们对代码的熟练程度。

有没有其他的 Library 已经实现了?

第二,我们要看看是否已经有开源的 Library 已经实现了我们需要的功能,是否确保我们不是在重塑别人已经造好的轮子,如果我们恰巧碰到了一个质量也不错也能解决我们问题的 Library,这不是一个节约自己时间的很好的机会吗?

如果你遇到了一个类似的开源 Library 但是并不能很好的解决问题,也可以和作者进行联系看看对方为什么没有实现,或者是其他的原因,这样我们就可以 fork 这个项目,并把我们的需求功能增加上,这样我们就对这个开源项目做了自己的贡献了。

功能是否真正一致?

很多时候在开发新特性的时候,我们感觉上在很多的地方都使用到了这样的工能,但其实仔细看的话,在不同的地方使用可能会有一些细节上的不同,这时候我们就要考虑这些细节问题,不能仅在大体功能上一样就抽取出一个 Library ,这样的问题不应该被忽视,不然就相当于起步的时候就走弯路了。

所以我们在将在使用库文件或者将要创造自己的库文件时,一定要问一问自己,是够这样的功能做成 Library 之后真正的帮我们节省了时间。

OneAPM Mobile Insight 以真实用户体验为度量标准进行 Crash 分析,监控网络请求及网络错误,提升用户留存。访问 OneAPM 官方网站感受更多应用性能优化体验,想阅读更多技术文章,请访问 OneAPM 官方技术博客
本文转自 OneAPM 官方博客


OneAPM蓝海讯通
11.4k 声望510 粉丝

Software makes the world run. OneAPM makes the software run.