InfoQ上登了这么一篇文章: 为什么Java开发者憎恨BPM

作为一名在专业BPM公司工作做了3年的技术人员，我马上被标题吸引了。通读全文之后，觉得虽然组织和文法有点乱，内容还是蛮有些道理的，总结起来，BPM被开发者“憎恨”的原因有下面几点：

1. 强迫开发者使用点击和拖拽的方式为流程和UI建模，从而失去了编码的灵活性和维护效率
2. 追求让业务人员自己建模，而实际上没有哪个业务人员愿意做这种事
3. 一些BPM建模工具功能简陋，不能解决现实的业务问题
4. 没有免费或开源的版本，因此很难对它们进行评估
5. 一些BPM产品就像早期的UML建模工具一样，只能用来“画画图”，最终要让系统运行起来，还需要编码，而且编码工作量不小
6. BPM产品通常缺乏Java开发领域常见的测试工具，自动部署脚本等“基础设施”，从而严重影响开发效率
7. 上面的所有问题并不仅仅是BPM的问题，而是存在于更广泛的领域，比如BRMS（业务规则建模系统）、MDD（模型驱动开发）、DDD（领域驱动开发）

这些问题中，我们的合作伙伴也曾提到过几条。开发人员，尤其是熟悉了J2EE架构的开发人员们，往往对这种自动化的“反动”开发方式非常抵触

那让我们来逐一分析一下：

1. 可视化建模：其实从4GL时代起，UI的可视化建模，就成了企业应用软件开发环境的标准配置，j2ee领域也不例外，没人愿意纯用代码一点一点调整界面效果；在这方面不存在需不需要的问题，应当关注的是建模环境是否直观、方便，以及人机交互方式的灵活程度；至于业务流程的可视化建模，实际上出自同样的需求——直观表达、方便调整，只是由于推出时间尚短，开发人员还没有形成使用习惯，各个厂商的产品也都不够成熟；
2. 业务人员建模：老实说，在现阶段，我也认为这只是一个“美好”的愿望罢了，哪个业务人员愿意给自己找这个麻烦呢；不过，话说回来，使用BPM模型与业务人员沟通，绝对是有效的方式；特别是组合BPM与UI，快速搭建的系统原型，往往可以精准地定位需求；
3. BPM套件构建的系统不能符合业务要求：这个问题得从两方面看，一方面，有些BPM产品确实过于简单，建模工具本身表达能力有限，又不能灵活扩展，面对实际业务当然束手束脚；另一方面，BPM产品诞生之初就是要解决跨部门、跨组织、多种角色和异构系统交互问题的，对于不适合的领域，比如图形处理、密集运算，本来就不擅长。所谓“术业有专攻”是也；
4. 缺乏开源/免费产品，不利于评估：没错，BPM市场还年轻，产品开发工作量却不小，开源产品的成熟还是需要一段时间的，但基本上所有主流商业产品都是很配合客户评估（废话，呵呵），开源领域的jBPM也不妨尝试一下。
5. 可视化模型只是“表面功夫”，实际需求还要编码来解决：诚然，没有不编码就能实现所有业务需求的magic tool，不过，编码的多少却并不仅仅是个量的问题；所谓优秀的BPM产品，就是要将属于流程的、易变的逻辑抽象出来，由模型来应对这部分（很多时候还会结合规则引擎，这里先不展开了），而让代码去处理较为固定的逻辑，特别是密集运算、大规模数据处理类的逻辑；
6. 缺乏自动化测试和部署工具的支持：这的确是当前大多数BPM工具的通病，不过，随着产品成熟度的提高，问题正在逐步解决（比如我们公司的产品现在就提供自动化部署的支持，也能通过JUnit和SOAPUI进行单元测试）
7. 不仅仅是BPM的问题：呵呵，这看上去更像优点，如果你认为领域建模是有意义的、模型驱动开发的思想是先进的，为什么不尝试一下BPM呢？

