這兩天找點時間看了看jbpm，其設計思想相當不錯，功能強勁，而且幾乎實現了工作流模型的所有要求。可擴展的思想也是貫穿了整個jbpm的設計思路，這都是能看得出來的優勢。但是這也僅僅是限于表面的一兩眼，如果真的研究起其代碼來，你會驚訝的發現Jbpm的代碼漏洞百出，其設計思想完全沒有發揮出來，應該說，Jbpm的代碼真是“秀逗”了。下面來舉幾個例子吧。另外，我還沒有看svn上的最新代碼，所以可能有的問題jbpm自己已經修復，那就謝天謝地了。下面的代碼基于jbpm3.1

秀逗1。無中生有

看到最核心的JpdlXmlReader代碼真實欲哭無淚，如果好好精簡精簡，至少能踢掉1/3的代碼。而其中甚至有些無中生有的代碼：
我們看到，如果符合之前的條件，就用代理類來代理org.jbpm.taskmgmt.assignment.ActorAssignmentHandler這個類，但是找了好半天也沒有找到這個類。。。。 難道是讓用戶在自己的項目中用這個類么？還是為了兼容原來的程序，，就算是其中一種，但是，可但是，這個條件根本就不可能滿足，也就是說這是段廢話，而且還無中生有的出來個ActorAssignmentHandler。。

秀逗2。畫蛇添足

應該是我的基本功不都扎實，實在是高不明白下面的代碼在干什么。。。

??public?void?setActorId(String?actorId)?{
????DefaultAuthenticationService?authenticationService?=?(DefaultAuthenticationService)?services.getAuthenticationService();
????DefaultAuthenticationService?defaultAuthenticationService?=?(DefaultAuthenticationService)?authenticationService;
????defaultAuthenticationService.setActorId(actorId);
??}

先強制轉換成DefaultAuthenticationService，然后再強制轉換成DefaultAuthenticationService。。。。
而且這里這么設計基本上就把DefaultAuthenticationService實現的AuthenticationService接口晾在那里了，根本就是應該用AuthenticationService這個接口來說話才對。jbpm的service設計的擴展性很強，可自己配制。但如果這么用service的話，再怎么擴展也沒用。

秀逗3。莫“名”其妙

Jbpm中變量的名字真的莫名其妙，很多明明是Map的類型他叫xxList，而不是Map的類型，他卻叫xxMap。這個地方我相信應該是能體現出程序員編寫程序的嚴謹性的地方，而Jbpm作的還不夠好。

秀逗4。固若金湯

Jbpm的擴展性貫穿始終，但是在最重要的泳道的擴展上卻小家子氣起來。看看泳道類代理的擴展代碼。
寫的很明確，如果泳道使用表達式來表示的那么就用代理類來代理處理表達式。。我本想，太好了，寫我自己的表達式，然后代理交給Acegi來根據表達式分配ActorId，但是，可是，但可是。他的代理類居然是寫死的，寫得就是自己的java.identity包里面的東西，不是說java.identity設計的不好，但是一個綜合系統的用戶角色管理系統是不可能跟著你的jbpm走的。強行要加入的java.identity的設計有點保護自我的意思，真的固若金湯，讓我結合acegi的想法又是難上加難。（不過還是有辦法的。大家自己找找看）。

秀逗5。口徑不一

口徑不一就是指兩個程序部分的結合不一致。這種例子很多，我舉一個程序和xsd的沖突的例子。
Instantiator是jbpm代理里面一個比較不錯的概念。代理功能之一是生成代理的類的實例，而Instantiator則是負責生成實例的機制，這個Instantiator設計的不錯，可以在配制文件中的config-type屬性來擴展。看程序。
這里的設計很人性化，可以根據configType來用自己的構造器，但是xsd卻不這么想。
可以看到它限制了4種類型，別說使用自己的構造器了，就連他自己的XmlInstantiator都不再考慮范圍之內，真是大義滅親呀。。

構造器來這里的作用很大，我寫了自己的spring構造器，構造的時候使用beanFactory來構造，這樣就算是存在數據庫里面的class也能當作spring的bean來處理。但是如果用xsd的話就會導致交驗錯誤，所以索性把xsd去掉了，還好一切正常，就是感覺別扭點。

秀逗N。。。 能夠看得出來Jbpm需要提高的地方還很多。但是這些問題應該是一些開發人員的小疏忽，相信在以后的版本中可以改進。不管再怎么秀逗，Jbpm在工作流中仍然保有著強勁的地位，對BPM模型的實現也作的最為全面。而jbpm的par熱部署和IDE也是整個系統中的兩大亮點，這些優點都是不可不提的，所以我仍舊支持Jbpm，希望他能更加迅速的發展壯大起來。。。。

PS：文中錯誤之處還望大家指出，我希望有些“秀逗”是我自己秀逗了。