#
構建一個項目，是一件極其復雜的事情。尤其是那種非常復雜的工程。
拿Java來說，構建一個項目的問題有一下這么幾個：
- 項目的組織方式
- 項目的源代碼控制策略
- 項目的依賴控制（工程之間的依賴以及第三方庫的依賴）
- 項目的構建方式
- 項目的構建和發布周期
現在，有一些人還是在使用IDE來進行項目的配置管理的，它的缺點是什么呢？
- 一般的IDE都擁有項目組織的功能。但是，可惜的是。IDE自帶的項目組織功能往往比較弱，IDE采取的項目組織方式都是平行式的，沒有項目的層次感，必須通過逐級命名來體現，比如foo項目下，有兩個子項目，于是分別命名為foo.bar和foo.demo，同理再深一層為foo.bar.web等，項目完全平行化管理（結構未必一定是平行的，但是對于IDE而言，它們是平等的）
- 現在流行的IDE對源代碼控制工具都有非常不錯的支持
- IDE對同一個工作區里的項目依賴的控制作的非常不錯，但是形式相對單一
- 一般都是采用IDE自行手工構建，某些IDE可以給你提供Ant腳本（比如NetBeans），如果采用復雜的構建策略，那么要做很多手工的操作
- 沒法實現自動化構建，隨著項目的增大，構建成本越來越大，構建和發布周期傾向于延長
現在，大多數的Java開發人員都采取了使用Ant腳本進行構建的方式。因為Ant腳本：
- 不會影響你的項目的組織方式，你可以隨意的按照任何方式組織你的項目
- Ant對源代碼控制工具有很好的支持
- Ant可以明確的管理和控制項目的依賴，通過Ivy可以自動下載項目依賴
- 自動化批處理的方式
- 支持構建服務器，可以實現每日構建
但是，Ant腳本也不是一點兒問題也沒有。首先，Ant腳本的重用性不好。一般意義上的Ant腳本重用，就是Copy&Paste。Ant對此沒有什么封裝。其次，Ant使用起來也比較困難，XML格式的腳本不是十分的好寫（有了Eclipse支持以后，強了很多），作為腳本語言，Ant非常的不完善（連字符串處理的功能都非常弱，這一點Ant-Contrib提供了一些好一點兒的支持）。Ant的擴展機制完全基于Java，不能做到即時修改。
除了Ant，在Java中，還可以采用Maven進行項目的構建。Maven項目是一個非常出色的項目。首先，它體現了Apache資深開發人員的項目組織和管理智慧。另外，它以統一有效的方式實現了項目的整個構建生命周期。Maven的黑盒化操作也給項目的配置管理減輕了負擔。如果采用了Maven的話，項目的組織方式、項目的構建方式、項目的發布控制全部迎刃而解。而且你所作的擴展，也是以插件的方式來透明化的起作用的。重用性比Ant高很多。使用起來也非常簡便。
但是，Maven也并不是沒有缺點。首先，Maven的項目組織方式是固定的，雖然這種固定的方式確實非常有道理。但是，如果與現有項目不兼容或者與IDE的項目組織方式不兼容的話，那么就完全不起作用了。比如Eclipse的Plugin項目，PDE的項目組織格式就與Maven2的項目格式完全不兼容。而且，Maven2自身的Manifest文件生成功能比較弱，對于OSGI項目而言，根本沒有可用性（因為要造成重復工作）。由于Maven采用的是黑盒操作方式。操作不透明。你如果想作一些簡單的自定義操作，也必須寫一個Maven的插件。插件的測試、調試和修改都要比Ant困難得多。
那么有什么好辦法呢？我推薦采用Ruby。
首先，Ruby是一種腳本語言，支持的環境有很多，而且還可以采用JRuby來運行。而且，Ruby支持一個類似Make語法的腳本語言，那就是Rake。
Rake腳本其實就是標準的Ruby腳本，擁有所有Ruby擁有的特性（面向對象等）。而Ruby也有非常好的依賴控制系統Gem（我個人認為比目前的Maven的依賴控制系統要好）。由于Ruby是標準的解釋型語言，所以操作都是非常透明的，也可以做到即時修改的效果。所以，用來作構建腳本是非常合適的。
但是，怎么用它來構建Java項目呢？現在已經存在一個基于Rake的Java構建系統了，那就是：Raven。
Raven除了提供一些處理Java的Rake Task之外，它還提供了對Maven Repository的Gem封裝，這樣，你就可以采用Gem的方式來獲取Java的項目依賴了。
Rake是我所看到的第一個用面向對象語言來寫構建腳本的。但是，它也并不是完全沒有缺點的，對Java的支持太少，就是一個很討厭的缺點。
如果想要采用Rake，而且還要做到象Maven那樣好，那么至少要有以下幾個功能（除去Raven已經提供的功能）：
- 新項目的Archetype功能
- Java項目構建生命周期模型
- IDE支持
- 根據源信息生成項目信息網站
目前我能想到的辦法只有一個，就是自己寫（呵呵）。大家有什么高見？
中等收入家庭該如何理財？
專家建議：增加房產投資，安排適當保險，構建基金組合。 作者：陳婷
張平是某建筑企業的生產管理人員，月收入3000元。妻子是一名普通的公司職員，月收入2000元。兩人有一個活潑可愛的孩子，還未滿 周歲。一家三口每個月的基本生活開銷為1500元。另一筆大開銷是交通費，由于張平的工作地點經常都在郊外，也沒有班車可以搭乘，所以他的交通費用每月將 近800元。兩人均為28歲，年輕力壯很少生病，沒有什么醫療費支出，只是小寶寶需要平均每月200元左右的醫療保健費用。這樣算下來，他們每個月可以結 余2500元。
此外，兩人的年終獎勵合計有8000元左右，存款和債券利息有5000元，股利、股息有1000元左右，年度性收入在14000元左右。年度性支出方面，則主要有一些人情往來，大約在1000元左右。另外還要孝順給父母1000元左右。
家庭資產多為存款
細觀他們的家庭資產，"最大頭"的比例就是存款了。其中現金和活期存款在5000元左右，定期存款則有20萬元之多，股票上投資了 25000元，去年還買進了10000元的基金。加上35萬元的自住房，房子面積48平方米。目前，他們的家庭總資產為59萬元左右。由于他們是在結婚前 花了3.5萬元"成本價"從父母處購得的售后公房，所以目前也沒有什么債務。
5年后換購大房子
張平和妻子短期內沒有什么特別大的計劃，倒是希望5年內可以再買一套房子，或者以現有房產換購一套面積較大的房子。因為隨著孩子的逐漸長大，一家三口需要的生活空間肯定要增大，而且對居住環境的要求可能會越來越高。
未雨綢繆累積教育金
今年最讓張平和妻子開心的事情，莫過于兩人在去年有了個愛情的結晶。小孩現在還未滿周歲，要把孩子培養到大學畢業，還需要不少錢。正所 謂"可憐天下父母心"，張平和妻子甚至還希望在小孩成家時，至少能給孩子20萬元。這"教育金"和"子女婚嫁基金"可是不小的費用，還需要努力積累。
考慮增加一定的保障
張平夫妻兩人的單位都有社保和醫療保險，父母均健在，也有社保。但父母現在健康不代表未來沒事，考慮到社保的保障力度不夠，還是有些擔 心他們以后的養老和醫療支出。小夫妻本身的健康醫療及養老儲備也是張平考慮的一個重點問題。張平目前的想法是，他希望自己和妻子退休后每年能有相當于現在 2-3萬元的生活費用。
期待專家的分析和建議
此外，張平認為自己家的財務管理過于松散，為了順利解決孩子的教育費用、自己的買房費用、夫妻倆和父母的醫療和養老費用，希望專家能幫他給出一定的分析和建議，以便他們能更加輕松地完成家庭的各項理財計劃。
專家建議一：資產配置分析
一、財務狀況分析
1.收支分析：張平夫婦目前家庭年度總收入為74000元。家庭總支出為32000元。結余比例為57%。可以看出該家庭是相當節省 的。而且該家庭的收入也比較穩定，主動性收入（68000元）占總收入的92%。但應當看到，隨著家庭新成員的到來和不斷成長（目前還沒有教育性支出）， 該家庭的日常開支將會慢慢提高。而且該家庭目前沒有安排任何商業保險，在這個方面顯然也需要有一些安排。所以該家庭未來的支出預期將會上升。
2.資產分析：張平夫婦目前家庭凈資產已經有59萬元。其中金融資產為24萬元，房產資產為35萬元，金融資產比重為40.7%，還算基本合適。該家庭沒有任何負債，財務穩健。家庭資產配置的主要問題是現金存款部分太高，占所有金融資產的83.3%，需要調整。
3.保障分析：盡管張平夫婦和他們的父母都有社保。但保障程度顯然不足，需要通過商業保險做一定的補充。特別在他們的孩子出生以后，這對小夫妻就更加需要保障了。
二、理財階段、理財重點和理財目標分析
張平夫婦目前才28歲，孩子也剛剛出生。此時正是家庭建設和事業發展的重要階段。在該階段理財的重點應當是安排好家庭生活，同時應當集中精力到各自事業的發展方面，因此投資的安排不宜過于復雜，應當以簡單易操作為主要考慮原則。
張平夫婦對未來有很多設想和安排。他們提出的理財目標主要有：
1.五年后再買一套房產或換購一套大房子，用于改善居住條件。
2.孩子未來直到大學畢業的教育費用。
3.孩子未來的婚嫁基金：20萬元。
4.夫妻兩退休后每年能有相當于現在2-3萬元的生活費用。
其實，目前張平夫婦孩子剛剛出生，自己也很年輕，此時談論30年以后的孩子婚嫁或自己的退休都尚顯太早。目前階段理財的目標應當是將家庭現有的財務和孩子出生以后的家庭保障等方面要安排好。
三、當前財務安排建議
1.增加房產投資：孩子出生以后的確需要更大的生活空間，目前48平方米三人居住顯得太擁擠。同時考慮到他們實際的資產狀況和未來月供 能力，我們建議目前就通過出售現有住房、然后支出現有存款10萬元左右，再負債15萬元來購買一套70萬元左右的房產，使得總居住面積達到75平方米以 上。而完全不必等到5年后再買。那時的房價和現在絕不是一個概念。而且該家庭目前資金充裕，又沒有任何負債，換購一套房產在財務的安排上沒有任何問題。
2.安排適當保險：孩子出生以后家庭保障就顯得格外重要了，應當安排好充足的保障。具體來說，張平夫婦的壽險、大病和意外保險都需 要。孩子也需要安排一定的醫療保險。保險的支出額度應當安排在一個月左右的家庭收入為宜。主要應當安排家庭保障類的保險，儲蓄理財類的保險暫緩。
3.構建基金組合：因為張平夫婦還很年輕，應當爭取在事業上更上層樓。所以在投資上應當盡量簡單。因此，我們建議張平夫婦的金融資產 除保留一部分存款外應當主要通過購買基金來安排，構建一個基金組合，長期投資，讓專家來幫助理財，省心省力。目前的股市投資可暫時保留，但今后也應當擇機 退出，全部通過基金來投資。而且今后每月收入的結余也應當采用定期定量的方式投入到家庭的基金組合中。
——本刊首席理財師 徐建明
專家建議二：投資建議
對于張平先生的理財需要，我們提出以下幾點建議，希望能夠對他有所幫助。
1.對于孩子的“教育和婚嫁基金”
我們建議做個"傻瓜型"的計劃。那就是在與理財專家溝通后，做一個基金的“一籃子”方案，即將貨幣基金、債券基金、股票基金按1:2: 7的比例進行定期定額的投資。由于張平夫婦年紀較輕，承擔風險的能力較強，所以我們的建議中適當增強了股票基金的投資比例。同時，我們也提醒張平先生要在 家庭情況發生巨大變化時，對投資比例進行適時的調整。長期性定期的投入會更好地增加收益，控制風險也無須花費太多精力。
2.對于夫妻倆的購房需求
張平夫婦的購房是為了自住需要，因此我們建議可以每年投入一定比例的資金進入保本增值市場，來進行購房基金的積累。如保本基金、貨幣市場基金、記賬式國債、以及最新發行的儲蓄國債等。這樣既可保持其靈活性，又可以在5年之內尋求適當的時機以按揭貸款形式購入新房。
至于未來是賣了現有房產換購新房，還是增大負債比例購置新房保留現有住房，則要看未來的家庭資產總量和月收入能力。若未來能力足夠，當 然也可以保留現有老房子用于出租，用租金來緩解部分月供能力。若未來家庭積累的資金量不夠，則可以選擇出售后換購大房子，負債額度可以由當時的月收入能力 來計算。
雖然理論上認為月供額度只要不超過月收入的50%就是安全的了，但我們建議月供最好不要超過月收入的1/3，否則對一家三口的基本生活將會產生不小的壓力，甚至淪為“房奴”一族。
3.在張平先生的家庭情況中我們注意到，其本人是建筑企業的生產管理人員，建筑行業是一個受經濟波動影響較大的行業。這對他家庭收入長 期的穩定性有不利的因素存在。因為夫婦二人均只有28歲，所以我們建議張平夫婦現在每年也為自己準備一筆“教育基金”。進一步的“充充電”，學習一些新的 知識和技能來提高自己。在我們看來理財不僅僅是對金錢進行投資規劃，也可以是對自身進行投資規劃，而且或許收益回報會更高，也能更好、更快地實現家庭理財 計劃。
——建行上海市分行盧灣支行 馬鈞潔
專家建議三：保險建議
家庭所面臨的風險不外乎人身損失風險、財產損失風險和責任損失風險。從表面上來說張平一家的財務狀況基本穩定，沒有什么債可“負”，但 是一旦碰到重疾或者意外等不確定因素的發生，不僅會嚴重影響家人的心理狀態，而且會對家庭的財務狀況造成不同程度的沖擊，所以絕對是可不言、但不可不理 的。況且，他們未來還打算購買大面積的房子，估計需要增加債務負擔。
風險的分析應該從兩個角度入手：損失發生的可能性和損失發生后的嚴重程度。正值盛年的張平夫婦的身故可能性很低，但是發生意外事故的風險不容忽視，尤其是張平本人從事的是建筑企業的生產管理工作。萬一有一方發生不測，家庭收入就會減少一半以上。
解決這個問題的最佳途徑之一莫過于人身意外傷害保險，它的最大優勢就是在引起損失的事故發生時提供一筆收入，從而可以彌補損失，緩解生者面臨的財務壓力。
將來購買新房有了負債之后，還應該增加一定的壽險保障。
根據張平的需求，他想為自己和妻子購買養老和醫療方面的保障，以及為兒子選擇教育金之類的險種。但按照他的家庭收入能力，我們建議他暫緩夫妻倆人的養老保險計劃，等到十年以后，也就是37歲、38歲以后再考慮養老保障。
夫妻倆人的醫療保障，則應該從現在開始做起，畢竟他們也是"奔三"的人了，雖然現在年富力強甚至沒有什么醫療費用指出，但再過兩三年肯 定會明顯感覺到身體的亞健康狀態來臨。而且，隨著撫育幼兒所付出的超額體力和精力，張太太的身體狀況可能面臨直線下滑的趨勢。為此，張平可以先為自己和太 太選擇一定的醫療補貼保險和大病保險。孩子方面，如果體質較弱，夫妻雙方的單位又不能負擔任何醫療費用，那么也可以為孩子選擇一份兒童醫療保險，向保險公 司轉移家庭的醫療負擔風險。
——上海合泰保險超市 高逢潔
軟件項目開發過程模型
1.????
什么是軟件項目開發過程模型
項目開發過程模型就是對于項目開發過程的概念建模，從而能夠實現在理論上對于軟件項目開發過程進行量化分析。
?
軟件開發過程模型以
Rational Unified Process
（簡稱
RUP
）為代表，如下圖
圖
1
、
Rational
Unified Process
但是也并不是只有
RUP
一種，比如
Agile Unified Process (
簡稱
AUP)
圖
2
、
Agile Unified Process
?
總體來說，
RUP
是最細化的項目開發過程模型，不管你采用什么樣的開發方式，整個開發過程的每一個過程你都是無法逃掉的（我們后面會討論這個），因為這代表了整個軟件開發實踐的客觀規律，只是在定義上有所不同，側重點上有所不同，對于迭代的看法有所不同罷了。
2.????
為什么要關注軟件項目開發過程模型
如同它的概念所示，軟件項目開發過程就是對軟件項目開發過程的概念建模，從而能夠實現在理論上對于軟件項目開發過程進行量化分析。
?
那么，這種量化的分析到底有能有什么好處呢？
?
我們在引子里說過：任何的軟件項目都有它存在的目的，都是為了解決一些現實中的問題。可以把這個成為這個項目的目的，可以把需要解決的問題的需求稱作這個項目的需求。
?
而對于商用（尤其是企業級應用）軟件項目開發而言，最基本也是最重要的目的就是以最小的成本，在項目交付的期限內，提供穩定的、可靠的軟件，用以解決用戶提交的所需要解決的問題，并且如有可能，必須為現實生活中問題的變更引起的用戶需要解決的問題的變更從而要求的軟件功能的變更做好準備。
?
l????????
為了能夠把客戶的問題描述清楚，必須進行業務建模和需求收集；
l????????
為了能夠把收集完的問題需求轉變成為可以信息化解決的問題并且解決，必須對其進行軟件化設計并進行實現；
l????????
為了保證軟件產品的質量，必須進行足夠多的測試（看看硬件廠商是怎么測試的？）；
l????????
為了能夠讓軟件產品正常運轉，必須進行軟件的部署；
l????????
而在軟件開發的過程當中，對于項目的管理、代碼的管理、還有資源的管理，在哪一個軟件項目開發中能缺少？
?
綜上，對這些過程的建模和定量的分析，并且確定在整個開發過程中各個階段所占的份額和所擁有的重要性，對于保證項目（尤其是大項目）的平穩開發和增強項目開發管理有著重要的作用。
?
并且，確定了項目開發過程模型，對于確定項目管理方式和提供技術、工具支持有著非常重要的作用。
3.????
接下來要討論的
既然我們已經有了一個明確的定義，并且能夠把它分解成為幾個部分（當然，我們將會看到，這些部分本身也是十分復雜的）。那么，看上去下一步，我們的任務就是一步一步的分析每一個部分。
?
但是，且慢，這些部分有些是沒法討論的（比如業務建模，它與用戶的域專家有關，或者跟一些國家、國際標準有關，跟計算機軟件開發沒太多的關系——除非是
IDE
之類的），有些是仁者見仁、智者見智的部分（比如設計和實現），有一些可以不必花太多口舌去討論（比如軟件項目的部署和資源管理），這一點
AUP
給我們開了個好頭，我們現在需要討論的就是：
l????????
需求分析
l????????
測試
l????????
配置管理
l????????
項目管理
?
但就是這么幾個，就足夠我們討論的。事實上，如果能夠對這些問題都全面的分析并且提出自己的見解和解決方案的話，分量足夠一個博士論文（起碼重量上差不多），也許那樣我可以出本書，呵呵，玩笑。
?
我只能盡力的往下分析，但是，我更希望的是大家能夠有所反饋。因為，在軟件設計中很多問題都是隱藏的（像地雷一樣），直到你踩上它為止，你都不會發現它。
?
我很希望能夠有反饋使我避免低級的錯誤。
“
是我們創造了工具，并且使用它們，而不是相反”
任何的軟件項目都有它存在的目的，都是為了解決一些現實中的問題。可以把這個成為這個項目的目的，可以把需要解決的問題的需求稱作這個項目的需求。任何的軟件項目的開發都必然離不開了解需求、根據需求進行設計、根據設計進行實現這些過程。不管是多大的項目，也不管是采用何種開發方式。
?但是，設計的方式卻有多種，沒有誰會規定，只有采用UML圖進行建模才叫設計。也沒有誰規定，只有“設計”好了的項目才能開始代碼實現。
對于軟件項目開發而言，大型的項目和小型的項目所面臨的項目開發的問題是不同的。
一個人幾天就可以完成的項目和幾個小組好幾個月才能完成的項目相比，它們面臨的實際中的開發問題，和開發結束后面臨的維護問題都是不可同日而語的。
而且，技術的角度上看，適合大的項目的開發方式也未必一定適合小的項目。
好了，說了這么多，我只是想說：
綜上所述，軟件開發過程是一個非常復雜的問題，對于做技術的人來說（尤其是做計算機軟件技術的人），解決問題的方式只有一種，分析問題、根據問題設計解決方案、然后實現解決方案來解決問題（解決方案未必一定是軟件）。
分析問題的第一步，就是把現實中的東西轉換成為概念模型，這樣我們才有一個討論和研究的平臺。如果沒有一個明確的統一的概念模型，那么，無論做什么研究都會顯得毫無意義（古代的智者和詭辯論者經常這么干）。
既然我們面臨的問題是軟件項目開發，那么我們第一個要做的就是把它建模，并且對它進行一下研究。
我會在接下來幾篇文章中對它進行詳細的闡述，并且針對我在項目開發中的一些經驗、總結和思考提出我對這個問題設計的解決方案。
目的只有一個，希望針對這個問題作出一些探討。希望能夠拋磚引玉。
當前問題：
流程－
ERP
軟件的死穴？
時間：
2004-03-12
提問者：
quicker??
地址（需要注冊）：
http://www.ceconline.com/DG/NOTE_900001_900002_793863.HTM?dmsource=CECOL_060419_EETCOL
這些年，接觸了不少
ERP
軟件，聽了不少關于
ERP
軟件的推廣說明會，自己也嘗試了好幾種軟件模塊的實際運用，但效果一直不如人意，專家對此也評論不同。說什么的都有，但幾乎沒人點出
ERP
的死穴。
有幾個問題我們必須首先理清。
一、任何一種
ERP
軟件都有其適用范圍，至少到目前為止，還沒有一個軟件可以成為放之四海而皆準的通用軟件。即使，某些聲稱自己是通用軟件的公司也不行。
二、任何一種
ERP
軟件都是建立在一種管理思想或者管理結構上的。我們知道，管理本無定法，也沒有優劣之分，主要看其是否能夠解決問題。軟件不過是這些思想的一種體現形式，同樣也擺脫不了這個約束。
三、實施
ERP
不是目的，
ERP
只是一個系統工具。這幾乎已成共識。我們試圖用一個系統思考的辦法來解決企業各部門之間的協調與資源共享，以達到企業整體經營績效的目的。
四、多數情況下，
ERP
都有個在實際運用中進行二次開發的問題。如果說，實際
ERP
表現有好、壞之分的話，主要還是看軟件公司二次開發的能力。
但是，以上這四點觀念，都無法回避一個事實：現在的
ERP
是建立在流程基礎之上的。因為，有
“
業務流程重組
”
做理論指導，這方面還有
6
西格瑪做旁證。
而我的觀點是，建立在流程基礎上的
ERP
軟件會被流程所困住，流程思路便成了
ERP
的死穴。如果我要界定一下我說的論點的適用范圍的話，那么，我
要說，對中國，對民營企業，
ERP
還很遙遠。因為，我無法窮舉，所以，為防止招來批評，我不得不界定成上述的一個相對狹窄的范圍。
為什么？這是中國的客觀現實所然。
今天的中國市場變化太大了，昨天的英雄，今天可能就成為了失敗者。中國的企業外部環境是多變的。在這種情況下，一個企業想要經營良好，沒有多變的
機制或者更準確說，具備靈活的應對機制，恐怕是很難持久的。進一步講，由于企業經營機制多變，那就要求企業具備動態調整的能力，這種能力從企業實際來講，
就是：組織結構多變、權責多變（也是權責不清的一個原因）、人員多變、流程多變等等。
有人講：唯一不變的真理就是變化。
那么，作為
ERP
軟件開發的公司來講，是不希望你變來變去的，一是軟件設計師在模塊規劃時很難協調，二是二次開發可能因為多變而成了多次開發，軟
件公司也受不了。有的軟件公司為逃避這種責任，干脆把源代碼交給企業，由企業去自行修訂。可是，有多少企業有這樣的強大開發能力呢？
其實，問題既不在于企業多變，也不在于軟件公司不負責任，而是建立在流程基礎上的框架是個死穴。
包括四川維尼綸公司在內一些早期應用過
ERP
的企業曾經談過：
“
。。。我們不得不加班登錄數據，否則第二天其它部門上班便沒法運作。。。
”
這就是
一個很典型的情況。由于流程的限制，上、下部門之間的數據庫是被流程捆綁起來的，所以，流程要求這樣，你不得不先行一步。但是，我們似乎應該思考一下，我
們真的應該這樣嗎？
我們不妨換個角度看看。如果，我們不把流程作為數據庫鏈接的基礎，而是把流程所產生的結果作為基礎，那會是一種什么樣的情況呢？
關注結果而不是關注流程，那么無論流程如何多變，均沒有什么可以擔憂的。
只要結果能夠反應企業的整體經營需要，隨著市場環境的變化，企業可以動態調整自己的組織結構、調整自己的運作流程。需要說明的是人員的調整也同樣不會產生大的影響，而現在的關注流程的方式，倒要受到這方面的影響，使得企業不得不再行投入成本進行培訓。
只有三種情況是例外：企業流程本身比較穩定或變革后流程重新穩定的能力很強；軟件公司的后續開發能力很強（往往有管理顧問做后盾）；企業自身的軟件開發調整能力超強。
否則，應用
ERP
，真應該小心啦。
你們說呢？
評注： 作者提出了ERP對業務處理流程提出了要求，也對ERP依賴于業務流程的程度提出了質疑。本身觀點是比較清晰的。但是，我個人覺得，拋開業務流程的處理而只關注業務處理的結果的話，只會降低ERP系統的價值，失去ERP系統對企業內部資源的統一調配能力和協調能力。所需要關注的應該是怎樣提高業務流程的靈活性和可定義性，在深層次上解決當前企業內部流程不確定的問題，沒有一家成熟的企業規則朝令夕改，雖然目前來看，中國的國情（最好的不一定是正確的，正確的不一定是掙錢的）決定了一個企業要想生存，必須能夠靈活的進行適應，但是這并不一定代表著確立業務處理流程沒有必要，確立公司內部業務處理規則沒有必要，在
解決當前企業內部流程不確定的問題上，ERP的開發企業必須要達到技術上提高業務處理流程的靈活性和可定制性，降低修改帶來的時間和經濟成本，還要結合自身的開發經驗，向客戶推薦當前業內先進的管理思想和管理方式，在另一個方面上提升用戶的價值。
這方面，大家有什么想法？
??? 在這里只是簡單的介紹一些企業應用開發應該采納和借鑒的一些展現層技術、架構和開發方式，之所以稱它們為新，主要是針對技術和趨勢而言，其實他們的概念已經不算是太新的了（已經存在一段時間了），正是因為如此，它們更加具有可借鑒的價值。
???
瀏覽器胖客戶端技術：
??? 無論如何說、無論采用何種技術目前的三層分布式企業級應用也都是網絡應用，它在本質上與其他的網絡應用是有相似性的，我們可以在它們之間作一個類比。
???
就在不遠的以前，網站的用戶界面也是靜態的，雖然很多網站提供了服務端動態網頁的支持，但是用戶看到的卻還是一張張靜態的網頁。用戶與網站之間是一個請求
和交互的過程（本質上就是這樣，看上去也是這樣），用戶通過超鏈接在一個個動態/靜態的頁面之間瀏覽。而所有的處理全部是由服務器來進行的。大多數能夠即
時響應客戶的是Flash或者Applet這種瀏覽器的插件。當然客戶端動態網頁的技術當時也已經存在很長時間了，但是并沒有得到太多的重視。
???
但是，近幾年來，動態網頁無刷新技術逐漸興起起來，它充分利用了客戶端瀏覽器所具備的計算能力，通過借助于DHTML容器的事件機制和非提交形式HTTP
訪問服務器的方法實現了可以在客戶端自行處理用戶請求的基于瀏覽器的胖客戶端，使得使用界面更加友好和易用，而且還在相當的程度上減輕了服務器處理的負
擔。
???
???
再拿二層的分布式企業級應用來作縱向比較，雖然抽象出應用服務器這一層對于數據庫服務器是一種解脫（也為SOA打下了基礎），但是由于當時的網絡應用的技
術所限，真正的用戶體驗是下降了的，胖客戶端的安裝和升級確實比較麻煩，但是一般說來客戶端的安裝問題只是部署和維護企業級應用系統的一個很小的問題。但
對于底層的實際用戶而言，基于網絡HTML技術的客戶端界面可能會好看一些，但是效率、操作性、實時反應的能力都是下降了的。對于底層的用戶而言，鍵盤操
作要比鼠標操作工作效率更高。企業級應用的系統是要給企業做的，而企業的主要目標是創造最大利潤，在這一點上其實很多三層的企業級應用都是對企業級應用所
要達成的目標的一種背離。但是，這主要是因為當時的技術所限，就算是最能代表當時網絡技術的大型商業網站，他們的用戶界面也幾乎全是靜態的HTML網頁。
???
???
綜上所述，可以看出三層分布式的企業級應用系統應該在展現層進行一次革新，應該盡可能的采用瀏覽器胖客戶端的技術，這樣一方面可以充分利用客戶端的計算能
力和資源，緩解服務端壓力，還可以通過快捷鍵、自定義快捷方式甚至自定義宏的方式提高用戶的使用效率和使用體驗。
???
服務端組件化開發技術：
??? Struts
是一個很好的框架，它的靈活性和穩定性是有目共睹的。但是無論如何它給開發人員帶來的工作量和調試起來的難度也是很多的（尤其是在沒有充分體現出分層概念
的企業級應用系統中）。其實難度最終是要轉化到網絡應用的開發上去的。三層的企業級應用系統也是網絡應用，而對于網絡應用而言，業務開發人員和美工（又叫
WebUI？）人員的分工也是比較頭疼的問題。JSP等模板技術于是應運而生，但其實這不過是一種善意的謊言。對于JSP而言業務開發人員還是必須對
HTML有比較深的了解，而且最頭疼的是，除非你把它放在Web容器中運行，否則你決不會知道它到底是一個什么樣子（除非你把你自己的大腦變成一個Web
容器加上一個瀏覽器），JSP Tag的出現并不能解決什么問題，從本質上來說它就是JSP概念的一個延展，可以節省代碼而已（而且帶來更多的復雜度）。
??? 難道真的沒有辦法了嗎？
??? 我們縱向對比一下二層的企業級應用，它開發和維護起來就沒有三層那么麻煩。原因何在？組件已經封裝了絕大多部分的工作，你所需要的只是應用組件、配置組件、添加事件處理代碼而已。
???
從這個方面上來說，還有什么DHTML更好的用戶界面描述語言？設想一下，你可以試圖拿Swing（為什么Swing？——平臺無關）寫一個可以在運行時
動態的改變界面結構、通過樣式描述文件動態改變組件樣式的程序（這一切可以跟一個或多個很完善的腳本語言無縫集成），它會多復雜？
??? 還記得桌面應用的開發嗎？沒有一個像樣的桌面程序沒有自定義組件的，但是它們的自定義組件大多數其實只是基礎組件的組合。
??? 同理，也可以對HTML進行如此開發。
??? 下面給出解決的架構。
???
展現層開發架構：
???? 開發要明確體現出客戶端、應用服務器端、數據庫服務器端的三層概念。數據庫服務端的開發與展現層無關略去不講。
- 客戶端開發：使用JavaScript進行事件處理響應用戶的操作，對組件進行相應的操作，如有必要可以采取遠程服務器端服務調用（既可以調用自己服務器提供的服務也可以調用其他的公用網絡服務，符合SOA的要求）的方式。
- 服
務端開發：展現層組件分為兩部分，動態網頁組件和JavaScript組件。動態網頁組件采用基于組件化的動態網頁框架（比如Tapesrty，為什么不
用JSF稍后再講）。另外服務端開發還有業務邏輯處理服務，其中業務邏輯處理屬于業務邏輯層不再多說，而業務邏輯處理服務和服務的遠程調用以及相應的安全
處理可以采用Spring + Acegi +
DWR的方式（這樣可以既可以實現JavaScript客戶端遠程調用業務邏輯服務，還可以很容易的實現服務的安全公開化，符合SOA的要求）。
??? 為什么這么看重Tapestry而不用JSF呢？
- JSF
的標準還是跟JSP綁在一塊的，雖然有Facelet的存在，但是本身擺脫不了JSP的JSF還是會被JSP所拖累的。我并沒有說JSP一無是處，作為模
板技術而言，JSP已經非常成功了，但是對于JavaScript胖客戶端開發而言，JSP本身容器相關的特性實在是沒什么好處。
- 目前
而言JavaScript是可以進行單元測試的，而Tapestry的Html模板技術使得JavaScript和Html的集成測試達到可能。你可以完
全不管Tapestry而調試JavaScript，調試成功以后再加上Tapestry的組件標簽就可以了。你可以為重要的JavaScript（一些
起粘結作用的Script就沒有必要測試了）寫測試腳本進行測試，而這些全部都是遠離Web容器的。
???
??? 我們的開發人員為什么要遠離JavaScript呢？因為它是動態解釋語言？Ruby也是。只要測試到位，動態語言也可以實現穩定的系統。
??? 運行的效率低？也許吧，但總高過整個頁面刷新，我說的不過分吧。
???
開發人員對JavaScript認識不夠，沒有很好的IDE支持？事實上，根本不必讓開發人員對它認識“夠”，因為他所寫的主要是一些GlueCode，
配置一下組件，把組件之間通過事件結合起來。當然，這些有一部分你可以自己發明一些XML來達到，值得嗎？我個人認為寫動態腳本也好過寫XML（別跟我說
你還可以寫個DTD）。至于IDE的話，我認為，寫JavaScript根本用不著，尤其是在你根本不會寫很多的時候。只要有一個瀏覽器和瀏覽器支持的
JavaScript調試器足夠了。只要組件化做好了，再結合工程模板，那么開發人員就象回到了二層的時代，選擇相應的組件，組合然后就是調試了。比兩層
有優勢的一點是，他不必啟動服務器就可以調試客戶端。
???
這一方面的網絡應用開發先驅是Google（可惜，他們沒用JavaEE技術，呵呵），到現在已經成為一種風潮，對企業級應用開發趕時髦是沒有必要的，但
是技術的發展帶來了新的可能，不管是在開發方面還是在客戶體驗和客戶效率提高上都會有更好的機會，為什么不把握這個機會呢？
??? 末了，SOA完全可以評為今年的軟件開發最流行關鍵詞。呵呵。它的核心概念是什么呢？不要浪費現有的IT資源。
??? 我們現在對于網絡和計算機技術的資源開發和應用的大部分都處于浪費狀態，有政治原因、有商業原因但是還有技術原因。能夠盡可能有效的利用手中現有的資源，對于企業的發展也有相當的積極作用。
地址：http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/
評論：
??? 很久沒有看到這么好玩的東西了。開始還是討論，但是由于
Gavin King的壞脾氣，最后直接變成了批斗大會了。哈哈。
??? 其實Hibernate怎么能夠封殺得掉Spring呢？他們只能自己生氣罷了。
??? 我倒不是太討厭EJB3，可是還要涉及到JDK5.0的技術，對以前的東西的兼容性也不能保證。目前來看，也不見得就比Spring強。
??? 我對他們倒是沒有偏見，但是我還是選擇用Spring。
AOP是一個什么概念呢？
AOP是Aspect Oriented Programming的縮寫，翻譯成中文就是面向方面編程。它是最近幾年流行起來的另一種編程方式。
- 首先，AOP只是OOP的補充，換句話說，Procedure Oriented Programming的工程是很難，也是幾乎不可能使用AOP的。
- 其次，AOP是對OOP系統的縱向切割，從另一個方面上實現了系統解耦
- 再次，AOP給OOP提供了另一種重用的可能。
對于OOP系統而言，系統的解耦主要依賴分層和良好的設計，一般良好的OOP架構沒有不采用分層和設計模式的（當然，分層分得恰當不恰當、模式用得好不好，跟框架的設計者有著直接的關系）。但是，對于OOP系統而言，它只能到達這一步了。
對于系統的必須要求，比如日志、錯誤跟蹤、訪問攔截、權限控制等操作，OOP就很難達到八面玲瓏。
其實，倒不是OOP一定不能實現上述功能的分離和重用，但是由于那又需要更高層次的抽象和封裝，憑空增加系統的復雜性和使用難度，又不利于版本控制和發布控制，一般來說，是得不償失的。
所以，很多開源項目比如Commons Logging等應運而生，它們的存在從一定的意義上解決了這個問題。
但是，還有一種很好的解決方案，那就是AOP（實際上AOP就是為了解決這種問題而誕生的）。
AOP既然是OOP系統的縱向切割，那么它就應該具備以下幾點：
- 切入點（Point Cut）：它需要一個點來切入到OOP系統中去，目前流行的AOP框架都采用從方法切入的方式。
- 切面（Advice）：切入之后，它要做些什么呢？必須可以有一種方式進行定制，目前流行的AOP框架都采用Java代碼實現的方式
- 重用性：一般來說，AOP能帶來的重用一般都是Advice描述文件的重用，目前所有的AOP的Advice都是Java的Class文件，這就提供了一種可能，所有的Advice都可以通過打包成Jar的形式實現重用。
由此可以看出，使用AOP能夠帶來的好處是提供了一種抽象模型的方式、一種重用以前工作的方式（在不更改過去的代碼的基礎上添加新的功能、同時也可以重用過去寫的Advice）。
AOP還有一個好處，就是減少工作量。
因為目前流行的AOP框架的PointCut定義一般都支持通配，這樣就可以實現批量定義和修改。如果代碼有著良好的規范、在良好的設計下，開發和維護工作量的減少會非常可觀。而且對于添加新的功能不必修改原有的架構設計，從另一方面也降低了非常可觀的工作量。
那么AOP在JavaEE企業級應用中能夠起什么作用呢？
- 事務控制：很多業務邏輯方法都需要事務控制，通過通配實現事務控制絕對是一個節省工作量的好辦法，如果再結合IOC更加可以脫離事務控制的依賴，實現事務控制靈活更換，提高了業務系統的重用性
- 權限控制：權限控制到底算不算業務邏輯？如果不算，為什么還要體現在業務邏輯中？通過AOP的方式，可以靈活的實現FilterChain機制，而業務邏輯的代碼可以對其毫無察覺。
- 持久層對象的裝飾和過濾：可以根據需要對持久層操作返回的結果進行裝飾和過濾，甚至替換，而對系統架構沒有任何要求。這是最漂亮和最干凈的做法。
- 系統級別診斷日志：實現可插拔式系統級別日志，這樣在系統正常運行后就可以為了提高系統性能而不費事的去掉它卻不會影響到系統的穩定。
- 業務級別高級抽象：比如可以把工作流支持API封裝，通過AOP的機制實現Mixin，這樣就可以實現工作流支持和原業務邏輯分離，可以分開進行管理，也可以在更高的抽象級別上實現重用。
AOP也不是沒有缺點，它本身就有一定的學習曲線，而且目前為止有具體意愿的好的實踐并不多，而且它也會給你的工程帶來復雜性，它還會給你的代碼增加理解的難度（不管你承認不承認，代碼閱讀的難度確實是跟代碼的耦合程度反相關的——雖然這是設計模式所力圖解決的問題）
但是，目前來看適當的使用AOP，給你的項目提高靈活性和可維護性，是值得的。
什么是容器？
JavaEE原話：“
Containers are the interface between a
component and the low-level platform-specific functionality that
supports the component. ”
翻譯過來就是“容器就是底層的、與支撐平臺相關的、對組件進行功能化支持的接口”。
難以理解？
通俗的解釋就是，容器是一系列為了實現分層的概念而定義的一系列功能的平臺無關的標準。它的主要用處就是平臺無關性和底層操作封裝性（Java的核心哲學）。
說白了，容器就是
Java的核心哲學在企業級應用范圍內的具體實現。
那么使用容器，能給我們帶來多大的好處呢？
- 強制性分層：通過Java的接口定義機制和強類型編譯器的支持，在底層就實現了分層的概念。即使頂層的實現十分沒有經驗，底層的分層還是可以辨認的。
- 底層操作封裝：以服務端應用服務器為中心的三層企業開發涉及到的技術相當麻煩和復雜，但是之間又有相當多的共性，所以進行有效的底層次的封裝是可行的而且是有必要的。這樣開發人員的工作就可以建立在一個穩固的基礎上，而不是靠自己的經驗去應對這些問題。
- 平臺無關性：這個也是Java的核心哲學，至于好處嗎，我就不多說了
- 代碼的重用可能性提高：記住，是可能性。具體的重用性要看開發的方式和開發后代碼的質量。
就JavaEE而言，它的標準里面只有WEB容器和EJB容器，這兩個容器已經充分體現了它們的概念。
但是，還有一種概念上的容器，它的概念與上述概念不同，所以被稱作輕量級容器。
首先，輕量級容器不是接口的抽象，沒有JavaEE概念中的部署和移除，從概念上說輕量級容器就是一個擁有IOC支持的Bean工廠。
從形象的角度上來看，輕量級容器是一個盒子，盒子里面裝滿了貼有標簽的JavaBean，對外界而言，它是一個魔盒，只要給它一個咒語（咒語必須正確），它就能給你一個禮物。
輕量級容器目前而言沒，有相應的標準，但是它的使用范圍卻比真正的JavaEE標準要寬泛得多（誰不喜歡禮物呢？）。
- 首先，它是一個非常好的JavaBean工廠（誰沒用過工廠模式？）
- 其次，它能夠給你的代碼帶來IOC支持（懶人最喜歡的生活方式莫過于東西自己來找它）
- 再次，一般來說，輕量級容器都可以通過動態代理和字節碼增強的方式提供AOP的支持
總而言之，輕量級容器是JavaEE容器概念的一種有力補充，它的用法更加靈活，適用的范圍更廣，從目前的經驗上看，開發、測試和管理起來也要比標準容器對象開發起來簡單。
-
輕量級容器一般不會給你提供分布式和集群的支持，因為它的優點就是靈活而不笨重。
-
輕量級容器就像作漢堡的那兩塊面包，你想吃什么就往里夾，但是漢堡好吃不好吃，主要就在你放進去的東西和搭配的手藝。
-
輕量級容器不能強制的要求你分層
- 輕量級容器的底層封裝一般以模塊加載進容器的方式實現。
-
有的人不愛吃漢堡。
總體評價：
容器是Java的核心哲學的體現，而輕量級容器則是工程師開發文化的體現，它可以很靈活的幫助你，對你沒有什么具體的要求。二者不會出現誰替代誰的情況。具體的使用方式，還得看你在設計時所處的情況。
更正一下：
就JavaEE而言，它的標準里面只有WEB容器和EJB容器是對它的服務端而言的。客戶端還有Application Container和Applet Container兩個容器。
除了關系型數據庫（企業級應用主要的數據持久工具）之外，企業級應用還需要其他的方式進行持久層操作。比如，數據保存在文件中、數據來自或者流向遠程的其
他服務等。這樣持久層的操作就會有3——5種之多（還分有事務管理支持的和沒有事物管理支持的）。
怎么對這么多的操作進行有效的管理，怎么才能使持久層的變更只
限定在持久層的范圍內，怎么才能實現業務邏輯開發人員在開發上不必具有很多的持久層框架經驗（注1），還有就是怎樣實現既可以利用強制和工具輔助的方式使一個新人能夠開發出跟掌握持
久層開發的精髓的核心開發人員同樣質量的代碼（注2）又可以讓老手開發起來非常快捷（熟練工種），更重要的是在業務邏
輯方面物質化、代碼化積累公司的業界開發經驗，這就是我們下面要討論的問題。
我認為，要想實現持久層的修改（注3）與業務邏輯層分離。還要最大可能的把公用的東西抽象出來，最大可能的為培養業務專精人員提供基礎，就必須
要有一個機制，實現把持久層的任務交給持久層去作。
這是什么意思呢？
就是在系統基礎架構上，實現業務邏輯層和持久層的明顯松耦合（業務邏輯層根本不必知道持久層到底是什么介質和實現方式）。
但是作為業務邏輯層的對象，數據的持久化操作是它所不能避免的東西，也就是說，它不可避免的會和持久層打交道。
那么怎樣在代碼的級別實現和持久層打交道還不跟持久層相關呢？
這就是要在下面給出的總體設計。在這里簡單的介紹一下用到了三個技巧，一個是
IOC，一個是
Command模式，還有一個就是CallBack的概念。
IOC就是著名的好萊塢模式——你不用來找我，我會自己去找你的，而CallBack通俗一點說就是“你要做什么，你告訴我，到時候我會通知你，并把你想要的東西帶來的”。
業務邏輯對象不可避免的要對持久層進行操作，但是它對持久層的操作本身可以抽象成為一個Command對象，由注入到業務邏輯對象中的DAO來負責操作。說通俗點兒就是
說，對業務邏輯對象（BO）而言它是把一個任務說明書（CommandCallBack）給了一個它自己都不知道是從哪里來的叫做DAO的家伙（IOC），然后跟他說：
“你拿著它，按它的指示去把這事兒給辦了吧。”；業務邏輯對象知道“這事兒”是什么事兒，因為任務說明書是有名稱的，但是至于任務說明書的內容，它就不清
楚了。具體的事情DAO和任務說明書清楚，但是業務邏輯對象只是一個交接。換句話就是說，通過這么一個交接手續，把持久層的東西還給持久層了。業務邏輯對
象只想知道“這事兒”辦完的結果，事實上本來就應該這樣。
整體設計上面，涉及到了幾個持久層開發的基本的技巧，除了IOC、CallBack之外，還有DAO和容器管理。
DAO的模式其實也不是什么新鮮的搖滾Rock'n'Roll了，企業級應用要的就不是新鮮的東西（注4）。這個方式里面用的DAO是通用型的DAO，通
用型的DAO的優點就是接口統一，框架比較容易理解。但是缺點也十分明顯，那就是它本身的靈活性是值得懷疑的，JDBC就是一個統一的接口，結果呢，直接
用它就會導致SQL遍布代碼，這本身就增加了管理的復雜度，本來就是來封裝持久層的，結果跟沒封裝沒有區別，那么這個工作就是值得懷疑的。非通用型的
DAO倒是可以解決這個問題，但是非通用型的DAO就太靈活了，沒有辦法對它進行良好的封裝，而且對于建筑在持久層的基礎之上的業務邏輯層架構而言，這種
靈活性導致了只能對業務邏輯操作進行粗放式的封裝，可重用的東西相對沒有使用通用型DAO的時候多了。還有就是非通用型DAO的開發上面想要實現代碼重用
也是比較麻煩的（需要良好的設計）。
至于容器管理嗎，明天再談。
注1：如果業務開發人員具有很多的持久層框架經驗，當持久層框架更
換時，必然會造成他的極度不適應，這通常是系統移植成本很高的原因之一
注2 ：這是有可能的，類比一下C++和匯編語言，用Eclipse和用手工進行重構
注3：包括庫表修改、框架更換和方式的修改——事實上，如果業務邏輯發生了修改，那么持久層可能必須得改，但是如果持久層封裝的好的話，反之未必亦然
注4：公司重要的事情是盈利，根據技術辯證法，任何一個技術有有其優點也有其缺點，都有其適用和不適用的地方，新鮮的技術往往由于是對已有技術的革新，所
以在一段時間內會有很多潛在問題，作為愛好者去試用去跟技術的負責人聯系當然是沒問題，但是作為企業，對產品是質量要負有法律責任的，一般的公司當然都不
會愿意當新技術的小白鼠。相對而言，舊的技術由于擁有廣泛的使用，優點和缺點廣為人知，熟練開發人員也比較容易找到，可以在開發中規避其自身的缺點。當
然，不新鮮的也得看著要，得根據實際情況再作決定。