Drupal 是由很小的核心和几千个实现不同功能的模块组成，无论要实现什么功能，几乎都可以通过找到模块来实现。但是一个中等的系统会需要几十个或者上百个模块。所以Drupal 模块的部署和维护必须通过高效的方式来实现。
Drupal 提供了两种不同的部署方式，你可以通过命令行来部署，或者通过传统的WEB界面来维护。
本文只介绍命令行的方式。Drupal 有命令行维护工具 Drush 。通过Drush来维护系统是Drupal众多优秀的特性之一，它类似于Django中命令行自动生成数据库结构，或者PECL安装PHP的扩展模块，或者yum来维护Linux软件包。只需要一行命令就可以安装系统，或者下载一个模块。
1. Drush的安装：
对于Drupal6.x,下载Drush模块，并且解压即可：
$ cd ~
$ wget http://ftp.drupal.org/files/projects/drush-6.x-3.3.tar.gz
$ tar zxvf drush-6.x-3.3.tar.gz
$ ln -s /path/to/drush/drush /usr/local/bin/drush
这样你可以在任何目录执行drush命令。
2. 用Drush来下载安装Drupal：
你不需要从Drupal网站下载安装包，上传到FTP，再配置数据库，从WEB界面安装：
下载并且解压Drupal包：
$ drush dl
安装Drupal
$ drush is
安装CCK
$ drush dl cck
$ drush en cck
清空cache可能是开发中最常用的功能：
$ drush cc
查看watchdog信息：
$ drush ws
执行cron
$ drush cron
更多drush命令：http://drush.ws
推荐用Drush来部署和维护Drupal
所有模块的安装维护仅仅需要1-2行命令,不必在忍受WEB界面网速的问题。我们需要用最好最快的方式来节约时间，提高效率。
1. Redis web admin UI
Redis-admin:
The only redis admin ui written in php found till now. But lake of testing, personally not run it successful.
Ref url: http://code.google.com/p/redis-admin/ PHP
RedisAdminUI:
This project based on C# and ajax, so you should run under Windows server, or install mono under Linux.
But you can simply put XSP under the project directory to setup it.
Ref url: http://www.servicestack.net/mythz_blog/?p=381 .net + XSP
Online Example: http://www.servicestack.net/RedisAdminUI/AjaxClient/#
Redweb:
Web interface of Redis written in Python.
Ref url: https://github.com/kennyshen/redweb
RedisCover:
Web interface of Redis written in Ruby.
2. Advantage of Redis
Get Unique IDs just one query:
INCR <object>
Atomic Opertion:
MULTI
…
EXEC
Multiple Databases:
SELECT 3
The default database will be 0.
Pub/Sub Asynchronous message
SUBSCRIBE room:a
PUBLISH room “message”
UNSUBSCRIBE room
Simple FIFO Queue
LPUSH queue1 a
…
RPOP queue1
时常回顾team的开发过程, 虽然总体还算非常顺利, 但是仍然有很多可以改进的地方, 找出其中的问题可以大大提高开发的效率。
项目开发中遇到的问题，或许也是很多团队遇到的问题：
通常一个feature需要比计划更多的时间来完成；
孤立看一个feature，很难估计相关联的任务量，所以通常一个看起来简单的特性需要更多的时间来完成。Bug产生和解决的反复会延长估计的时间。将一个feature放到整个项目中还需要考虑到context的分析的工作量。
不能孤立的分析一个feature, 一个feature的增加，可能需要对之前很多feature的修改，一个feature的变化，可能需要对之前更多的feature进行改进。
有些时候程序员的效率会比平时低；
这常发生在task频繁切换的时候，假如一个任务正在进行，又增加了另一个任务，同一个人做的情况下就会遇到task的切换，很多时间浪费在环境的分析回忆上。
文档过多或者过少；
文档过多会浪费很多时间在写文档上，这是敏捷开发的大忌，但是完全不写文档很难做到协同开发，即使是自己写的代码时间久了也会忘记细节。
会议不能有效解决问题；
会议需要进行日程计划，每次例会需要所有人了解议题，提前熟悉相关内容，否则复制的问题沟通会很困难。
PM认为问题很简单，而开发团队认为很难解决。
应该把问题分离到程序解决和业务流程解决两部分，有时候单纯用自动化的方式不比人工流程效率高。其实难题往往通过第三种方式来解决，需要花更多的时间在问题分析上。
程序员和非程序员思维有很大区别(实际参与编码的程序员)：
程序员会考虑一个feature是不是会失败，而非程序员想的是一个feature是不是会成功，可以加上去。所以往往后者会不断的添加feature，前者会经常说实现这个很难，实现那个几乎没可能。
项目的开发，解决所有问题其实都是在一个现有的堆栈上进行的，这基于先前的开发经验或者网上能找到的参考的经验。也许问题是很简单，但是假如这方面的经验非常缺少，就会导致更大的开发风险，更大的难度。
非程序员往往从问题难度本身来看待开发的难度，而程序员则会根据经验来看待问题，比如现有技术堆栈和现有经验。
总之
项目的开发过程其实是ROI的控制和对细小任务风险的评估的过程，只有所有人能高效沟通，正确不断评估风险，正确审视投入产出比，才能真正做到开发的高效率。
转载请保留原文链接 http://blog.eood.cn/improve_communication_skills_and_development_efficiency