总之，BPM不是银弹，它有自己的问题和缺点，但在适合的领域，它可以工作得很出色，随着整个产业的成熟，它还会越来越好。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

一般来说，根据所谓好莱坞原则，我们不应该在子类中显示调用超类的方法，而是通过重写超类的方法来实现特殊的逻辑，以此来避免循环依赖。不过，调用超类中被重写的同名方法，通常是可以接受的，比如：

Class A
{
  public void go()
  {
     System.out.println("do by A");
  }
}

Class B extends A
{
  @Override
  public void go()
  {
     System.out.println("do by B");
     super.go();
  }
}

如果超类要做的事，总在子类之前，或者之后，是没有问题的，而一旦子类do的前后各需要一段公共的代码，这个办法就行不通了。

于是我们干脆把一个方法拆成两个，其中一个“大”方法调用另一个“小”方法，由子类去重写那个小方法，这样子类干脆就不用掉父类的方法了，显得更加纯粹：

abstract Class A
{
  public void go() //大方法
  {
     prepare()
     going();
     clearup()
  }

  abstract public void going(); //小方法

  protected void prepare()
  {
     System.out.println("prepare by A");
  }

  protected void clearup()
  {
     System.out.println("clearup by A");
  }
}

Class B extends A
{
  @Override 
  public void going() //重写小方法
  {
     System.out.println("do by B");
  }
}

问题是，如果Class B还有子类呢，它自己也需要在子类的执行逻辑前后插入一些东西，难道又把doing这个“小”函数拆开？这是不是太复杂了点？再说我都不知道怎么跟下面的“小小”函数起名字了 。当然，让子类反过来调Class B的函数更不好，不但违反了前面的“Don't call me”原则，而且本身就很麻烦——每个子类都得写。

有没有更好的办法呢？  看来这个问题没写清楚，引起了一些误会，有必要进一步解释一下。首先，我这里并不是想验证或者实践某种模式，确实是一个实际的开发项目遇到了需要权衡的地方。

目前我的设计大致是像下面的样子：

只所以选用继承结构，是因为子类所代表的几个概念与父类在自然意义上确实是"is a"的关系，并且在子类间是互斥的；而且A/B/C这几个类都很稳定，可能发生的变化主要是B可能会增加子类B3,B4，或者A会增加子类D,E之类的。

使用它们的客户程序在获得一个实例之后，一般情况下只会调用它们的go方法，也就是说，不关心具体的实例是属于哪种类型的。当然，有很多方式都可以实现这个需求，而我关心的是，怎样才能让可能新增的B3、B4、D、E这些类实现起来最简单、可靠。所以，最终还是选择了逐步细分函数的方式。

代码如下：

abstract Class A
{
  public void go() //大方法
  {
     prepare()
     going();
     clearup()
  }

  abstract public void going(); //小方法

  protected void prepare()
  {
     System.out.println("prepare by A");
  }

  protected void clearup()
  {
     System.out.println("clearup by A");
  }
}

abstract Class B extends A
{
  @Override 
  public void going() //重写小方法
  {
  	 beforeRun();
  	 run(); //小小方法
  	 afterRun();
  }
  
  abstract public void run();
  
  protected void beforeRun()
  {
  	 System.out.println("beforeRun by B");
  }

  protected void afterRun()
  {
  	 System.out.println("beforeRun by B");
  }
}

Class B1 extends B
{
  @Override 
  public void run() //重写小小方法
  {
     System.out.println("go by B1");
  }
}

Class B2 extends B
{
  @Override 
  public void run() //重写小小方法
  {
     System.out.println("go by B2");
  }
}

Class C extends A
{
  @Override 
  public void going() //重写小方法
  {
     System.out.println("go by C");
  }
}

这样，B在自己的层次，“要求”本类别的Class在go的时候，必须按顺序调用beforeRun和afterRun，新增的B?子类只需实现自己的run方法即可被正确使用；万一真有很特殊的情况，新的子类希望在go的时候不要调用beforeRun或者afterRun，那么用一个空函数覆写它们即可。

