考核系統快結束了，將此項目的經歷回憶如下，也小結一下，先談這個項目中值得提倡的地方：

1、在開發之前進行了完整的需求分析，形成了系統的需求文檔，需求文檔中最有用的部分感覺就是界面原型，還有系統的菜單，這樣給了用戶一個初步的直觀的印象，同時文檔中的一些對于界面原型的描述以及計算規則等內容在后期的開發中也起了指導作用。

2、在需求分析完成之后，進行了概要設計，包括完整的數據庫設計，這樣在后期的開發中對數據庫表結構方面沒有大的修改了，只是添加了一些表和視圖。

再談談項目中的缺點吧：

1、首先就說說需求文檔，雖說需求文檔寫了很多，大概有100頁左右（word），但由于一篇文檔中集中的內容太多，對于用戶來說只是關注了界面原型，系統菜單等部分，對于其它內容用戶關注度不高；同時由于篇幅太大，開發人員打開查看或者后續修改也比較麻煩。

對于以后的需求文檔是否可以這樣編寫：首先有一個正文，正文中包括大綱，然后將每一個具體的需求放在單獨的一個文檔中，最好能類似html鏈接那樣，這樣查看也方便，也一目了然。

原來用RobotHelp寫過幫助，照此看來，豈不可以用來寫需求文檔了，呵呵

2、再說數據庫設計，還不夠細致，很多應用場景由于設計的不夠細致，導致數據庫表也有所欠缺，因此對于以后的項目設計有兩個注意點：

a、加強應用場景設計，具體可以用流程圖，甚至序列圖描述清晰的業務流程，完善數據庫表設計。

b、要求一定先修改模型（這里指PowerDesigner中的數據庫設計），然后再去修改POJO類等具體代碼，最好不要先改代碼，再修改模型，這樣難免會有遺漏，時間久了，就會導致模型和代碼的不一致，慢慢的，模型文檔就沒有人看，也沒有人維護了。

c、順便提一下，模型文檔的好處一是方便后來者，二是可以方便的導出數據字典。

3、對于命名規范沒有在開發前考慮全面，雖然在開發前對命名規范有一定的規定，但是不夠全面，造成了后期開發中各人各人的命名有所偏差。

4、分層架構中的dao層和service層處理的不夠好，導致service層實際上是混雜了dao和service的功能，業務代碼不夠清晰。以后的項目考慮dao就是dao，提供數據訪問的操作，service層則提供業務處理方法，service與dao的關系應該是多對多的關系。

