当前任何一个组织 — 无论是私企，还是国企，无论是政府还是民间组织，无论是在国内还是在国外 — 都在强调提高效率。但"提高效率"不简单是一句口号，还需要脚踏实地的真正去做。

说到"提高效率"，大家首先就会想到工作的行为主体-人！促进人员能力的提升是提升个体工作效率的一个很好的办法。在软件开发领域也有一个公认的事实，那就是一个顶尖程序员的效率可以十倍甚至百倍于一个普通程序员。为此，很多组织都投入巨资引入各种针对个体能力提升的培训和咨询，试图以此提升全体人员的效率。我们不能否认这种方法的效果，但从实际情况来看，似乎效果有限，特别是对组织整体效率的提升效果有限，因为组织内不可能都是由领域顶尖人员组成的，即使接受培训，大部分人员也不会成为顶尖级，其水平还是处于平均线的。这就是摆在我们面前的一个现实，我所在的组织同样也面临着同样的问题，这也促使我进行了一些较为深入的思考。

那么除了个体能力提升之外，我们还应当如何提升组织的整体效率呢？

提高效率，首先要做好"认知"，找到方向。即知道什么工作决策和行为是有利于提高效率的，什么样的决策和行为是无助于提高效率或是导致无用功。以现阶段比较火的物流快递行业为例，科学地选择送货路线无疑是提高整体效率的一个好方法，即能节省时间，还能节省交通燃油成本，缩短送货时间，提高服务质量。如果你作为快递公司的老总，你的决策应该是：建立一套高智能的选路系统，以帮助每个快递员快速完成送货任务。在软件开发领域，人们一直以来都在做着探索，努力地瞄准正确的方向前行。特别是近些年来，软件开发借鉴其他传统产业的生产经验，试图通过消除开发过程中的浪费来提升整体开发效率。什么是软件开发领域的浪费呢？广义的讲，对开发团队而言，不能卖钱的工作都是浪费；对于客户而言，不能给客户带来价值的工作都是浪费。传统行业(比如汽车制造业)用事实证明，浪费现象只能尽量减少，但无法完全杜绝。但浪费是否是完全没有意义的呢？有些"浪费“对组织的发展壮大还是有裨益的，比如建立企业内部知识库等。OK，我们似乎找到了软件领域提升组织整体效率的方向，那就是要尽量减少那些既不能给客户带来直接价值，也无法给我们自身带来经济利益，对组织的发展壮大也无多大贡献的浪费。

提高效率，还要了解个体的行为特征。我们应该了解所在行业从业人员的行为效率曲线。理想的情况是让大家始终都能处于自己的高效率区间。俗话说，术业有专攻。快递员在挨家串户送货时效率是最高的；软件开发人员在设计、编码和调试时效率是最高的；文案人员在编写文档时的效率是最高的，等等。如果让每个快递员自己优化送货路线、让每个软件开发人员自己做集成构建，环境搭建、调试和测试、让文案人员自己负责后期的装订和印刷，那低效率就不可避免。说白了就是让大家都去做且一直在做自己最擅长的事情，这样才能尽量发挥出个体的效率，才有益于组织整体效率的提升。

有了上面两个方面作为前提，我们就可以得到一种切实可行的提升组织整体效率的方法，那就是推进组织内部服务的建设。什么是"内部服务"？简单来说，就是组织内部一部分人员的工作就是为其他人提供服务，至于服务的内容因行业的不同而不同。"内部服务"可以从全局角度主动地推动个体效率提升。从个体行为上来看，内部服务可以剥离大多数个体所不擅长的事情，让大多数个体长期处在高效率区间，后期将这些大家不擅长的事情以服务或基础设施的形式科学地且用户界面友好地提供给大家，让大家可以高效地或自动化地使用。这就是"内部服务"的原理所在。注意，与在培训和咨询等过程中，组织内人员需主动学习和主动提高效率不同，通过内部服务的建设和提升，组织内人员是在不知不觉中"被提升了效率"，也避免了因人员能力参差不齐，效果因人而异的问题，这是其最大魅力。

个人觉得实施内部服务建设有以下几个关键要素：
- 细分工作，识别出基础服务。即找出可以作为服务的工作内容。还是以软件开发领域为例，系统管理小组和版本构建小组的工作内容就可以作为提供给其他人的基础服务。

