“我们是否应该使用Drupal?”

Should we using Drupal?

  “我们是否应该使用Drupal?”——这样的问题大家应该都不陌生,即使有人告诉你“应该”或者“不应该”,在你的脑子里也必定会有各种疑问,好像问题并不是像表面这么简单,答案好像也不是存在于“应该”和“不应该”之间。

  如果你正被这个问题或曾经被这个问题所困扰,那么,接下来的内容你可能会感兴趣。

  正如前面所说“我们是否应该使用Drupal?”这个问题并不是在问“我们是否应该使用Drupal?”,真正问题也许是——为什么应该使用Drupal?为什么不应该使用Drupal?以及应该怎么使用Drupal?

 

为什么应该使用Drupal?

  这个问题实在是太简单了,不是吗?你可以去问任何一个选择使用Drupal的人、团队或者公司。不用太资深,他也能够讲得头头是道。没错,这就是Drupal的魅力,它实在是太好了,它能这样,能那样,几乎无所不能。—— Drupal 实在是太好了,这就是应该使用它的理由,大部分会提出本文开头问题的人也相应这一点,所以才会提出那样的问题。

 

  但这个答案并不能回答那个问题,所以我们再看看“为什么不应该使用Drupal”……

 

为什么不应该使用Drupal?

  不应该使用Drupal的原因有一点与应该使用它的原因是一样的,那就是他太强大了,他是整个Drupal社区的智慧结晶,熟悉它需要花费大量的时间和精力——这些时间和精力不是指学习它,因为学习任何一项技术并不比其它任何技术要难。

  也许会有人讲到其它的原因,比如性能不好、版本不向后兼容、难以协作等等,这些也可能是阻碍你使用Drupal的原因,但无需在意这些问题。

 

  也许你已经发现了,这些“应该”和“不应该”的理由对你来说并不足够?不是因为这些信息无关痛痒,而恰恰正是因为你觉得他们至关紧要,才会更加想要更多“我们是否应该使用Drupal?”的答案。而这样的答案即使给再多也不会够。

 

应该怎么使用Drupal?

  对于有 R&D 部门的大公司,不必把注意力放在Drupal的技术点上,而应该考虑建立和运营自己的Drupal团队。因为Drupal已经提供了扩展性非常良好的研发标准和框架,这对项目的持续性、统一性以及未来的可持续发展性都提供了良好的保障。建立团队能够从人员方面更好的保证项目的稳定性和可持续性。

  团队建立的具体做法有两种:一种是招募一位有能力的Leader,然后再通过招聘、培养的途径逐渐强化团队;另一种就是与有专业Drupal培训业务的公司达成合作,长期驻场进行项目指导以及团队培养,直至团队能够独挡一面。

  对于有 R&D 部门但技术能力不够强、或经费相对有限的公司,建议将项目发给外包公司,并与之达成合作,在外包项目完结后,为你提供业务与技能的培训、咨询。通过外包公司完成项目整体的建设工作,并让自身的 R&D 团队掌握一定必须的Drupal技能,能够以较快的时间成本完成项目,并以正对较低的成本学习Drupal,以及对项目进行维护和二次开发。

  对于没有 R&D 部门的公司/团队/政府部门,如果项目后期还会有较多研发需求,则不建议使用 Drupal。如果只是展示型或弱功能型的站点,可以将项目进行外包使用Drupal进行搭建,但意义也不大。Drupal 的最大优势在于其灵活性和可定制性,如果自身不使用这些优势去达成定制或节省长期成本的目的,将项目直接外包给任何能够以任何技术达成目标的团队似乎会更好。

  附注:如果使用Drupal仅仅是因为它在全球范围内响亮的名号,那其实就不用纠结应该不应该了 :D


付费阅读