反之，如果beforeRun/afterRun这样的函数需要B?子类来调用，那么绝大多数子类都要编写调用的代码，也包括将来可能扩充的，这显然造成了一定的代码重复。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

对象

本地对象

所谓"native object"，是指“独立于宿主环境的ECMAScript实现提供的对象"，目前即是ECMA-262标准定义的类：

Object         Function         Array         String

Boolean     Number         Date          RegExp

Error           EvalError        RangeError    ReferenceError

SyntaxError    TypeError   URIError

Array 

在我用过的所有语言中，Javascript中的数组是最爽的了（当然也只有JS是动态语言，呵呵）： 既可以像普通数组一样访问，又可以像类实例一样调用它的属性和方法。像下面这样：

var testArray=[3,"17",6.5];

alert(testArray.length);

从上面也可以看出，由于弱类型语言的特点，数组中的元素可以不必同类型，甚至不必有什么关系；当然，取出的时候也不必做什么类型转换——这可比Java里又要定义超类或接口，又要来回来去地downcast/upcast方便多了。

数组的大小是完全动态的，需要使用的时候，直接赋值就好了。如：testArray[25]="red"；这时，如果下标0-24还没有使用过，它们对应的元素会被置为null，而数组的length属性会变为26。这个特性说明，一个“稀疏”数组很会浪费空间的。

当然，企图在一个元素被赋值之前就使用的话，还是会出错的。

数组有两个很有用的方法：join和push，两者结合，可以大大提高字符串连接的效率，如下：

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

基础

运算符

void

以前从来没用到过的运算符，它的好处是总返回undefined，这样当在超链接中调用的时候，就不会导致当前页面的重定向。例如：href="javascript:void(window.open('about blank'))" （这当然是a标签的一个属性，不过直接写html代码会被当作一个真的超链接，只好这么写了）

位运算

js也支持位运算，当然很少会遇到，我只在Walter Zorn Graphic library里见到过。这是一个很牛的JS库，完全不借助任何插件实现跨浏览器的矢量图绘制，其中大量使用了位运算来提高性能。

位运算符包括：与（&），或（|），非（~），异或（^），左移（<<），有符号右移（>>），无符号右移（>>>）

逻辑运算符

逻辑运算符本身很常见，需要注意的是哪些值会被自动转换为逻辑上的true or false：

true：对象；除0以外的任何数字

false：数字0；undefined；null；NaN

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

这篇本来早就该写了，一个是自己懒，另一个是上周javaeye网站好像有点问题，每次保存都丢一半文字，也不报错，搞得我郁闷之极。

基础

• null：表示尚未存在的对象，注意，尽管尚未存在，也是个对象啊，所以用typeof检测一个null值变量的结果是Object；不过，为了便于写if语句，在js中，"undefined==false", "null=false", 因此，"undefined==null"。
• 整数：最容易犯的错误就是，忘了070其实是个八进制数，相当于十进制的56；
• 浮点数：“在进行运算之前，真正存储的是字符串”——这应该是解释执行的本质决定的吧——直接后果是，alert(0.8)这样的语句可以正确输出，而alert(2*0.8)的输出就成了"2.40000000000000003"
• 数字边界：数字有几个边界值，分别是Number.MAX_VALUE(最大值), Number.MIN_VALUE(最小值), Number.POSITIVE_INFINITY(正无穷), Number.NEGATIVE_INFINITY(负无穷), Infinity(无穷大，-Infinity，这个有点莫名其妙，不知道为啥又搞出一套)；特别地，还有一个isFinit(iNumber)函数来判断数字是否为无穷大。
• NaN：一些需要数字作为参数的函数，当传入的实参无法转换为数字时，往往会返回这个值；关于NaN，最重要的就是要记住NaN!=NaN，因此判断一个变量是否为NaN，一定要使用isNaN(var)函数。
• 将字符串转换为数字：sVar.parseInt()是最常用的函数，也最容易出错，为了保险起见，最好每次调用的时候，都加上“进制”的参数，比如：a.parseInt(10)，就制定了按十进制转换字符串a；Number(sVar)也是一种转换方式，不同的是，它要求整个字符串都得是有效数字，因此Number("4.5.5")将返回NaN；
• 判断变量类型：一般情况下，可以先用typeof 运算符，如果结果是"object"，再用instanceof来判断；奇怪的是，不知道是ECMAScript标准的问题还是IE实现的问题，instanceof不认为原始类型值的变量是对象，而使用constructor属性似乎可以应付所有类型的变量，如下：

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

