项目延期和重构

项目背景及延期原因分析

这是一个用作宣传的系统，它由客户端，Flash端，服务端三部分组成，客户端放在客户机器上，实现一些本地的播放及相关操作； Flash端被嵌入到客户端中，调用服务端的数据。服务端做播放内容的管理及提供数据接口服务。

现在已经有一个1.2的版本在生产环境运行。现在的需求是增加一些功能并且将旧的耦合较多的部分进行重构，以插件的方式提供播放内容。

这三块分别是三个研发部门抽调的开发人员实现，并且开发人员没有换到一个区域办公，人在不同的楼层。考虑到这是一个不到9人月的小项目，所以在项目估算的时候并没有做基于代码行的估算，而是以一种比较粗犷的工作量估算方法。在估算过程中，有针对这三块功能进行分别估算，但是在Flash端的估算过程中没有体现出这是一个以细化需求为目的的估算过程。开发在正常的进行，项目一切正常，然而由于其它项目需要，Flash端的开发人员需要进入其它项目，于是将此项目的开发工作交接给另一个开发人员，此时Flash端的开发进度就开始脱离了项目经理的掌控。等到服务端和客户端的开发完成，测试完成，风险时间用完，Flash端的开发工作才基本完成。但是Flash端是客户端和服务端的中转地，起着至关重要的作用。待开发工作完成后，进行需求确认，发现现有的功能较旧版有较多出入，一部分必须有的功能并没有实现，实现的功能中还有较多的BUG。于是项目延期……

原因分析

基于项目管理的角度分析整个项目过程，存在以下问题：

估算过程问题
人员变更问题
项目经理进度把控问题
风险识别不充分

估算过程应该是一个细化需求，指导开发人员更了解所开发功能的过程，从而在对需求的理解上对整个开发周期进行估算。此项目估算过程过于草率，没有体现估算的价值。人员变更没有在项目管理过程中体现，在人员变更时对于工作的交换及需求学习等活动都不充分，甚至没有。虽然有一些客观原因，但是项目经理确实没有实时的现场的跟进Flash端开发的进度，过于充分相信开发人员对于进度的描述。风险识别过程不充分，特别是人员变更及采用工作量估算时，没有对风险有一个充分的识别。

重构对项目的影响和如果可以重来

基于代码开发的角度，主要是Flash端重构的问题。重新认识下Martin Fowler在《重构》这本书中对于重构的定义：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。

我们这次重构是有必要的，在需求列表中有将旧的耦合较多的部分进行重构，以插件的方式提供播放内容的需求项。但是从现状来看，这次的重构已经不再是纯粹的重构了，它变成了一个重写的过程。旧的所有的功能都重写了，并且一些资源的使用都是采用的新的。没有认清重构的本质，没有定义好重构的范围，这是此次问题的关键所在。不改变代码外在行为的前提在本次重构中没有体现，并且对于外在行为的定义和识别活动也没有进行，这是一个问题。

如果可以重来，重构前开发人员对于原有代码外在行为的进行需求识别和功能细节识别，这个可以简单点，开发人员给出一个check list，产品、测试都可以使用这个list, 同样这也是自己重构过程中的指向灯。在给出列表后，产品和测试人员需要对这个列表进行审核，确认是否和已经的外在行为一致，这些活动在开发前和开发完成后都要进行。

另一些思考

基于不同的技术的项目，可能项目经理对这些领域不了解，但是可以看到实际的产出，在一些功能实现完成后，尽量到开发人员的位置上确认其描述。
对于跨部门的项目，虽然推动其它部门的人做事有一定的难度，但是事是必须要做的，需要更多的关注和协调。
如果可以，项目组成员集中在一个区域是最好的，不过有时候也只是想想而已。

以数组形式访问对象的成员变量

在Yii框架中我们可以直接以数组的方式访问对象的成员变量，查看其源码得这些类都实现了ArrayAccess接口。如果你想让一个类的实例可以以数组的方式访问，实现ArrayAccess接口就可以了。如下示例：

class Foo implements ArrayAccess {

    private $_container = array();

    public function __construct() {
    }

    public function offsetSet($offset, $value) {
        $this->_container[$offset] = $value;
    }

    public function offsetExists($offset) {
        return isset($this->_container[$offset]);
    }

    public function offsetUnset($offset) {
        unset($this->_container[$offset]);
    }

    public function offsetGet($offset) {
        return isset($this->_container[$offset]) ? $this->_container[$offset] : NULL;
    }

}

$foo = new Foo;

$foo['test'] = 100;
echo $foo["test"];

这是官网上的一个例子，修改了一些代码，非常简单，它实现了一个类，这个类实现了ArrayAccess接口。从而我们可以以数组的方式访问或设置值。

什么原因导致可以以这样的方式访问呢？难道仅仅是因为那个接口吗？归根结底应该是类中的我们约定好的方法，而这些方法中只是接口的形式表现出来了。如果我们没有实现这个接口，而仅仅某个类拥有了这些方法呢？当程序执行时，程序会输出： Fatal error: Cannot use object of type Foo as array…

这表示实现这个接口是必须的，如果实现这个接口，那么就一定需要实现这个接口定义的所有方法。比如我们要以数组的方式读取一个成员变量，那在PHP内核中是如何实现的呢？通过表象看本质，这里是以数组的方式读取，那么其实现的位置应该还是在方括号符的实现位置。以VLD查看其中间代码，我们可以得知数组读取变量的中间代码为：ZEND_FETCH_DIM_R 在此中间代码的执行过程中最终都会调用zend_fetch_dimension_address_read函数来读取值。在这个函数中，它会依据不同容器类型做不同的处理，这些类型包括：数组，字符串、NULL、对象等。虽然我们是以数组的方式调用对象的属性，但在放对象属性的窗口还是对象。因此，此处程序走的分支是对象，在此分支中，对于对象，它会调用对象的read_dimension方法，默认情况下，Zend引擎的read_dimension方法默认实现是 zend_std_read_dimension函数（Zend/zend_object_handlers.c）。我们看zend_std_read_dimension函数的实现，如下：