- 按工作内容调整团队组织。即将组织划分为若干基础服务团队，以及其他非提供内部服务的产品团队；明确内部服务团队的职责范围以及与其他团队的接口方式。

- 基于内部服务改造工作流程。将内部服务放入工作流程中，让成果物在各个团队间高效流动，甚至可以在一定程度上简化原有工作流程。

在人员有限的前提下，内部服务团队也可以是虚拟团队，不过这样做就会导致内部服务工作的优先级在工作极其繁忙时被降低，可能会导致浪费现象在后续显现出来。内部服务的概念也是分工细化思想的延伸，也许它并不适合一些人员规模较小的startup，但却适合那些规模已经扩大但效率却没有明显提升的组织。

在软件开发领域，我们很容易识别出很多基础服务，诸如服务器/虚拟化环境支持服务、公共库开发团队、测试工具的开发服务、构建与持续集成服务、自动化测试支持服务、文案服务等。越来越多的自动化框架和工具(比如puppet、jenkins、buildbot等)也让内部服务团队可以不必具有很大规模，而且可以使得服务团队自身的工作也颇为高效。另外内部服务团队还便于将一些致力于消除浪费、提高效率的思想(诸如持续交付、DevOps)快速地转化为具体的工作方法和实践。

总之，提高效率是一个极其重要的事，甚至是直接关乎于真金白银的事。一个组织应着眼于全局思考、规划和落实提高效率的具体措施。如果一个组织现在依然将提高效率停留在喊口号的层次上，那若干年后，这个组织剩下的也就仅是那句口号罢了。

又是一个行为类的模式，似乎这类模式在使用C语言开发的项目中适应性更强，而另外两类模式创建型和结构型则略显不受待见^_^。

Chain of Responsibility模式（中文名：职责链模式）是一个不算复杂的模式。虽不复杂，但用好了同样可以解决大问题。个人觉得其最大的好处就在于可以动态地重组针对一类对象的处理流程。正是得益于这一优势，它才可以在纷繁芜杂的业务领域站稳脚跟。

我们遇到的问题是这样的：有一类消息需要我们的系统处理，消息在系统入口处需经过种种业务层面上的校验，只有通过所有校验的消息才被允许进入到我们的系统中并被视为合法的消息。针对来自不同企业的消息，系统在入口处的校验规则是不同的，对于信用度较高的企业，系统实施的校验较少；而对于信用度不高的企业或新签约企业来说，其校验规则就相对多些；随着企业的信用度的变化，系统也会自动地调整对其下发消息的校验规则集。

最初关于这个部分的系统伪码大致是这样的：
int check_msg(corp_info, msg) {
    if (corp_info->need_check_source) {
        if (FAILED == check_source(msg))
            return xx;
    }

    if (corp_info->need_check_destination) {
        if (FAILED == check_destination(msg))
            return xx;
    }

    if (corp_info->need_check_priority) {
        if (FAILED == check_priority(msg))
            return xx;
    }

    if (corp_info->need_check_content) {
        if (FAILED == check_content(msg))
            return xx;
    }

    return 0;
}

在check_msg外部，系统根据企业的信用度设置corp_info中的多个check feature开关，诸如need_check_source、need_check_content等，从而使得check_msg内部可以根据企业的不同feature开关情况，对企业发送的消息实施不同的校验规则。

这里消息校验的请求者与消息校验的处理者具有一定的耦合，另外check_msg中满眼的if语句也让我们的神经为之紧绷！于是我们尝试移除if，尝试降低请求者和执行者之间的耦合。在《设计模式》中我们找到了Chain of Responsibility模式，我们决定试试！

我们首先定义了handler_t接口：

struct handler_t {
    void (*set_successor)(struct handler_t *this, struct handler_t *successor);
    struct handler_t* (*get_successor)(struct handler_t *this);
    int (*handle_request)(struct handler_t *this, void *obj, void *args);
    int type; /* handler类型 */
};

接下来，我们根据例子的需要逐个定义该接口的实现：source_checker、destination_checker、priority_checker和content_checker。以source_checker为例：

/* source_checker.h */
struct handler_t* source_checker_new();
void source_checker_destroy(struct handler_t **h);

/* source_checker.c */
struct source_checker_t {
    struct handler_t h;
    struct handler_t *successor;
};

