基于drupal7 的开发项目代码重构的实践

有幸接触到drupal,并且参与了公司基于drupal7系统的代码重构,所以这篇文章主要讲一下我们团队在做重构的一个过程,包括重构要解决的是什么问题,重构要达到的一个什么样的具体的目标,重构过程是如何实施的。

1、重构要解决的问题

我们平台基于drupal开发的,基于这个平台下面有很多的site,可以简单地理解为,有一套核心的系统,然后基于这个系统下有很多的网站应用,每个应用都有自己的业务逻辑。随着时间推移与不同的用户需求,平均每两个月都会有一个平台的版本发布,也就是有platform_v1.0.0.0版本,platform_v1.1.0.0版本,platform_v1.2.0.0版本等等。每个平台的版本可能都会有新的功能。

现在的问题是,如果有一个site用的是1.0.0.0版本的平台,现在当前最latest的1.8.0.0,那么如果这个1.0.0.0的site只要1.8.0.0 version的其中一个功能的话,该如何实现?我们的做法是,根据每个平台version的release note,也就是每个version的每个功能的开发文档,把1.0.0.0的site升级到1.8.0.0,其中迭代了8个版本,工作量惊人,而且风险巨大。

所以我们考虑,能否有一种实现方法,不区分平台版本,哪个site要用什么功能,我们只要做简单的部署配置,把site需要的功能apply就行了。

基于drupal的强大的模块化,我们考虑把每个version里面,耦合度很强的module都组成一个feature,哪个site要用哪个feature,我们只做feature的简单配置就行,避免了平台升级带来的不必要的风险。

同时,为了尽量做到“简单配置”,减少时间与人工成本,同时又有drupal的module install,所以我们同时把手动配置的操作,通过代码重构,转成自动部署。


2、重构要达到什么样的具体目标

通过上面的背景描述,目标就很明确了:

1)把原来的module整合成feature,每个feature下面有一个或者多个耦合性很强的module;

2)减少不同feature之间的耦合度,比如几个feature要用到的函数放到基础的feature里面;

3)根据每个module的需求(创建表,创建menu,创建content type,权限分配等等),把这些以前人工要做的事情,通过代码写入到install文件里面


3、重构是如何实施的

确定了需求之后,我们要做的第一步就是针对每个feature,在PMT上写solution,把大的ticket具体化,比如:

sub ticket1: feature1应该包括了哪些module;

sub ticket2: review 代码,是feature1跟其他feature的耦合度降到最低(查找其他依赖于当前feature的函数或者当前feature依赖到的其他feature的函数)

sub ticket3: review release note,写install文件,使部署自动化。可以看这篇文章 drupal 7 上使用install文件

...