《Javascript高级程序设计》（Professional JavaScript for Web Developers），一本好书，非常适合做Web客户端开发的入门教材。

现在开发程序和以前有了很大不同，碰到新技术，都是先google一些sample code，然后照葫芦画瓢，就写起代码来了。尽管这不利于对技术的全面把握，却也是不得已的事情（哪个项目有时间等你慢慢由浅入深呢）。不过，等用了一段时间，会慢慢发现经常困扰自己的都是些基础问题，这时，就应该抽空读读书，梳理一下头脑中零散的知识了。所选的书既要全面系统地介绍相关知识，又要与实践充分结合。《Javascript高级程序设计》正是这样一本书。（怎么感觉像广告，呵呵）

下面记录一些阅读的收获，它们或者帮我弥补了知识的不足，或者印证了实践的手段，还有一些为以后进一步深入铺平了道路。

渊源

• Javascript的鼻祖是C--，哈，有趣的名字，本想表达简洁的含义，可惜程序员们未必领情
• Javascript诞生于Netscape，时过境迁啊
• Javascript的语言核心标准为ECMAScript，它还有个大名鼎鼎的同胞兄弟，Flash中的ActionScript
• DOM也是不可或缺的一部分，
• BOM也是，尽管很不标准，有些功能还非它不可

基础

• String类型的变量是被存放在栈（stack）里的，够惊人吧，可惜没说清到底是怎么实现的

• undefined值不等同于未声明的值，不好理解吗，就是这样

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

基于Web的应用程序，经常需要在页面中作些简单的计算，用作数据提交前的验证，或者给用户提供更友好的信息。但由于十进制小数并不总能用二进制小数精确表示，在进行小数运算时，经常会出现“莫明其妙”的误差，比如“33*2.46=81.179999999999999”之类的。如果要在页面上显示计算结果，特别是当这个结果表示金额的时候，误差通常是不可容忍的。

网上有人说Javasript不能做精确运算，所以会出现误差云云。这当然是不对的，这种情况应该是由计算机二进制表示的本质决定的。应该说，Javascript的表现其实还好一些，因为在数字进行运算之前，我们总是可以得到它的精确表示（字符串）。

解决问题的基本思路就是牺牲速度换精度，逐位进行运算，并且自己在程序逻辑中实现进位。为此，Java提供了BigDecimal类。而在Javascript中，我们就没这么幸运了，没有现成的类库可供使用。可能是制订规范的人也认为没必要使用JS来做“科学计算”吧。

我以前做的项目中，经常会碰到计算金额总价、合计、总计之类的“商业计算”，对精确小数运算的需求还是比较迫切的，所以自己开发了一个小数运算的“类”。实现这个类的时候，使用了投机取巧的办法：把小数转换为整数，运算完成后，再转换回去。它唯一能解决的问题就是：避免十进制小数和二进制小数之间的转换误差；它不能提高运算的精度（有效数字），也不能扩大数字的表示范围。

使用方法如下：

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

近期做了一个POC，需要在浏览器端做一些日期的处理工作，除去其中跟公司产品相关的部分，其它的代码还是比较通用的，主要有两个功能：

1. 根据一个Date对象获取相对应的特殊时间点，比如一天、一个月或者一年的起止时间；
2. 在一个Date对象上加减相应的时间值

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师