#
用sonar來管理我們的代碼并提高我們的代碼質量，他能把cobertura，checkstyle，findbugs較為完美的結合起來，主要產生的報告特別漂亮，而且有其參考性。
http://docs.codehaus.org/display/SONAR/Install+Sonar
本文為大家介紹軟件設計中的一些原則，都是經過長期經驗總結出來的知識，每一個程序員都應該了解，相信對大家在進行軟件設計的過程中會有很大幫助。
Don’t Repeat Yourself (DRY)
DRY 是一個最簡單的法則，也是最容易被理解的。但它也可能是最難被應用的（因為要做到這樣，我們需要在泛型設計上做相當的努力，這并不是一件容易的事）。它意味著，當我們在兩個或多個地方的時候發現一些相似的代碼的時候，我們需要把他們的共性抽象出來形一個唯一的新方法，并且改變現有的地方的代碼讓他們以一些合適的參數調用這個新的方法。
參考：
http://en.wikipedia.org/wiki/KISS_principle
Program to an interface, not an implementation
這是設計模式中最根本的哲學，注重接口，而不是實現，依賴接口，而不是實現。接口是抽象是穩定的，實現則是多種多樣的。以后面我們會面向對象的SOLID原則中會提到我們的依賴倒置原則，就是這個原則的的另一種樣子。還有一條原則叫 Composition over inheritance（喜歡組合而不是繼承），這兩條是那23個經典設計模式中的設計原則。
Command-Query Separation (CQS) – 命令-查詢分離原則
查詢：當一個方法返回一個值來回應一個問題的時候，它就具有查詢的性質；
命令：當一個方法要改變對象的狀態的時候，它就具有命令的性質；
通常，一個方法可能是純的Command模式或者是純的Query模式，或者是兩者的混合體。在設計接口時，如果可能，應該盡量使接口單一化，保證方法的行為嚴格的是命令或者是查詢，這樣查詢方法不會改變對象的狀態，沒有副作用，而會改變對象的狀態的方法不可能有返回值。也就是說：如果我們要問一個問題，那么就不應該影響到它的答案。實際應用，要視具體情況而定，語義的清晰性和使用的簡單性之間需要權衡。將Command和Query功能合并入一個方法，方便了客戶的使用，但是，降低了清晰性，而且，可能不便于基于斷言的程序設計并且需要一個變量來保存查詢結果。
在系統設計中，很多系統也是以這樣原則設計的，查詢的功能和命令功能的系統分離，這樣有則于系統性能，也有利于系統的安全性。
參考：
http://en.wikipedia.org/wiki/Command-query_separation
You Ain’t Gonna Need It (YAGNI)
這個原則簡而言之為——只考慮和設計必須的功能，避免過度設計。只實現目前需要的功能，在以后您需要更多功能時，可以再進行添加。
如無必要，勿增復雜性。
軟件開發先是一場溝通博弈。
以前本站有一篇關于
過度重構的文章，這個示例就是這個原則的反例。而，WebSphere的設計者就
表示過他過度設計了這個產品。我們的程序員或是架構師在設計系統的時候，會考慮很多擴展性的東西，導致在架構與設計方面使用了大量折衷，最后導致項目失敗。這是個令人感到諷刺的教訓，因為本來希望盡可能延長項目的生命周期，結果反而縮短了生命周期。
參考：
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
Law of Demeter – 迪米特法則
迪米特法則(Law of Demeter)，又稱“最少知識原則”（Principle of Least Knowledge），其來源于1987年荷蘭大學的一個叫做Demeter的項目。Craig Larman把Law of Demeter又稱作“不要和陌生人說話”。在《程序員修煉之道》中講LoD的那一章叫作“解耦合與迪米特法則”。關于迪米特法則有一些很形象的比喻：
如果你想讓你的狗跑的話，你會對狗狗說還是對四條狗腿說？
如果你去店里買東西，你會把錢交給店員，還是會把錢包交給店員讓他自己拿？
和狗的四肢說話？讓店員自己從錢包里拿錢？這聽起來有點荒唐，不過在我們的代碼里這幾乎是見怪不怪的事情了。
對于LoD，正式的表述如下：
在《Clean Code》一書中，有一段Apache framework中的一段違反了LoD的代碼：
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
這么長的一串對其它對象的細節，以及細節的細節，細節的細節的細節……的調用，增加了耦合，使得代碼結構復雜、僵化，難以擴展和維護。
在《重構》一書中的代碼的環味道中有一種叫做“Feature Envy”(依戀情結），形象的描述了一種違反了LoC的情況。Feature Envy就是說一個對象對其它對象的內容更有興趣，也就是說老是羨慕別的對象的成員、結構或者功能，大老遠的調用人家的東西。這樣的結構顯然是不合理的。我們的程序應該寫得比較“害羞”。不能像前面例子中的那個不把自己當外人的店員一樣，拿過客人的錢包自己把錢拿出來。“害羞”的程序只和自己最近的朋友交談。這種情況下應該調整程序的結構，讓那個對象自己擁有它羨慕的feature，或者使用合理的設計模式（例如Facade和Mediator）。
參考：
http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge
面向對象的S.O.L.I.D 原則
一般來說這是面向對象的五大設計原則，但是，我覺得這些原則可適用于所有的軟件開發。
Single Responsibility Principle (SRP) – 職責單一原則
關于單一職責原則，其核心的思想是：
一個類，只做一件事，并把這件事做好，其只有一個引起它變化的原因。單一職責原則可以看作是低耦合、高內聚在面向對象原則上的引申，將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。職責過多，可能引起它變化的原因就越多，這將導致職責依賴，相互之間就產生影響，從而極大的損傷其內聚性和耦合度。單一職責，通常意味著單一的功能，因此不要為一個模塊實現過多的功能點，以保證實體只有一個引起它變化的原因。
Unix/Linux是這一原則的完美體現者。各個程序都獨立負責一個單一的事。
Windows是這一原則的反面示例。幾乎所有的程序都交織耦合在一起。
Open/Closed Principle (OCP) – 開閉原則
關于開發封閉原則，其核心的思想是：模塊是可擴展的，而不可修改的。也就是說，
對擴展是開放的，而對修改是封閉的。
對擴展開放，意味著有新的需求或變化時，可以對現有代碼進行擴展，以適應新的情況。
對修改封閉，意味著類一旦設計完成，就可以獨立完成其工作，而不要對類進行任何修改。
對于面向對象來說，需要你依賴抽象，而不是實現，23個經典設計模式中的“策略模式”就是這個實現。對于非面向對象編程，一些API需要你傳入一個你可以擴展的函數，比如我們的C 語言的qsort()允許你提供一個“比較器”，STL中的容器類的內存分配，ACE中的多線程的各種鎖。對于軟件方面，瀏覽器的各種插件屬于這個原則的實踐。
Liskov substitution principle (LSP) – 里氏代換原則
軟件工程大師Robert C. Martin把里氏代換原則最終簡化為一句話：“Subtypes must be substitutable for their base types”。也就是，子類必須能夠替換成它們的基類。即：子類應該可以替換任何基類能夠出現的地方，并且經過替換以后，代碼還能正常工作。另外，不應該在代碼中出現if/else之類對子類類型進行判斷的條件。里氏替換原則LSP是使代碼符合開閉原則的一個重要保證。正是由于子類型的可替換性才使得父類型的模塊在無需修改的情況下就可以擴展。
這么說來，似乎有點教條化，我非常建議大家看看這個原則個兩個最經典的案例——“正方形不是長方形”和“鴕鳥不是鳥”。通過這兩個案例，你會明白《墨子 小取》中說的 ——“娣，美人也，愛娣，非愛美人也….盜，人也；惡盜，非惡人也。”——妹妹雖然是美人，但喜歡妹妹并不代表喜歡美人。盜賊是人，但討厭盜賊也并不代表就討厭人類。
這個原則讓你考慮的不是語義上對象的間的關系，而是實際需求的環境。
在很多情況下，在設計初期我們類之間的關系不是很明確，LSP則給了我們一個判斷和設計類之間關系的基準：需不需要繼承，以及怎樣設計繼承關系。
Interface Segregation Principle (ISP) – 接口隔離原則
接口隔離原則意思是把功能實現在接口中，而不是類中，使用多個專門的接口比使用單一的總接口要好。
舉個例子，我們對電腦有不同的使用方式，比如：寫作，通訊，看電影，打游戲，上網，編程，計算，數據等，如果我們把這些功能都聲明在電腦的抽類里面，那么，我們的上網本，PC機，服務器，筆記本的實現類都要實現所有的這些接口，這就顯得太復雜了。所以，我們可以把其這些功能接口隔離開來，比如：工作學習接口，編程開發接口，上網娛樂接口，計算和數據服務接口，這樣，我們的不同功能的電腦就可以有所選擇地繼承這些接口。
這個原則可以提升我們“搭積木式”的軟件開發。對于設計來說，Java中的各種Event Listener和Adapter，對于軟件開發來說，不同的用戶權限有不同的功能，不同的版本有不同的功能，都是這個原則的應用。
Dependency Inversion Principle (DIP) – 依賴倒置原則
高層模塊不應該依賴于低層模塊的實現，而是依賴于高層抽象。
舉個例子，墻面的開關不應該依賴于電燈的開關實現，而是應該依賴于一個抽象的開關的標準接口，這樣，當我們擴展程序的時候，我們的開關同樣可以控制其它不同的燈，甚至不同的電器。也就是說，電燈和其它電器繼承并實現我們的標準開關接口，而我們的開關產商就可不需要關于其要控制什么樣的設備，只需要關心那個標準的開關標準。這就是依賴倒置原則。
這就好像瀏覽器并不依賴于后面的web服務器，其只依賴于HTTP協議。這個原則實在是太重要了，社會的分工化，標準化都是這個設計原則的體現。
參考：
http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
Common Closure Principle（CCP）– 共同封閉原則
一個包中所有的類應該對同一種類型的變化關閉。一個變化影響一個包，便影響了包中所有的類。一個更簡短的說法是：一起修改的類，應該組合在一起（同一個包里）。如果必須修改應用程序里的代碼，我們希望所有的修改都發生在一個包里（修改關閉），而不是遍布在很多包里。CCP原則就是把因為某個同樣的原因而需要修改的所有類組合進一個包里。如果2個類從物理上或者從概念上聯系得非常緊密，它們通常一起發生改變，那么它們應該屬于同一個包。
CCP延伸了開閉原則（OCP）的“關閉”概念，當因為某個原因需要修改時，把需要修改的范圍限制在一個最小范圍內的包里。
參考：
http://c2.com/cgi/wiki?CommonClosurePrinciple
Common Reuse Principle (CRP) – 共同重用原則
包的所有類被一起重用。如果你重用了其中的一個類，就重用全部。換個說法是，沒有被一起重用的類不應該被組合在一起。CRP原則幫助我們決定哪些類應該被放到同一個包里。依賴一個包就是依賴這個包所包含的一切。當一個包發生了改變，并發布新的版本，使用這個包的所有用戶都必須在新的包環境下驗證他們的工作，即使被他們使用的部分沒有發生任何改變。因為如果包中包含有未被使用的類，即使用戶不關心該類是否改變，但用戶還是不得不升級該包并對原來的功能加以重新測試。
CCP則讓系統的維護者受益。CCP讓包盡可能大（CCP原則加入功能相關的類），CRP則讓包盡可能小（CRP原則剔除不使用的類）。它們的出發點不一樣，但不相互沖突。
參考：
http://c2.com/cgi/wiki?CommonReusePrinciple
Hollywood Principle – 好萊塢原則
好萊塢原則就是一句話——“don’t call us, we’ll call you.”。意思是，好萊塢的經紀人們不希望你去聯系他們，而是他們會在需要的時候來聯系你。也就是說，所有的組件都是被動的，所有的組件初始化和調用都由容器負責。組件處在一個容器當中，由容器負責管理。
簡單的來講，就是由容器控制程序之間的關系，而非傳統實現中，由程序代碼直接操控。這也就是所謂“控制反轉”的概念所在：
1.不創建對象，而是描述創建對象的方式。
2.在代碼中，對象與服務沒有直接聯系，而是容器負責將這些聯系在一起。
控制權由應用代碼中轉到了外部容器，控制權的轉移，是所謂反轉。
好萊塢原則就是IoC（Inversion of Control）或DI（Dependency Injection ）的基礎原則。這個原則很像依賴倒置原則，依賴接口，而不是實例，但是這個原則要解決的是怎么把這個實例傳入調用類中？你可能把其聲明成成員，你可以通過構造函數，你可以通過函數參數。但是 IoC可以讓你通過配置文件，一個由Service Container 讀取的配置文件來產生實際配置的類。但是程序也有可能變得不易讀了，程序的性能也有可能還會下降。
參考：
[url]http://en.wikipedia.org/wiki/Hollywood_Principle [/url]
[url]http://en.wikipedia.org/wiki/Inversion_of_Control [/url]
High Cohesion & Low/Loose coupling & – 高內聚， 低耦合
這個原則是UNIX操作系統設計的經典原則，把模塊間的耦合降到最低，而努力讓一個模塊做到精益求精。
內聚：一個模塊內各個元素彼此結合的緊密程度
耦合：一個軟件結構內不同模塊之間互連程度的度量
內聚意味著重用和獨立，耦合意味著多米諾效應牽一發動全身。
參考：
http://en.wikipedia.org/wiki/Coupling_(computer_science)
[url]http://en.wikipedia.org/wiki/Cohesion_(computer_science) [/url]
Convention over Configuration（CoC）– 慣例優于配置原則
簡單點說，就是將一些公認的配置方式和信息作為內部缺省的規則來使用。例如，Hibernate的映射文件，如果約定字段名和類屬性一致的話，基本上就可以不要這個配置文件了。你的應用只需要指定不convention的信息即可，從而減少了大量convention而又不得不花時間和精力啰里啰嗦的東東。配置文件很多時候相當的影響開發效率。
Rails 中很少有配置文件（但不是沒有，數據庫連接就是一個配置文件），Rails 的fans號稱期開發效率是 java 開發的 10 倍，估計就是這個原因。Maven也使用了CoC原則，當你執行mvn -compile命令的時候，不需要指源文件放在什么地方，而編譯以后的class文件放置在什么地方也沒有指定，這就是CoC原則。
參考：
http://en.wikipedia.org/wiki/Convention_over_Configuration
Separation of Concerns (SoC) – 關注點分離
SoC 是計算機科學中最重要的努力目標之一。這個原則，就是在軟件開發中，通過各種手段，將問題的各個關注點分開。如果一個問題能分解為獨立且較小的問題，就是相對較易解決的。問題太過于復雜，要解決問題需要關注的點太多，而程序員的能力是有限的，不能同時關注于問題的各個方面。正如程序員的記憶力相對于計算機知識來說那么有限一樣，程序員解決問題的能力相對于要解決的問題的復雜性也是一樣的非常有限。在我們分析問題的時候，如果我們把所有的東西混在一起討論，那么就只會有一個結果——亂。
我記得在上一家公司有一個項目，討論就討論了1年多，項目本來不復雜，但是沒有使用SoC，全部的東西混為一談，再加上一堆程序員注入了各種不同的觀點和想法，整個項目一下子就失控了。最后，本來一個1年的項目做了3年。
實現關注點分離的方法主要有兩種，一種是標準化，另一種是抽象與包裝。標準化就是制定一套標準，讓使用者都遵守它，將人們的行為統一起來，這樣使用標準的人就不用擔心別人會有很多種不同的實現，使自己的程序不能和別人的配合。Java EE就是一個標準的大集合。每個開發者只需要關注于標準本身和他所在做的事情就行了。就像是開發鏍絲釘的人只專注于開發鏍絲釘就行了，而不用關注鏍帽是怎么生產的，反正鏍帽和鏍絲釘按標來就一定能合得上。不斷地把程序的某些部分抽像差包裝起來，也是實現關注點分離的好方法。一旦一個函數被抽像出來并實現了，那么使用函數的人就不用關心這個函數是如何實現的，同樣的，一旦一個類被抽像并實現了，類的使用者也不用再關注于這個類的內部是如何實現的。諸如組件，分層，面向服務，等等這些概念都是在不同的層次上做抽像和包裝，以使得使用者不用關心它的內部實現細節。
說白了還是“高內聚，低耦合”。
參考：
http://sulong.me/archives/99
Design by Contract (DbC) – 契約式設計
DbC的核心思想是對軟件系統中的元素之間相互合作以及“責任”與“義務”的比喻。這種比喻從商業活動中“客戶”與“供應商”達成“契約”而得來。例如：
供應商必須提供某種產品（責任），并且他有權期望客戶已經付款（權利）。
客戶必須付款（責任），并且有權得到產品（權利）。
契約雙方必須履行那些對所有契約都有效的責任，如法律和規定等。
同樣的，如果在程序設計中一個模塊提供了某種功能，那么它要：
期望所有調用它的客戶模塊都保證一定的進入條件：這就是模塊的先驗條件（客戶的義務和供應商的權利，這樣它就不用去處理不滿足先驗條件的情況）。
保證退出時給出特定的屬性：這就是模塊的后驗條件——（供應商的義務，顯然也是客戶的權利）。
在進入時假定，并在退出時保持一些特定的屬性：不變式。
契約就是這些權利和義務的正式形式。我們可以用“三個問題”來總結DbC，并且作為設計者要經常問：
它期望的是什么？
它要保證的是什么？
它要保持的是什么？
根據Bertrand Meyer氏提出的DBC概念的描述，對于類的一個方法，都有一個前提條件以及一個后續條件，前提條件說明方法接受什么樣的參數數據等，只有前提條件得到滿足時，這個方法才能被調用；同時后續條件用來說明這個方法完成時的狀態，如果一個方法的執行會導致這個方法的后續條件不成立，那么這個方法也不應該正常返回。
現在把前提條件以及后續條件應用到繼承子類中，子類方法應該滿足：
1.前提條件不強于基類．
2.后續條件不弱于基類．
換句話說，通過基類的接口調用一個對象時，用戶只知道基類前提條件以及后續條件。因此繼承類不得要求用戶提供比基類方法要求的更強的前提條件，亦即，繼承類方法必須接受任何基類方法能接受的任何條件（參數）。同樣，繼承類必須順從基類的所有后續條件，亦即，繼承類方法的行為和輸出不得違反由基類建立起來的任何約束，不能讓用戶對繼承類方法的輸出感到困惑。
這樣，我們就有了基于契約的LSP，基于契約的LSP是LSP的一種強化。
參考：
http://en.wikipedia.org/wiki/Design_by_contract
Acyclic Dependencies Principle (ADP) – 無環依賴原則
包之間的依賴結構必須是一個直接的無環圖形，也就是說，在依賴結構中不允許出現環（循環依賴）。如果包的依賴形成了環狀結構，怎么樣打破這種循環依賴呢？有2種方法可以打破這種循環依賴關系：第一種方法是創建新的包，如果A、B、C形成環路依賴，那么把這些共同類抽出來放在一個新的包D里。這樣就把C依賴A變成了C依賴D以及A依賴D，從而打破了循環依賴關系。第二種方法是使用DIP（依賴倒置原則）和ISP（接口分隔原則）設計原則。
無環依賴原則（ADP）為我們解決包之間的關系耦合問題。在設計模塊時，不能有循環依賴。
參考：
http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple
在使用ExtJs過程中，性能一直是一個比較頭疼的問題，從用戶的角度來看，就一個字：慢。從技術的角度來說，這個“慢”字可以分為兩種，加載“慢”和渲染“慢”。想分辨這兩種情況很容易：如果居于網不慢而互聯網上慢，說明是加載慢；如果Chrome不慢而IE慢，就是渲染慢。還有另一種情況：越用越慢，這個“慢”通常是內存泄露造成的。
針對以下這三種情況討論一下解決方案：
1，加載慢
1.1 減少要加載的東西
不要動不動就ext-all.js，extjs是可以定制的，如果你用不到tree，就不要包含這個組件了。ExtJs的官網上有詳細的定制方法和工具。
1.2 給出合適的用戶提示
把Js后置，然后前面做一個加載的提示。如果像Gmail那樣給出進度條，或者像很多網游那樣來點圖片或者Tips啥的就更好了，說不定用戶還會覺得怎么加載這么快，我還沒看清楚呢，呵呵。
1.3 用的時候再加載
動態加載，參考使用ExtJs開發MIS系統（2）：Js的動態加載。
1.4 只加載一次
別用iframe了，如果你的靜態內容過期做的不好，瀏覽器會經常再不厭其煩的從服務器下載同樣的東西。
1.5 對你的Js添加過期標記
ext-base.js、ext-all.js都可以設置很長的過期時間，甚至永不過期（如果你不換extjs的版本）。這點對所有靜態內容都很有用，如何設置過期標記請垂詢Google。
2，渲染慢
2.1 少加載少解析、晚加載晚解析
1.1，1.3，1.4都對改善渲染慢的情況有效——加載的少了自然渲染的快了。
2.2 別用iframe
iframe不僅僅可能會使瀏覽器加載兩遍，還一定會使瀏覽器解析兩遍，放棄它吧，真的。
2.3 精心設計你的Js代碼
例如緩存getElementByID()的結果、編譯查詢表達式之類的東西，這個純看Js功力。
2.4 可能的話，讓用戶換個瀏覽器吧
Chrome比IE的Js渲染快是數量級上的差異！構造一個40列，50行的復雜GridPanel試試，你就會深有體會了……對于企業內部的MIS系統，換瀏覽器還是具有可能性的。
3，內存泄露
Ext性能調優方案
1. 將JS進行合并壓縮。
使用yahoo的yui-compress.jar進行壓縮JS，去掉過多的空格和注釋，并合并，減少IO的支出。
2. 將前后臺傳輸的數據進行GZIP壓縮。
大數據量的數據傳輸，通過GZIP的壓縮方案，可以減少到25%，有些數據可能會更多。
3. 對大量的JS分析依賴關系，進行動態加載。
這個是關鍵，通過分析所有的JS中的依賴關系，減少了JS加載的數量。從很大程度上提高了性能。
4. 另外對部分頁面進行緩存，而非真正的關閉。
還有一個外部的因素，由于系統使用的客戶機環境上的復雜，我們在多個瀏覽器上進行了測試，只有IE是最慢的，尤其是IE6，后來發現不是IE6要比IE7慢，是因為發現MS發布了腳本引擎cscript 5.7, 而大部分的ie6系統都裝的是5.6, 這個版本上的升級，不僅僅是修改了BUG，在JS的執行速度上也有了較大的提升，于是我們在環境因素上又加上了一條，要求客戶安裝cscript5.7，也大大的提升了頁面的打開時間。
ext-all.js這個文件都有500多k，在頁面中直接引用這個js文件是很不現實的，曾經在一個大的項目中使用這個js，則直接導致頁面半天出不來的后果。于是自己研究了下，目前通過下面的方法來優化提升Ext Js的性能。
使用JSVM
JSVM (JavaScript Virtual Machine的縮寫)，一個JavaScript基礎框架，sourceforge開源項目，由萬常華（wch3116）于2003年底發起, 目前最新版本是2.05,采用的是 BSD License 授權協議。本身JSVM也提供了JSVM+Ext2的實例，看看就知道怎么在JSVM下加入ext的js庫了。
我在項目中是這么用的：
<script type= "text/javascript" src= "/depporject/comjs/jsvm2/jsre.js" classpath= "dom2.gzjs;ext2p.gzjs" modules= "smartloader" ></script>
使用Gzip壓縮
gzip壓縮后，ext js文件的大小將只有100k左右。
只是對gzip壓縮的文件需要提供filter（Java開發），為你的應用提高解壓縮功能,filter的寫法很簡單：
public void doFilter(HttpServletRequest request,
HttpServletResponse response, FilterChain chain)
throws IOException, ServletException 
{
for (Iterator it = headers.entrySet().iterator();it.hasNext();) {
Map.Entry entry = (Map.Entry)it.next();
response.addHeader((String)entry.getKey(),(String)entry.getValue());
}
chain.doFilter(request, response);
}
public void init(FilterConfig config) throws ServletException {
String headersStr = config.getInitParameter( "headers" );
String[] headers = headersStr.split( "," );
for ( int i = 0 ; i < headers.length; i++) {
String[] temp = headers[i].split( "=" );
this .headers.put(temp[ 0 ].trim(), temp[ 1 ].trim());
}
}
}
web.xml配置
< filter >
< filter-name > addHeaderFilter </ filter-name >
< filter-class >org .common.AddHeaderFilter </ filter-class >
< init-param >
< param-name > headers </ param-name >
< param-value > Content-Encoding = gzip </ param-value >
</ init-param >
</ filter >
通過以上兩步，整個頁面裝載速度很快了。大家可以試試。
另外在實際開發中，并不是將ext-all.js全部在jsvm中裝載，只是將常用的ext js代碼歸到一起，由gzip壓縮，然后又jsvm裝載（即ext2p.js，p代表部分），剩下的ext js代碼由jsvm按需裝載。
概念解釋
在實際的業務中，對于工作流一般是這樣定義的：
定義完成某項工作需要多少個環節，每個環節由哪些人處理，完成這項工作的表單。
實際處理的時候，通常由發起人填好表單，然后去找各個環節的負責人簽字審批，一直到流程結束。
在JBPM的框架中，用ProcessDefinition來描述某項工作，Activity描述各個定義的環節，Transition描述環節中的路徑。
ProcessDefinitionInstance來描述實際執行的工作，可能是繼承了ProcessDefinition，但又多出很多屬性，如建立時間，發起人等，
Task或Excution來描述實際執行的步驟。
相應地有RespositoryService，ExcutionService，TaskService，來操作ProcessDefinition，Excution，Task，使工作一步步地往定義好的步驟往下走。
Excution表示實際流程中的當前環節，即以前的Token。
編程實務
畫好流程圖，即定義流程，畫好一堆的步驟。
作好每個環節中要展示的JSP頁面，并配到流程定義中。
寫好每個環節提交后要處理的JAVA代碼。
JBPM流程定義
流程定義的中間環節有兩種：
一種是流程引擎碰到這種環節，會自動流轉到下一環節，如Decision，Java等。
另一種是流程引擎碰到這種環節，會處于等待狀態，直到程序下指令如：excuSinal才流轉到下一環節，
這里面又分兩種：一種是有處理人屬性的Task，由處理人決定下一環節的流向，另一種是沒設處理人，由程序決定下一環節的走向，如State。
實際流程中可以放變量值，以供整個流程環節存取。
如果流程定義中用了變量或表達式，則其實際值，會取實際流程中放進去的值。
如Task節點：
加一個Task節點時，將assignee設成表達式，這樣在生成Task記錄時，會讀取綁定到流程實例中變量的值，作為assignee的值，
也可以指定一個CLASS，在生成Task記錄時，會運行其中的assign方法，讀取assignable中的getAssignee()的值，作為Task的分配人。
退回的解決方案
退回就是將此Task退回到上一環節的處理人處。
畫圖的時候不畫退回的路徑，但在程序處理中用代碼加這一Task指向上一環節的路徑，complete(taskId,newTransition)使其回到上一環節，然后再刪除這一Transition。
會簽的解決方案
會簽指的是將同一任務同時分派給多人并行處理。
用For-each和join實現，或動態增加子任務。
1. 流程定義(Process Definition)
流程定義是記錄在xml文件中的對流程的描述，它包含唯一的流程開始節點和多個流程功能節點，每個節點之間使用transition進行連接。
Process Definition使用id, key和version進行標識，jBPM中可能包含多個key值相同的Process Definition，key值相同的Process Definition會擁有不同的version值，而id是使用key-version的形式用來表示唯一的Process Definition的。
jBPM中使用RepositoryService來控制流程定義的發布，瀏覽，刪除等操作。
2. 流程實例(Process Instance)
以流程定義為藍本生成的流程實例，在jBPM屬于Execution的一種。
當我們執行start時，會根據流程定義啟動一個新的流程實例，然后它會根據流程定義里的節點運行，在遇到state或task時停頓，等待外部用戶調用signal，最后會執行到end節點，結束整個流程。
jBPM中只允許有一個start節點，所以每個流程都是單一入口的，jBPM4中可以允許有多個end節點，所以我們可以在任意位置結束流程。
jBPM中使用ExecutionService來控制流程實例的啟動，瀏覽，執行，刪除等操作
3. state節點
狀態結點是一個典型的等待狀態。同任務結點不同的是，狀態結點不會向任務列表添加任務實例。當業務進程需要等待外部系統的干預時，這種結點是很有用的。（需要外部系統干預，但又不是讓人去干預）假設如下情況：在進入該結點時，通過node-enter事件向外部系統發送一個消息，然后結點進入等待狀態；當外部系統完成處理，并回送一個消息，這將導致觸發一個signal()方法的運行，該方法重新激活正在等待的流程繼續下行
jBPM中使用ExecutionService來控制對state的signal操作。
4. task節點
任務結點（task-node）任務結點是代表由人介入的一個或多個任務。因此當流程運行到一個任務結點時，會生成“任務實例對象（task instances）”，并添加到參與人的任務列表中，之后結點會處于等待狀態，直到參與人完成他們的任務，并激活流程繼續向下執行。
task節點可以使用assignee, swimelane等方式為任務定義分配到某個人或者某個組，對應的用戶可以執行completeTask()結束任務，并控制任務結束后流程實例向哪個方向前進。
jBPM中使用TaskService控制task的各項操作。
5. Identity身份驗證
jBPM中的身份驗證分為User, Group和Membership三部分，用戶表示登陸用戶，Group表示用戶組，用戶和用戶組之間的關聯關系保存在Membership中。User和Group與Task中的assignee和swimelane是息息相關的。
6.事件
Event反映的是流程執行中的各個時刻。在流程執行中 JBPM引擎會在計算下一個狀態的時候觸發各種事件。一個事件通常和流程定義中的一個元素相關聯，比如流程定義本身，節點或者轉移。大部分的元素能夠觸發不同類型的事件，比如一個節點可以觸發節點進入事件，節點離開事件。事件其實是和動作連接在一起的。每個事件維護一個動作列表。當JBPM引擎觸發一個事件的時候，該事件維護的動作列表中的動作將被執行。
JBPM中事件類型是寫死在事件類中的，共有16種：
EVENTTYPE_TRANSITION = "transition"; // 轉移
EVENTTYPE_BEFORE_SIGNAL = "before-signal"; // 發信號前
EVENTTYPE_AFTER_SIGNAL = "after-signal"; // 發信號后
EVENTTYPE_PROCESS_START = "process-start"; // 處理開始狀態
EVENTTYPE_PROCESS_END = "process-end"; // 處理結束狀態
EVENTTYPE_NODE_ENTER = "node-enter"; // 進入節點
EVENTTYPE_NODE_LEAVE = "node-leave"; // 離開節點
EVENTTYPE_SUPERSTATE_ENTER = "superstate-enter"; // 進入超級狀態
EVENTTYPE_SUPERSTATE_LEAVE = "superstate-leave"; // 離開超級狀態
EVENTTYPE_SUBPROCESS_CREATED = "subprocess-created"; // 子流程創建
EVENTTYPE_SUBPROCESS_END = "subprocess-end"; // 子流程結束
EVENTTYPE_TASK_CREATE = "task-create"; // 任務創建
EVENTTYPE_TASK_ASSIGN = "task-assign"; // 任務分派
EVENTTYPE_TASK_START = "task-start"; // 任務啟動
EVENTTYPE_TASK_END = "task-end"; // 任務結束
EVENTTYPE_TIMER = "timer"; // 定時器
7.transition
關聯兩個節點，用于表示節點的走向
8.常用類說明
ProcessEngine：它是整個jBPM4的入口，并且是單例模式。通過它可以獲取processEngine，并藉此獲得工作流引擎所提供的各種服務
RepositoryService：控制流程定義的發布，瀏覽，刪除等操作
ExecutionService：控制流程實例的啟動，瀏覽，執行，刪除等操作
IdentityService：控制身份的各項操作
*********************************************************************************************
對jBPM4.3數據庫的幾張表簡單介紹
JBPM4_DEPLOYMENT 流程定義表
JBPM4_DEPLOYPROP 流程定義屬性表
JBPM4_EXECUTION 流程實例表
JBPM4_HIST_ACTINST 流程活動(節點)實例表
JBPM4_HIST_DETAIL 流程歷史詳細表
JBPM4_HIST_PROCINST 流程實例歷史表
JBPM4_HIST_TASK 流程任務實例歷史表
JBPM4_HIST_VAR 流程變量(上下文)歷史表
JBPM4_ID_GROUP 角色表
JBPM4_ID_MEMBERSHIP 用戶角色表
JBPM4_ID_USER 用戶表
JBPM4_JOB 定時表
JBPM4_LOB 存儲表
JBPM4_PARTICIPATION 參與者表
JBPM4_SWIMLANE 泳道表
JBPM4_TASK 任務表
JBPM4_VARIABLE 上下文表
紅色的表為經常使用的表.這里不使用JBPM自己的權限角色定義.
發布一個流程deploy后
jbpm4_deployment新增一條記錄
jbpm4_deployprop新增三條記錄
jbpm4_lob新增一條記錄
開始一個流程startProcessInstanceByKey后
jbpm4_execution新增一條記錄
jbpm4_hist_actinst新增一條記錄
jbpm4_hist_procinst新增一條記錄
jbpm4_hist_task新增一條記錄
jbpm4_task新增一條記錄
流程定義相關的布署信息就存儲在（1） JBPM4_DEPLOYMENT、（2） JBPM4_DEPLOYPROP 及（3） JBPM4_LOB 中。上傳一個包含png和jpdl.xml的zip包后，JBPM4_DEPLOYMENT多一條記錄 JBPM4_DEPLOYPROP多三條， JBPM4_LOB多兩條。
（4）J B PM4_HIST_PROCINST 與（5） JBPM4_HIST_ACTINST 分別存放的是Process Instance、Activity Instance的歷史記錄。
（6）JBPM4_EXECUTION 主要是存放JBPM4的執行信息，Execution機制代替了JBPM3的Token機制（詳細參閱JBPM4的PVM機制，過段時間我也會進一步分析）。
（7）JBPM4_TASK 存放需要人來完成的Activities，需要人來參與完成的Activity 被稱為Task。
（8）JBPM4_PARTICIPATION 存放Participation的信息，Participation的種類有Candidate、Client、Owner、 Replaced Assignee和Viewer。而具體的Participation既可以是單一用戶，也可以是用戶組。
（9）JBPM4_SWIMLANE。 Swim Lane是一種Runtime Process Role。通過Swim Lane，多個Task可以一次分配到同一Actor身上。
（10） JBPM4 _VARIABLE 存的是進行時的臨時變量。
（11） JBPM4_HIST_DETAIL 保存Variable的變更記錄。
（12）JBPM4_HIST_VAR 保存歷史的變量 。
（13） JBPM4_HIST_TASK Task的歷史信息。
（14）JBPM4_ID_GROUP （15）JBPM_ID_MEMBERSHIP （16）JBPM4_ID_USER 這三張表很常見了，基本的權限控制，關于用戶認證方面建議還是自己開發一套，JBPM4的功能太簡單了，使用中有很多需要難以滿足。
（17） JBPM4_JOB 存放的是Timer的定義。
Repository：內容倉庫，提供文件存儲和搜索等。
Workspaces：倉庫下面分多個Workspaces，以供存放節點。
RootNode：每個Workspace下面只有一個RootNode。
Node：節點，可包含節點或屬性對象。
Property：屬性對象，可存放對應的文件。
要使用倉庫前必須有鑰匙，開了門之后，要做存放或檢索文件的入口是Session，通過Session新增節點或取得節點。
要上傳實體文件，必須將實體文件關聯到屬性對象，再將屬性對象加到節點，再將節點加到根節點中即可。
一個倉庫只有一個Session，一個倉庫可有多個Workspace，一個Workspace只有一個根節點。
Alfresco選擇原因：
支持業界CMS內容管理系統的兩大標準：
CMIS：提供了針對于內容倉庫的一組標準服務，和JSR-170：對內容倉庫進行交互的標準接口集；
Alfresco集群
在集群環境中的Alfresco內容應用服務器的每個結點都可以共享同樣的內容倉庫存儲，盡管存儲本身可能根據需要在不同的結點上進行復制。緩存和查詢索引也同樣是分布式的。
支持備份服務
備份服務器是集群部署的一個特例，當服務器失效后，一個應用服務程序可以切換到備份版本的部署棧上去。
摘要: 英文Email，第一段該寫什麼？
1. I am writing to confirm/ enquire/ inform you...
我寫信是要確認/ 詢問/ 通知你......
2. I am writing to follow up on our earlier decision on the marketing campaign in Q2.
我寫信來是為了要追蹤我們先前對於第二季行銷活動的決定。
引用稍早的談話或信件，該怎麼說？
3. With reference to our telephone conversation today......
關於我們今天在電話中的談話......
閱讀全文