代码复用的最佳实践——使用Git Sub Module

在我们日常的项目开发中,多个不同的项目经常会有一些相同功能模块,比如Log模块、网络通讯模块、数据库操作模块等。这些模块往往是业务无关的,具有通用性。我们在新项目中快速集成这些模块的最直接的方式就是拷贝一份代码放在新项目中使用,但是,这会导致非常头疼的代码维护的问题。
假如在 A、B 两个项目中使用了拷贝源码的方式来集成 Log 模块,刚开始大家都一切正常,后来 A 项目组的小李发现了 Log 模块的一个 Bug,并立即修改源码进行了修复。从这一刻开始,A、B 两个项目的 Log 模块的源码就不一致了,所以 B 项目也应该立即根据 A 项目的修复方案对 B 项目的 Log 模块进行修复,或者把 A 项目的 Log 模块的源码再拷贝过来。这样 Log 模块的源码就这样不断的拷贝,随着使用这个模块的项目的增多,这种代码拷贝的复用方式将难以维护。
不仅如此,由于不同项目组的维护人员不同,甚至 B 项目组压根都不知道 A 项目组的小李发现并修复了 Log 模块的这个 Bug,所以 A、B 项目中的 Log 模块会一直不一致,很有可能 B 项目组的小王在未来的某个时刻也发现了之前 A 项目组的小李发现的 Bug,他还需要重新对 Log 模块进行修复。这种重复的工作是一种很大的浪费,没有达到高效复用代码的目的。
不难想象,B 项目组也有可能对 Log 模块进行修改,随着时间的推移,这个通用的 Log 模块在 A、B 两个项目中的源码会有很大的差异,每个项目组都要单独花精力来维护这个模块。Log 模块本来应该是一个通用的模块,不同的项目之间也应该使用同一份代码,这样一个项目组修复的 Bug 就自然在其他的项目中也被修复了。
我们通常都说代码复用,所谓复用就是多个地方共用一份代码,而不是多个地方使用不同的代码。要达到这样的代码复用可以使用 Git 的 Sub Module 功能。
把这些通用的功能模块独立成一个一个的小的 Git 仓库,每个 Git 仓库只维护自己这个模块的功能,比如 Log 模块的 Git 仓库里面只关心 Log 模块,所有其他的模块一概没有。在 A 、B 项目的 Git 仓库里面可以使用 Sub Module 的方式引入 Log 模块,当 Log 模块需要修改时,只需要在 Log 模块的那个 Git 仓库里面进行修复和提交,然后在 A、B 项目里面拉取 Sub Module,这样 Log 模块的最新代码就会被所有的项目同时共用了,非常方便,也方便不同项目组的人员共同对 Log 模块进行修复。这样,我们就再也不需要维护多份不同的 Log 模块的源码了。
使用 Git Sub Module 的前提是这个模块一定要是独立的、业务无关的功能模块,那么如何设计和抽离出独立可复用的功能呢?这是一个很值得思考和研究的话题,我的切身经验可以概括为两个字:克制。
欲知如何克制,且听下回分解。