static void _set_successor(struct handler_t *this, struct handler_t *successor) {
    struct source_checker_t *h = (struct source_checker_t*)this;
    h->successor = successor;
}

static struct handler_t* _get_successor(struct handler_t *this) {
    struct source_checker_t *h = (struct source_checker_t*)this;
    return h->successor;
}

static int _handle_request(struct handler_t *this, void *obj, void *args) {
    struct source_checker_t *h = (struct source_checker_t*)this;
    struct msg_t *msg = (struct msg_t*)obj;

    if (校验失败) /* 伪码 */
        return FAILED;
    printf(“[source_checker]: check msg – [%s]\n”, msg->msg_id);

    if (h->successor)
        return (h->successor->handle_request(h->successor, obj, args));

    return SUCCESS;
}

struct handler_t* source_checker_new() {
    struct source_checker_t *h;

    h = (struct source_checker_t*)malloc(sizeof(*h));
    if (!h) return NULL;

    memset(h, 0, sizeof(*h));
    h->h.set_successor = _set_successor;
    h->h.get_successor = _get_successor;
    h->h.handle_request = _handle_request;
    h->h.type = SOURCE_CHECKER;

    return (struct handler_t*)h;
}

void source_checker_destroy(struct handler_t **h) {
    struct source_checker_t *p = (struct source_checker_t*)(*h);

    if (p) free(p);
    (*h) = NULL;
}

destination_checker、priority_checker和content_checker与source_checker的实现类似，关键在于_handle_request的实现不同。

现在我们就可以在初始化阶段为不同企业组装不同的业务校验流程了，假设我们有两家企业A和B，A企业下发的消息需要进行全部业务校验，而B企业下发的消息仅需进行source check和destination check：

/* A企业消息的业务校验链 */
struct handler_t *A_destination_checker = destination_checker_new();
struct handler_t *A_priority_checker = priority_checker_new();
struct handler_t *A_content_checker = content_checker_new();
struct handler_t *A_msg_checker = source_checker_new();

A_msg_checker->set_successor(A_msg_checker, A_destination_checker);
A_destination_checker->set_successor(A_destination_checker, A_priority_checker);
A_priority_checker->set_successor(A_priority_checker, A_content_checker);

/* B企业消息的业务校验链 */
struct handler_t *B_destination_checker = destination_checker_new();
struct handler_t *B_msg_checker = source_checker_new();

B_msg_checker->set_successor(B_msg_checker, B_destination_checker);

我们可以将msg_checker的放入corp_info中，这样check_msg的新实现如下：
int check_msg(corp_info, msg) {
    return corp_info->msg_checker->handle_request(corp_info->msg_checker, (void*)msg, NULL);
}

这样通过A企业下发的消息testAmsg通过check_msg得到的结果是：
[source_checker]: check msg – [testAmsg]
[destination_checker]: check msg – [testAmsg]
[priority_checker]: check msg – [testAmsg]
[content_checker]: check msg – [testAmsg]

而B企业下发的消息testBmsg通过check_msg得到的结果则是：
[source_checker]: check msg – [testBmsg]
[destination_checker]: check msg – [testBmsg]

前面说过动态重组针对某一对象的业务流程是职责链模式一大特点。当某企业信用度发生变化时，该企业对应的checker链也会动态修改。比如当企业A信用度增加时，系统将去除其对应的content check流程，去除过程的实现如下：

struct handler_t *h = A_msg_checker;
struct handler_t *successor = h->get_successor(h);

while (successor) {
    if (successor->type == CONTENT_CHECKER) {
        h->set_successor(h, successor->get_successor(successor));
        break;
    }
   
    h = successor;
    successor = successor->get_successor(successor);
}

重组校验链后，企业A下发的消息testAmsg通过msg_check得到的结果就变成了：
[source_checker]: check msg – [testAmsg]
[destination_checker]: check msg – [testAmsg]
[priority_checker]: check msg – [testAmsg]

也许大家也看到了职责链模式的缺点，那就是每增加一个业务处理对象就要增加一个handler_t的具体实现，如诸多xx_checker，在C语言开发中这至少需要一个头文件与一个源文件。但职责链模式对降低请求者与处理者之间的耦合，以及支持职责链的动态重组方面还是会给你带来很大帮助的。是否使用这种模式，需要你自己根据实际情况权衡利弊后做出选择。