作者归档：admin

前端控制器

前端控制器

表现层的请求处理机制需要支持每个用户多个请求，我们可以以集中式或分散式的方式管理这些请求。

如果以分散的方式进行管理可能会导致如下的一些问题：

  • 每个请求都有一个共同的操作，分散处理可能会导致代码的重复。
  • 可能会导致视图导航和视图内容的耦合。
  • 分散处理可能会带来更高的维护成本。

如果我们采用集中的方式进行管理，则可以对安全认证、国际化等操作统一处理，同时也可以在一个集中点处理站点的某些操作（如日志记录，站点全局访问控制等），
并且可以在一个地方处理逻辑在多个视图中重复显示。如此我们有了选择前端控制器的理由。

前端控制器建议集中处理所有请求的处理，然而它并没有限制系统中请求处理器的个数，对于不同的服务，完全可以提供不同的处理器。
这与集中式的管理并不矛盾，其实集中只是一种相对的集中，从而达到解决分散式所产生的问题的目的，
任何一种模式只是为解决一些应用场景的特定问题。

运行机制
一个前端控制器其本体包括两部分：一个分发中心（或叫调度处理程序）和一个command（或动作）层次结构。
当一个请求到达服务器，前端控制器接收此请求，从其请求信息中获取足够的内容并决定下一步操作，然后委托给某个command，执行操作。

分发中心可以是一个类或几个类，它没有页面输出，它的作用就是决定最终运行哪一个command。
这里简单点，可以直接根据参数约定，动态识别并执行。
这种简单方法做到了开闭原则，可以在不修改分发中心的前提下添加新的command。

例子
前端控制器在PHP的框架中基本上都会出现，在实现方式上，前端控制器大多采用Apache的url_rewrite模块，
以在.htaccess中重写规则，将所有请求都转发到index.php文件处理。

如PHP的YII框架，Application即YII framework的前端处理器，它是整个请求过程的运行环境。
Application 接收用户的请求并把它分发到合适的控制器作进一步处理。
其一个访问到动作被执行，简单过程如下：

  • 用户访问 Web 服务器，假设其访问地址为index.php?r=post/show，则其入口脚本 index.php 会处理该请求。
  • index.php建立一个应用实例并运行（run方法，在运行前有若干组件加载，初始化操作）。
  • 在应用从一个叫 HTTPRequest 的应用组件获取此次请求的详情。
  • 在urlManager 的组件的帮助下，根据前面获取的请求详情确定用户要请求的控制器和动作，分别对应CController和CInlineAction。
  • 应用建立一个被请求的控制器实例来进一步处理用户请求，控制器确定由它的actionShow 方法来处理 show 动作。
  • 然后它创建并运行和该动作相关的过滤器（CController->runActionWithFilters( )），如果过滤器允许的话，动作被执行，即CController->runAction() ==> CInlineAction->run()。

对于前端控制器，Java体系中的Struts框架以XML配置方式体现，在strut.xml配置动作，在web.xml中配置过滤器。

  • 前端页面提交以“.do”结尾的请求。
  • FilterDispatcher接收请求并调用Action处理该请求。
  • Action处理完毕返回一个逻辑视图。
  • FilterDispatcher根据Action返回逻辑视图创建物理视图
  • 将物理视图返回给页面。

当然我们也可以在一个PHP文件中实现整个前端控制，直接约定命名规范，根据传递进来的参数动态加载处理器，处理方法，视图等。

PHP的词法解析器：re2c

re2c是一个扫描器制作工具，可以创建非常快速灵活的扫描器。它可以产生高效代码，基于C语言，可以支持C/C++代码。 与其它类似的扫描器不同，它偏重于为正则表达式产生高效代码（和他的名字一样）。因此，这比传统的词法分析器有更广泛的应用范围。 你可以在sourceforge.net获取源码。

PHP在最开始的词法解析器是使用的是flex，后来PHP的改为使用re2c。 在源码目录下的Zend/zend_language_scanner.l 文件是re2c的规则文件， 如果需要修改该规则文件需要安装re2c才能重新编译。

re2c调用方式：

re2c [-bdefFghisuvVw1] [-o output] [-c [-t header]] file

我们通过一个简单的例子来看下re2c。如下是一个简单的扫描器，它的作用是判断所给的字符串是数字/小写字母/大小字母。 当然，这里没有做一些输入错误判断等异常操作处理。示例如下：

#include <stdio.h>

char *scan(char *p){
#define YYCTYPE char
#define YYCURSOR p
#define YYLIMIT p
#define YYMARKER q
#define YYFILL(n)
    /*!re2c
      [0-9]+ {return "number";}
      [a-z]+ {return "lower";}
      [A-Z]+ {return "upper";}
      [^] {return "unkown";}
     */
}

int main(int argc, char* argv[])
{
    printf("%s\n", scan(argv[1]));

    return 0;
}

如果你是在ubuntu环境下，可以执行下面的命令生成可执行文件。

re2c -o a.c a.l
gcc a.c -o a
chmod +x a
./a 1000

此时程序会输出number。

我们解释一下我们用到的几个re2c约定的宏。

  • YYCTYPE 用于保存输入符号的类型，通常为char型和unsigned char型
  • YYCURSOR 指向当前输入标记， -当开始时，它指向当前标记的第一个字符，当结束时，它指向下一个标记的第一个字符
  • YYFILL(n) 当生成的代码需要重新加载缓存的标记时，则会调用YYFILL(n)。
  • YYLIMIT 缓存的最后一个字符，生成的代码会反复比较YYCURSOR和YYLIMIT，以确定是否需要重新填充缓冲区。

参照如上几个标识的说明，可以较清楚的理解生成的a.c文件，当然，re2c不会仅仅只有上面代码所显示的标记， 这只是一个简单示例，更多的标识说明和帮助信息请移步 re2c帮助文档：http://re2c.org/manual.html。

更多编译器相关算法: Compiler Algorithms

项目延期和重构

项目背景及延期原因分析

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

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

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

原因分析

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

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

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

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

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

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

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

另一些思考

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