5、考核系統中使用了JSF/Richfaces做為表現層，好像不太好使，經常會出現多次重復訪問方法的問題，后續還需要加強對JSF的學習，避免類似問題。另外Richfaces在生成大數據量的頁面時，一個表格有1440行數據，頁面巨慢無比:(，后來沒有使用RichaFaces的表格，直接使用jstl+html標簽，速度倒是很快。

6、項目中的日志輸出、異常處理不夠明晰，這個和命名規范一樣應該在項目開始時給出清晰的思路，在具體開發中應該經常檢查。

具體內容參見如下鏈接：

http://www.javaworld.com.tw/roller/ingramchen/entry/2005_9_20_JBossSeamKingofStateful_

今天在http://refcardz.dzone.com/上下載了《Getting Started with Hibernate Search》，乍一看標題，以為是講如何使用Hibernate進行查詢操作什么的，下載好以后打開一看，原來是Hibernate集成了lucene，用來對自己的數據庫進行全文檢索，真是厲害！

沒有仔細研究具體內容，先記下一筆，日后有時間時，可以實踐一把。

    Template設計模式主要適用于需要按一定的步驟執行的場合，但有的步驟在不同的場合執行的內容有不相同。如下類圖中的TemplateClass中的execute()方法會按照如下的順序進行調用：

public void execute() {
    step1();
    step2();
}

    但由于step1在不同的場合執行的內容不一樣，此時就將step1設為抽象方法，在TemplateConcreteClass1和TemplateConcreteClass2中分別實現，這樣就形成了Template設計模式，step1()方法也稱為模板方式。

    類圖如下：

   

1、在菜單中選擇“Weblog”，然后選擇“Another Weblog Service”。
2、在Weblog Homepage URL中輸入你的Blog主頁地址。
3、輸入用戶名與密碼。
4、在“Type of  weblog that you are using”中選擇“Custom(Metaweblog API)”。
5、“Remote posting URL for your weblog”中輸入“http://www.cnblogs.com/用戶名/services/metaweblog.aspx”。

具體過程參見：http://coenraets.org/flex-spring/

簡要描述一下：
1、首先要繼承FlexFactory，實現Spring與Flex的集成，上文中已經提供了具體實現，下載即可。

2、在web.xml中配置Spring，如下：
   

3、在service-config.xml配置文件中添加
   

4、修改remote-config.xml中原有的destination配置，原為：
       
    修改為：

      
1、使用HTTPService
    使用HTTPService可以直接訪問ASP.NET、JSP、Servlet、PHP等頁面，此種方式最為簡單直接。

2、使用WebService
    使用WebService可以直接訪問互聯網上各大公司提供的WebService服務，該種方式對做互聯網應用開發可能用的比較多。

3、使用RemoteObject
    此種方式可以直接訪問Java Class的method，可以采用此種方式構建 Flex + Spring + Hibernate的應用。

4、使用Message
    此種方式彌補了WEB應用的缺點，使得瀏覽器和Server端可以進行雙向交互，可以用于構建復雜的C/S方式的企業應用。

不同方式的具體訪問方法在BlazeDS的Test中都有樣例。

第一、第二種方式不需要服務端有特殊設置，只要客戶端能夠解析服務端返回的信息即可。
第三、第四種方式需要使用BlazeDS進行配置后方可使用，或者使用ColdFusion。 至 http://opensource.adobe.com/ 可以下載BlazeDS，下載后解壓至本地。

BlazeDS includes the following Web Application Archive (WAR) files:

• blazeds.war - The primary BlazeDS WAR file: use this as a starting point for building your BlazeDS application.
• samples.war - Sample BlazeDS applications.
• ds-console.war - Simple monitoring application for BlazeDS deployments.

在訪問BlazeDS的Sample前，需要首先運行install_root/sampledb目錄下的HSQLDB數據庫，運行方式為啟動startdb.bat腳本

然后啟動tomcat，即可訪問http://localhost:8400/，體驗BlazeDS了。

如果沒有下載tomcat和BlazeDS的整合包，直接安裝BlazeDS的話，對于不同的應用服務器需要進行一些額外的配置，具體參見如下鏈接：

http://opensource.adobe.com/wiki/display/blazeds/Installation+Guide

    今天忽然想到這個題目----快速高效的開發軟件項目，將個人的一點體會記下來：

1、需求分析要做的充分，使用原型法和用戶進行溝通，這樣可以更好的把握用戶需求。

2、架構設計一定要做，解決項目中可能遇到的難點問題，其實架構設計也可以看作一個抽象的過程，從系統需求中抽取出共性的內容，然后進行設計。

3、多周期迭代，每次迭代的時間控制在兩個星期至一個月，每次迭代結束后一定需要進行測試。要牢記項目經理的職責不是編寫代碼，不是關注編碼的細節，要有全局觀，與用戶要有良好的溝通。

4、困難的問題、基礎的問題要先解決。

5、要有測試人員全程參與，并且測試人員對項目的目標、范圍、質量要求與項目主管、用戶理解一致。

6、確保開發人員理解需要解決的問題后才進行開發，可采用復述法、提問法確保理解。

7、不要采用大家不熟悉的技術，如果采用，那么需要對該技術盡早預研，并開展培訓工作。

8、建立一個強有力的、關系融洽的團隊。團隊中最好能有一個技術高手，最好能有一個活躍氣氛的人。

9、確保能夠有效的溝通，尤其是后期測試人員參與集成測試時。

10、不要把項目時間排的很滿，要留出機動的時間和資源。

11、對項目組成員能夠進行考核獎勵。

12、沒有完美的產品，只有合適的產品。

13、項目啟動前就編碼規范、溝通方式、在項目中采取何種管理方式等與項目組成員進行溝通。項目組每周召開簡短的例會，討論完成情況，分析存在問題，交流溝通其他技術問題。

14、不能姑息項目組中犯錯誤的同事，有問題要指出，方式要恰當。

15、最后一點，不要拘泥于形式，要能夠洞悉項目中已經存在、正在出現、即將發生的問題和風險，并采取適當的方法去解決，最近很喜歡孫子兵法中的一 句話“故兵無常勢，水無常形。能因敵變化而取勝者，謂之神。”。當然這不是說各項知識不需了解，僅憑感覺，這樣是做不好項目的。

1、專注于構建一個強有力的團隊，這一團隊能夠解決困難的問題，并為客戶創造真正的價值
    團隊的定義：團隊就是一群擁有互補技能的人，他們為了一個共同的目標而努力，達成目的并固守相互間的責任

2、領導者鼓舞；管理者授權。要同時成為優秀的領導者和管理者，你需要就愿景進行溝通并理解其細節。

3、對可能出現的障礙有所準備，防微杜漸，在這些障礙尚未壯大時就清除它們。

4、花時間來仔細傾聽別人的意見，但不要過于擔心其他人的想法。

5、專注于事實。

6、充當一個衰減器，而不是放大器，為團隊提供穩定性。

7、永遠不要將不能解釋的事情歸咎于蓄意破壞。

8、培養幽默意識來作為嚴肅認真的一種平衡；對于工作一絲不茍，對自己輕松自如。

9、除了工作，還應該懂得享受生活，而且每年要讀25本書。

10、相信你的直覺：如果你感覺不妙，那么很可能預感就會成真。

摘自《軟件開發的邊界-管理成功的項目》

如何編寫高質量的Java代碼：

1、  養成良好的習慣及良好的編碼風格，比如當有代碼沒有徹底完成前，通過TODO、FIXME等方式進行標注，比如良好的命名規則、注釋、行間距等

2、  秉承設計模式的一個基本原則：單一職責，一個類不應過于龐大，如果過于龐大，則應分解

3、  避免Ctrl+C、Ctrl+V，當發生這樣的事情后，需要進行重構

4、  要敢于重構，敢于重構的一個質量保證手段就是要對代碼進行充分的測試

5、  注意異常處理、注意事務控制的范圍

6、  遇到問題不能總是求助于Google、其他同事，要自己能夠分析問題，解決問題

7、  不能僅僅滿足于編碼速度快，要時刻牢記需要編寫的是高質量的代碼，易于維護的代碼。一定要深刻理解高質量、易于維護。高質量就是說代碼需要在各種情況下都能正常工作，而不僅僅是正常流程no problem，易于維護就是說如果換了一個開發人員來修改代碼，是否能夠很容易的閱讀代碼，理解代碼，還是他會覺得這段代碼無藥可救了，重寫是最佳選擇，如果是后一種狀況的話，那么這段代碼就是最糟糕的了。

 

以下為摘自IBM <Java代碼質量專題>的一段話：

高質量的軟件通常具備了這樣一些特性：

• 滿足用戶的需求。
• 合理進度、成本、功能關系。
• 具備擴展性和靈活性，能夠適應一定程度的需求變化。
• 能夠足夠的強壯、足夠的魯棒，能夠有效的處理例外的情況。
• 保持成本和性能的平衡。
• 能夠可持續的發展。

 

    首先需要明白的是，什么是架構設計，看了以前的培訓資料，也google了，也自己想了，總結下來：

    架構設計：軟件系統是由組件以及它們之間的連接關系組成的，同時架構設計還要滿足軟件系統的易變性、可擴展性、可維護性等特性。

    搞清楚了什么是架構設計之后，再想想怎么才能做好架構設計呢？

    架構設計可大可小，回顧一下自己做過的項目，細想再小的項目其實也有一個架構設計，只不過這個架構設計可能很小，三言兩語就能描述清楚了，比如一個很小的BS系統，可能也要劃分一下，功能模塊如何劃分，哪些是公用的，目錄或package如何劃分，這個我覺得也是架構設計。

    但是當系統變大時，架構設計就變得復雜了，因為需要考慮的東西就多了，一方面從系統的功能來說，系統功能點已經上百成千個了，光是搞清楚這些功能點就已經不容易了，如何從這些功能點中發掘共性，劃分組件，如何設計組件之間的聯系，實現分而治之就更復雜了，另一方面，系統變大了，系統的非功能性需求或約束更多了，一個小系統，可能不需要考慮大用戶量、并發、大數據量等問題，但一個大系統，即使用戶不提這些約束條件，一個好的項目經理或者架構師，必須替用戶考慮這些約束條件，有幾年的數據以后，系統會不會變慢，采取什么樣的方式可以解決這樣的問題，用戶如果要求5秒內，系統必須有響應，那么目前的架構設計能不能滿足這樣的要求呢？

    同時從軟件系統的架構與建筑設計的類比來看，一個建筑設計，必定是先把建筑結構定下來，然后再按圖施工，如果想有創新性的設計，則必須廣聞博見，同時還必須功力深厚，否則怎么設計的出鳥巢呢？呵呵

   同樣對于一個軟件架構的設計者來說，第一個層次，豐富的實踐知識，達到這樣，至少在一定的范圍內可以依葫蘆畫瓢了，同時還可以有一些局部性的創新設計。
   第二個層次建立在第一個層次的基礎上，廣聞博見，精通十八般武藝，無論哪種兵器都能使得很趁手，比如BS架構很熟悉，CS架構很熟悉，銀行系統的架構設計做過，電信系統的架構見過研究過，嵌入式系統的架構也熟悉，操作系統、數據庫等基礎知識那更是不用說，至少熟悉多種主流編程語言，還能緊跟潮流趨勢，更要有自己的思想，理解能力深厚，這樣的大師我想應該能做出創新性的設計了。

    回顧一下自己，只能是第一個層次了，其實第一個層次也不算很好，第二個層次只能算剛剛入門，看來要成為一個大師，很難，@_@



今天將以前參加的一個架構設計的培訓教材拿出來又翻了翻，忽然發現當時培訓的教材其實是按照RUP的開發思路來安排的。
首先來看看RUP的核心工作流，分別是：

• 商業建模（業務建模）
• 需求
• 分析與設計
• 實現
• 測試
• 發布
• 配置與變更管理
• 項目管理
• 環境

后面幾項與架構設計的關系不大，重點看前面幾個：商業建模、需求、分析與設計。
回過頭來再看看培訓教材的大綱：

• 架構師必備的全局觀
• 架構設計導論
• 架構設計過程概覽                 
  
• 需求分析                          ---- RUP ---- 需求
  
• 領域建模                          ---- RUP ---- 商業建模
  
• 打通軟件需求到架構師設計之墻      ---- RUP ---- 需求、分析與設計
  
• 概念性架構設計                    ---- RUP ---- 分析與設計
  
• 細化架構設計                      ---- RUP ---- 分析與設計
• 非功能需求設計方法論              ---- RUP ---- 分析與設計（重點在非功能需求的架構設計）
• 架構驗證                          ---- RUP ---- 分析與設計（重點在驗證）
• UML實踐指南
• 面向對象架構設計
• 架構模式實踐
• 框架技術實踐

除了實踐部分與前面概要性的部分之外，其余部分基本可以對應起來。

有時候，會覺得寫小說是件容易的事情，設計好大綱，一篇一篇往里填充不就行了么，但是換做真的是自己動筆的話，確萬萬也寫不出來。
架構設計也是如此，簡單點說是如此簡單：熟悉需求、商業建模、分析與設計。但是真的遇到一個需要實現的系統時，確發現千頭萬緒，要想做一個好的架構，不是一件容易的事情。

要想做好架構設計，重點還在一個分析，學習架構設計也是如此，那就是得分析開源框架、別人的代碼為什么要這么做？要分析我從中可以體會到什么？
架構設計師的知識面一定要廣，否則應用面就比較窄了。

說了半天，回頭一看，亂七八糟，其實最近在琢磨的一個問題是，如何才能搞好架構設計 ^_^

再想想，這是一個長期工程，需要不斷的分析積累。


今天假借兒子的名義買了個變形金剛，了卻了多年的心愿，哈哈

在startup.sh開始處中增加如下內容：

declare -x CATALINA_OPTS="-server -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8788"

然后啟動Tomcat即可。

windows下是增加如下內容：
SET CATALINA_OPTS=-server -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8788


在終端中切換到root用戶，然后執行如下命令：
yum install scim scim-lang-chinese scim-pinyin -y

安裝完成后，注銷再登錄系統即可。
時間過的真快，上次寫隨筆已經是四個月前的事情了。

四個月過去了，有什么進步呢？但工作還是要做，不知什么時候是個盡頭。

 使用flash.utils.getDefinitionByName()函數可以根據類名創建類的實例，具體可以參照API文檔。 今天看了《最后期限》的前幾章，好書！ 今天才了解到，Hibernate3.2已經全面支持EJB3.0中的JPA規范。

看來對新技術了解不夠，只顧了看EJB3.0的規范了

感覺Hibernate3.2全面支持EJB3.0的規范對于EJB3的推廣來說是件好事，至少在ORM這方面，一般程序員積累的經驗可以很快速的適應EJB3.0的開發。只要繼續加強對EJB容器、事務處理等方面的學習，就可以對EJB3有全面完整的了解。比起以前EJB2.1和常用技術的格格不入而言，真的是很大的進步了。