程序架构与设计(Java语言)

 从事应用开发的程序员或多或少都曾有过这样的感觉:这个世界充斥着形形色色的概念和缩写,不知该追随这位导师还是信奉那个门派,如EJBRoRAJaxHibernateIoCAOPRod John son在他在书中《Expert One on One J2EE Development without EJB》倡导一种的“循证架构”(evidence based architecture)。 
  选择一种架构、一种技术的依据是什么?Rod John son认为,应该是基于实践的证据、来自历史项目或亲自试验的经验。Rod John son通过这本书希望传达的、更为重要的信息正是“循证”的工作方式—————那原本就应该是程序员的工作方式。 
  有意思的是看过这本书的人觉得大牛(Rod John son)很牛,自己也可能很牛,但如何让全世界架构师一起牛起来,还是一头雾水。 
  我们从一个问题开始:如果,给你一个ERP的项目,你会选择什么架构,为什么? 
  Soap?EJB?不论你怎么选择哪一种架构,尽管你可以理直气壮的说这是xx大牛所推荐最佳方案。但Rod John son都会大声告诉你:错了,根本上错了,因为xx大牛的经验根本靠不住! 
  把项目架构在不靠谱的经验上当然危险。循证的核心理念是:一切活动基于当前最佳证据。证据包括两大类:知识和经验。知识大家都很清楚,我们来说说经验。首先看一下经验的效应公式
                         
