這兩天找點(diǎn)時間看了看jbpm，其設(shè)計(jì)思想相當(dāng)不錯，功能強(qiáng)勁，而且?guī)缀鯇?shí)現(xiàn)了工作流模型的所有要求。可擴(kuò)展的思想也是貫穿了整個jbpm的設(shè)計(jì)思路，這都是能看得出來的優(yōu)勢。但是這也僅僅是限于表面的一兩眼，如果真的研究起其代碼來，你會驚訝的發(fā)現(xiàn)Jbpm的代碼漏洞百出，其設(shè)計(jì)思想完全沒有發(fā)揮出來，應(yīng)該說，Jbpm的代碼真是“秀逗”了。下面來舉幾個例子吧。另外，我還沒有看svn上的最新代碼，所以可能有的問題jbpm自己已經(jīng)修復(fù)，那就謝天謝地了。下面的代碼基于jbpm3.1

秀逗1。無中生有

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

秀逗2。畫蛇添足

應(yīng)該是我的基本功不都扎實(shí)，實(shí)在是高不明白下面的代碼在干什么。。。

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

先強(qiáng)制轉(zhuǎn)換成DefaultAuthenticationService，然后再強(qiáng)制轉(zhuǎn)換成DefaultAuthenticationService。。。。
而且這里這么設(shè)計(jì)基本上就把DefaultAuthenticationService實(shí)現(xiàn)的AuthenticationService接口晾在那里了，根本就是應(yīng)該用AuthenticationService這個接口來說話才對。jbpm的service設(shè)計(jì)的擴(kuò)展性很強(qiáng)，可自己配制。但如果這么用service的話，再怎么擴(kuò)展也沒用。

秀逗3。莫“名”其妙

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

秀逗4。固若金湯

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

秀逗5。口徑不一

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

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

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

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