软件开发中的理想与现实（九）——三个臭皮匠，顶个诸葛亮

我说过要介绍一下项目组成员的，既然马上要真正开始做项目，那么互相好好了解一下还是很有必要的。
项目组包括我一共四人，分别是realdodo（我）、chanjinn、wumaomao、XophiiX。
我自不用多说，在项目中以项目流程的引导者身份出现，同时也参与开发。
chanjinn是我的学长（噢，忘说了，我们四个都是学生），做过好几个项目，编过很多代码，嵌入式、Linux都有不少研究，做项目很有思想，唯一只是C++基础相对差一点，不过不要紧，软件开发中的经验和悟性很重要。他笑起来很可爱（^______^），就像括号里面那样，很和蔼可亲。
wumaomao是团队中少有的C++高手，了解不少C++和设计模式的东西，有很强的编程能力，绝对将是项目中的中坚力量。而且他写得一手好字，有深厚的文化内涵，令我十分佩服。
XophiiX是项目组中最年轻的同学，比我小整四岁，但在编程方面已经很有感觉，并且酷爱游戏编程，对新东西非常感兴趣。我见到他之后就马上感觉到后生可畏，他超过我只是时间问题了！
在团队中能够拉到这么强大的阵容真是十分难得，我相当知足了。不过，如果放到更大的范围内比较，我们都是菜鸟中的菜鸟，我们的能力还远没有值得骄傲的地步。这不，2月20日，项目正式开张的第一天，我们就遇到大难题了。
我们项目的第一个迭代目标是，将用ASN语法描述的消息转换成C语言数据结构。至于什么是ASN、为什么要自己开发而不用现成的ASN到C的转换工具、为什么不用yacc、为什么用C++开发这些功能等问题我都不想回答，反正我们有自己的理由（呵呵）。写一个最简单的例子，假设有下面的消息：
     A ::= SEQUENCE
    {
        b BOOLEAN,
        c INTEGER
    }
那么转换成C语言之后应该是：
    typedef struct tagA
    {
        BOOL b;
        LONG c;
    }A;
相信一看这个例子就能够明白，SEQUENCE和struct相对，BOOLEAN和BOOL相对，INTEGER和LONG相对，只要处理好这个对应关系就问题不大了。
根据这个想法，XophiiX提出一种设计（白板上画的草图，我把它稍微整理了一下）：
当然，这是一种有效的做法，但是扩展性实在太差，因为ASN的语法可不比C语言简单！例如这个消息：
    Sample ::= CHOICE
    {
        b BOOLEAN,
        c INTEGER
    }
那么换成C语言之后应该是：
    enum Sample_E
    {
        I_B,
        I_C
    };
   
    typedef struct tagSample
    {
        ULONG ulIndex;
        union
        {
            BOOL b;
            LONG c;
        }choice;
    }Sample;
噢，这是什么东西，根本就没有办法简单的进行对应了！如果用刚才简单对应的方式来处理，这个系统真的就会变成一个怪物了！所以这个方案就被否定了，啊，XophiiX不要伤心，在最开始这是很常见的事情。
为了方便确定设计的方向，我根据需求画出这个系统最基本的处理流程图（好了，大家终于知道我有多么菜了）：
但是我还没有想好如何把它变成可分解的类，所以就算大家都比较认同这样的流程也没有用，不过作为一个大体思路，起码有助于指明方向。
马上，我们就把上面这个做了一个精简，并准备对各部分进行细化。精简图如下：
大家心里都明白，最重要也是最麻烦的就是如何收集词元信息，但是如何做最好呢？不知道！眼看着上午就要结束，白板上的图画了又擦，方案往往提出几分钟就被否，然后所有人都陷入一种抓狂之中。
OK，it's lunch time。人是铁饭是钢，还是去休息一下吧。
午餐的时候大家都比较沉默，虽然我一直安慰大家，每个项目开始的时候都是这样的，设计的灵感会突然冒出来的，不过大家还是不太相信。
嗯，不管怎么样，灵感还真的就出来了。不知道是谁提出了一个“作坊”模型，让大家眼前一亮，简单的说就是，把处理ASN文件得到的词元当作零件，收集词元信息当作零件分类，修饰词元信息当作零件组装，输出C文件则是最终包装，那么“作坊”（就是收集词元信息）负责进货（得到零件）和销售（零件分类输出）。按这样的说法，为了进货，我们需要一个库存；为了分类，我们需要工人；为了管理工人，我们需要一个经理。他们的职责也很清楚，库存负责存放零件，经理负责根据库存情况划定工作范围并“雇佣”合适的工人，工人则仅仅专注于工作。他们的关系如下：
这个图并不详细，甚至有些明显地错误，但是我们已经可以按照中央的想法进行工作了！综合来看，现在可以把整个处理过程表达如下：
下面我们就可以针对这种设计，具体规定这几部分之间的接口了！在规定接口时我们发现，这个流程并不具有弹性，因为作坊必须知道它的顾客（修饰词元信息）的情况才能工作，而我们是想实现一个面向广大人民群众的作坊，所以我们引入了一个代理商来解决这个问题。嗯，代理商具体是什么呢？哦，直接用main来做这样的代理其实就可以了！
最终，今天的框架如下：
至于接口，我们也慢慢的一一确定，此处不再赘述。今天的晚餐吃得特别香。
好了，喘口气，今天收获很多，等会我们来好好总结一下。