表面效应 原始效应   伪效应 实际效应 
  从公式中可以看出,大牛的有效经验其实并不单纯。以软件架构为例,假设原始效应是指公司的有效资源及开发团队能力(意味着拥有优质资源的公司,即使选择最差的架构也可能会成功),伪效应指信仰架构是最优架构所带来的精神动力(比较容易理解的例子是,专家给病人吃用淀粉做成没有任何药物作用的“药片”能治好疾病,简称安慰剂效应。表面上伪效应是有用的效应,实际上有害,它意味着将资源浪费在错误的信仰而非正确的信仰上,而未能获得正确信仰的有效收益。),实际效应才是某种架构应用于特定环境的有效性。 
  我们曾经在无数的书籍和文章中看到,EJBJ2EE的核心技术之一;而Rod John son在他的书中竟然宣称,绝大多数的J2EE应用根本不需要EJB。在技术选型的时候,估计都能很清醒的意识到:“技术应该以实用为主”。但我们不免又被大牛和自己的经验所左右。选还是不选EJB?谁也不愿意把自己的项目架构在空中楼阁中,但是怎么样才能获取架构方案真实的效果和适应环境呢? 
  倒推一下经验公式: 实际效应 表面效应 (原始效应   伪效应)。 
  屏蔽掉表面效应上的偏倚(或波动因素),才是实际效应。循证来源循证医学领域,它有一个很有效的方法:随机对照实验(RCT)。这个实验是伪效应的天敌(时不时也出来狠揍伪科学),至少让一半以上的地球人多活至今日。随机对照实验方法很简单,通过一定量的样本,进行结果比较,目的是屏蔽伪效应和原始效应。如做一次《EJBxx类项目适用/不适用》实验,设置500个样本,分成AB两组,a组为实验组使用EJBB组为对照组,使用某个特定的架构。最后收集实验组和对照组的关键数据进行比较,比较结果就能够很客观的反映EJB对某种特定环境是适应性。 
    再关注一下倒推公式,假设实验组和对照组在样本足够的时候能模拟出几乎相同的环境,那么实验组的实际效应应该是比对照组强的那部分,即:实验组实际效应 实验组表面效应 对照组表面效应。通过随机对照实验,经验公式的伪效应、原始效应所对应的外部环境、公司资源、开发团队就可以被最大限度剔除,还原其真实面目。随机的目的是通过抽样减低主观选择样本导致失真,RCT还有单盲实验,最初指让实验组病人吃实验药物,给照组吃设计的一模一样的药片(安慰剂),以避免实验组出现安慰剂效应。后来发现医生会潜意识更关注实验组和忽视对照组也会导致偏倚(病人觉得更受关注而疾病好的更快),设计出双盲实验,即医生和病人均不知病人吃的是药片还是安慰剂。 
  “可是,”有人说了,“我一直都是按照别人/网上/书上的建议来做架构的。要亲自考察各种各样的技术,甚至还有很多项目,还要根据项目情况比较它们的优劣,我可没这份时间。”。事实上,完整的RCT在医学界也存在伦理问题,如:拿病人生命做实验是否符合人类道德。似乎RCT只适用于新药研究(如艾滋病、癌症、sars、甲型H1N1,等等死马当活马医)。但并没有难倒doctor们,他们发明了meta评价方法。让任何一个企业开展500个实验组和对照组做一次《EJBxx类项目适用/不适用》,都不靠谱。可大家往往都忽略了,全球各地至少已经存在50000个以上的《EJB应用于xx类项目成功/不成功》的案例。meta评价方法首先假设有办法收集足够多的样本(meta评价得益于互联网的发展),用RCT的思想对已有资料进行科学理性评价。所以,meta评价方法至少包括四部分: 
  1,收集足够多的样本,包括可获取的企业内外资料、互联网资料、期刊杂志,还有问卷调查。 
  2,形成对照,收集ABC...N组对照信息,通过对照还原真相。 
  3,控制偏倚,设计出能模拟RCT效果的偏倚控制。是不是很像程序设计?所以Rod John son认为循证架构是程序员本该的工作方式。 
  4,分析出它(经验)的成分、特征、适应症、用法、副作用、禁忌。 
  值得注意的是这是四个必要部分,而不是四个个顺序步骤。问题就有点类似于先做架构还是先做需求,在这里主要指先收集样本还是先控制偏倚。当然,一般意义上如果现有大量可靠样本,则先收集样本,再设计偏倚控制。反之,则先设计偏倚,然后收集样本(如先设计偏倚控制,假设使用问卷调查,在问卷调查中加入偏倚控制策略:问题陷阱、交叉验证等等)。循证架构的目的是收集及评价出高质量的架构方法,但同时又要避免被这种意识所引导,造成“主观偏倚”,这是RCT所禁忌的地方。 
  千万别小看RCT的魅力,医学界用它打趴下无数经典,也拯救了无数的生命,如放血疗法、维生素等等。美国新药上市,没有经过RCT根本不让上市。至今没有一位医学界大牛敢出来公开反对RCT,循证的帽子也被扣在几乎任何一个领域:循证经济、循证管理、循证物理。。。。。。包括循证谈恋爱。存在问题的地方就存在循证。  
 
有点啰嗦,总结一下: 
  1,经验效应公式为:表面效应 原始效应   伪效应 实际效应 ,其倒推获得: 实际效应 表面效应 (原始效应   伪效应)。 
  2,屏蔽表面效应上的偏倚(伪效应及原始效应)的有效办法是随机对照实验(RCT)。假设在大样本意义上的近似输入应该有类似输出,那么可以假设:实验组实际效应 实验组表面效应 对照组表面效应。 
  3,在无条件施行随机对照实验(RCT)时,可以采取meta评价方法。 
  4meta评价方法包括:收集大量可靠样本、形成对照、控制偏倚、获取分析结果。 
  正像Rod John son所倡导的:尔等不必向泥胎偶像顶礼膜拜,圣灵正在尔等自身。当然,前提是经验的分享和验证。按照Rod John son的说法,一个合格架构师有足够的知识和经验,更重要的是架构师应该是信息的处理者,而不仅仅是信息的传播者。也就意味者,合格的架构师应该具有收集资料、控制偏倚、提取经验真相,从而获得最适合自身项目的架构方案,而不仅仅是捧着红宝书不断念叨“大牛xx说”或躺在自身经验的柴垛上吃空山。

你可能感兴趣的:(程序架构与设计(Java语言))