对软件架构的一些思考(V2.0)

    最近看了一些技术书籍，结合自己的工作体会。对软件架构有了一些新的体会，在这里总结一下。如果说原始的看法是V1.0，那现在的想法就是V2.0吧。
    我虽然早就是党国认证的系统架构师，但对软件架构的看法其实是非常偏实用主义的。记得我在某篇博文里说，何为好的架构？就是在整个软件开发过程中都不会后悔的技术决定，小到函数设计，大到模块划分，仅此而已。这种看法是正确的，但也是无用的。毕竟我们做出一个决定后不可能坐时间机器到未来问：不好意思打扰一下，这个函数设计我后来后悔了吗？“将来是否后悔”是最高标准，当软件需要变更的时候如果痛不欲生甚至想脚底抹油跑路，应该给自己一记棒喝，告诉自己之前架构失当，要吸取教训。但最高标准对于指导软件架构是没有帮助的。怎么做才能避免将来后悔？盛衰岂无凭，还是需要更深刻地思考。
    我之前还有一个观点：就是可以通过重构可以达到好的架构。这不能说完全是错的，比如发现一个函数设计不当，好吧，重构一下，嘿咻嘿咻，一个完美的函数诞生了。但重构的最大问题是：重构是需要花费时间的，一个月的代码重构很快，但半年甚至一年的代码呢？你能这么说服领导吗：呃，老大，对不起接下来一个月我要重构整个代码，不会增加任何功能，可能引入很多Bug，但没关系，之后结构非常完美，Bug我会改得很快，而且以后增加新功能的时候效率惊人。领导会同意吗？如果我是领导，我肯定不会同意。从我过往的经验来看，重构真的可以节省大量时间，勉强维护粗陋的代码长期来看效率反而低得多。但有两点也是事实：1）目前的代码修修补补还是能用，完全重构必然有不少bug，稳定需要的时间可能要很久，开发总是过于乐观和自信；2）这厮又没有变身内裤反穿眼带咸蛋，看上去跟写这些代码的屌丝一个模样，凭啥当时架构不对，现在就能架构好，说不定重构完成后来个新需求，立马又跪着哭喊老大再给我一个月。这事我吃过亏，我曾经觉得一部分代码实在太烂了，那些代码的开发也同意这个看法，认为要提取一个牛叉的类库，再也不能这么过下去了。于是他花费一个月的时间，整出个类库，是否牛X我不知道，但难用极了，大家基本都不用。
    正文开始。
    软件架构最重要的工作是识别和抽取软件中的各种“变数”。这个“变数”抽取出来有可能是一个变量、一个函数、一个类甚至一个模块。这么说可能太抽象了，举个具体例子。前两天我重构了一个自动化生成工具，里面有一段代码做了很多事情，里面包括类型转换，由于目前只遇到LONG和BSTR类型，代码中把类型转换和代码生成杂糅起来。我一看，立马感觉不对，AX控件支持的类型这么多，将来显然会遇到更多类型，于是提取了一个类似下面的函数：
std::string castType(const std::string& argType){
    if (argType == "BSTR"){
        return "VT_BSTR";
    }
    else if (argType == "LONG"){
        return "VT_I4";
    }
    else{
        throw std::runtime_error(argType + " is not supported");           
    }   
}
    是的，这并没有什么难的，不是什么复杂技术，太简单了。其实在绝大多数时候，抽取“变数”都是非常简单的，一般就是给函数增加个变量，给类增加个函数而已。即使由于情况复杂，用了类、设计模式、函数指针这些重型方法，其实又能难到哪里去呢？任何有2-3年面向对象开发经验的程序员，都应该可以轻松应付这些。真正的难度在于“识别”变数。这与逻辑思维能力有关、与开发经验有关、与领域有关。前两个应该没有疑问，至于领域，举个例子：一个经验丰富的Linux开发刚开始接触Windows编程，不懂得如何提取公共模块很正常，但等他熟悉以后就可以处理得很好了。架构能力取决于思考的深度广度，多接触各领域的开发工作、多总结思考，就能提高自己识别“变数”的能力。合理地识别变数和抽取变数，能够改善程序结构、应对需求变更，从而“将来不后悔”。
    是不是“变数”提得越多，软件架构就合理。当然不是，想想Windows API动辄十几个的参数吧（然后好几个参数说明是保留——目前没用，坑爹啊），架构的目的是“将来不后悔”，但总不能现在就后悔吧？要把握一个度——我不想再次引入时间机器的概念，所以就不具体解释这个度了。只是建议多看看各种API吧，见贤思齐，见不肖则改之。
    上面的内容看起来有点唯心主义，“识别和抽取变数”、“把握度”，似乎都是不可捉摸的。但并非如此，多实践、多总结，就能不断成长。就像武功一样：光说不练假把式，光练不说傻把式。世上不存在完美的架构，因为各种情况太多太复杂（啥！邮局要能P2P下载？）。但存在一个够好的架构让我们可以从容应对各种显然的需求，这也就是软件架构想要达到的目标。路漫漫其修远兮，与诸君共勉。
   
    写本文时一些乱七八糟的随想：
    1）一定规模以上的软件，架构要交给靠得住的人。不要怀疑新手（ps：我说的新手与工龄无关，只与能力挂钩）的架构能力——他们绝对会把事情搞砸的。让他们填空和维护软件去。
    2）不要让能力不够的开发进行重构，换个发型，凤姐还是凤姐。
    3）代码Review是必要的，可以知道每个人的真实水准，但也不用花太多功夫。强者恒强，弱者恒弱。
    4）不要老想让新手完全动起来，那样只会生产更多的垃圾代码，以后擦屁股的时候更痛苦。
    5）合理的软件架构要能够避免超级大类/函数（除非只是干分发工作），从而能够将软件模块化，有利于协同开发。最好能使得某些部分类似“填空”，从而让弱点的开发也能参与。