zval *zend_std_read_dimension(zval *object, zval *offset, int type TSRMLS_DC) /* {{{ */
{
    zend_class_entry *ce = Z_OBJCE_P(object);
    zval *retval;

    /* 判断是否为ArrayAccess的子类 */
    if (instanceof_function_ex(ce, zend_ce_arrayaccess, 1 TSRMLS_CC)) {
        if(offset == NULL) {
            /* [] construct */
            ALLOC_INIT_ZVAL(offset);
        } else {
            SEPARATE_ARG_IF_REF(offset);
        }
        zend_call_method_with_1_params(&object, ce, NULL, "offsetget", &retval, offset);

        zval_ptr_dtor(&offset);

        if (!retval) {
            if (!EG(exception)) {
                zend_error(E_ERROR, "Undefined offset for object of type %s used as array", ce->name);
            }
            return 0;
        }

        /* Undo PZVAL_LOCK() */
        Z_DELREF_P(retval);

        return retval;
    } else {
        zend_error(E_ERROR, "Cannot use object of type %s as array", ce->name);
        return 0;
    }
}

从上面的代码我们可以看出：程序会先判断所给对象的类是否为ArrayAccess的子类，如果不是，则会显示错误，这在前面已经猜测，在此证实了。如果是其子类，则调用offsetget方法获取值。

虽然我们在使用SPL时会比较简单，但是如果要开发一个SPL有时可能就没这么简单了，特别是那些有语言特性的SPL功能（如ArrayAccess），则在实现时可能就需要调用相关语言实现的代码了，从上面看SPL与语言结构产生了较为严重的耦合，如果这个SPL要去掉，则需要修改的地方不只一处，是否有其它方案？ SPL现在本来就是以扩展的形式存在于PHP中，以扩展的方式加载，却不能以扩展的方式卸载。优雅乎？

PHP的类自动加载机制

在PHP5之前，各个PHP框架如果要实现类的自动加载，一般都是按照某种约定自己实现一个遍历目录，自动加载所有符合约定规则的文件的类或函数。当然，PHP5之前对面向对象的支持并不是太好，类的使用也没有现在频繁。在PHP5后，当加载PHP类时，如果类所在文件没有被包含进来，或者类名出错，Zend引擎会自动调用__autoload 函数。此函数需要用户自己实现__autoload函数。在PHP5.1.2版本后，可以使用spl_autoload_register函数自定义自动加载处理函数。当没有调用此函数，默认情况下会使用SPL自定义的spl_autoload函数。看下面两个例子：

1、 __autoload示例：

function __autoload($class_name) {
   echo '__autload class:', $class_name, '<br />';
}

new Demo();

以上的代码在最后会输出：__autload class:Demo。
并在此之后报错显示： Fatal error: Class ‘Demo’ not found

2、spl_autoload_register示例：

function classLoader($class_name) {
    echo 'SPL load class:', $class_name, '<br />';
}

spl_autoload_register('classLoader');

new Demo();

以上的代码在最后会输出：SPL load class:Demo。
并在此之后报错显示： Fatal error: Class ‘Demo’ not found

以上的两个示例表明：当类不存在时（即需要的类不在类符号表），Zend引擎会将再调用一次用户定义的函数，如__autoload或spl_autoload_register注册的函数。如果这两个方法同时存在，那么程序会调用哪一个呢？还是说两个都调用？看下面一个示例，你觉得会输出什么呢？

function __autoload($class_name) {
    echo '__autload class:', $class_name, '<br />';
}

function classLoader($class_name) {
    echo 'SPL load class:', $class_name, '<br />';
}

spl_autoload_register('classLoader');

new Demo();

首先我们看__autload函数。从其命名格式来看，这是一个魔术方法。虽然__autoload和__set、__tostring等类的魔法方法的常量定义在源码级别是一起的，可是它并不是专属于某个类的魔法方法。它是所有的类共用的自动加载魔术方法。它将作为一个全局函数存在。那么Zend引擎是如何在类没有找到时调用这个方法的呢？

不管是使用new关键字创建类的实例，还是使用implement实现接口，或者继承某个类，所有的这些操作都有可能调用__autoload函数。这几个操作在源码层都有一个共同点，它们在执行的时候都需要获取类的信息（接口在本质上也是一个类）。它们在最终都会调用 zend_fetch_class (Zend/zend_execute_API.c)函数，这个函数本身没有多少内容，关键是它调用了zend_lookup_class_ex(Zend/zend_execute_API.c)函数，这个函数就是类的自动加载的真相所在。

在zend_lookup_class_ex函数中，我们看到程序会首先查询类符号表，如果存在类直接返回。如果不存在，就会执行我们所说的自动加载了。这里针对__autoload函数和spl相关的函数都做了处理，并且以第一参数和第二参数传递给Zend引擎的函数调用函数zend_call_function。

在zend_call_function函数中，它会判断第二参数是否存在函数，如果存在函数则只会调用第二个参数传递的函数（这里指SPL注册的函数）。如果第二个函数没有值，则执行第一个参数传递过来的函数（这里指用户定义的__autoload函数）。到这里，我想前面提到的两个方法同时存在的情况应该就有答案了。

潘锦的空间

SaaS SaaS架构团队管理技术管理技术架构 PHP 内核扩展项目管理