隨筆檔案

The Architect (dedicated non-programming technical decision maker and problem solver for business):

架構師（專用非編程技術決策者，業務問題解決者）

1. Has outdated programming knowledge and experience, loss of touch with modern development approaches and practices.                                                                                                                                                                                             過時的編程知識和經驗，對現代的軟件開發方式和實踐缺乏關注。   


2. Don’t program and don’t know much about evolving system internals, but makes key technical decisions. Often has completely irrelevant and unreal picture what is happening with the system.                                                                       不進行軟件開發，對系統內部知之甚少，但卻要做出關鍵的技術決策。對系統經常有完全無關和虛幻的映像（不太會翻譯這句）。


3. Tends to complex, premature and generic solutions when the system is still in infancy and nothing is clear. Applies latest modern buzzword technologies as SOA, MDA, SaaS, Software Factories, etc. which look so beautiful in technical magazines, conferences and CV, but cause unnecessary headache for developers.                                      當系統仍處于起始階段，都還不明晰的時候，常會做出復雜的，不成熟僅僅通用的決策。使用在技術雜志、技術大會和CV上看起來如此美妙的現代最新的口號，諸如SOA，MDA，SaaS，Software Factories等等，只是給開發人員帶來不必要的頭痛。


4. Plays role of the middleman introducing complexity in coordination and project responsibilities. Represents software team in interactions with business customers reducing communication value for the rest of the team and impacting idea flow.                                                                                                                                                                          以中間人的角色，引入復雜的協調和項目的責任。代表開發組與客戶進行交流，屏蔽了其他成員的發言權和開發思想上的交流。（翻譯時候意思懂了，但就是表達不出來）


5. Reduces quality of decisions, which become limited to one perspective; decision making starts lacking diversity, independence and decentralization, which are essential attributes of collective intelligence.                                          決定僅僅局限在某個角度 ，降低了決策的質量；最初的決定缺乏多樣性，獨立性和向下兼容，這些都是集體決策的本質。                      


6. Creates tension with developers who experience mismatch between grand design and reality. Often continues pushing design decisions until the system becomes overly complex, difficult to change and becomes completely unusable.                                                                                                                                                                                             在缺乏大型設計和實現經驗的開發者之間制造緊張氛圍。不斷的做出決定，系統變得過度復雜，難于改變，和應用。


7. Secures job and justifies high salary - becomes authoritative center for solving business problems without much input from the team.                                                                                                                                                                            有穩定的工作和高薪，成為解決業務問題的權威，但卻從未融入到團隊當中。


8. Causes loss of sense of ownership, motivation and accountability in developers by detaching them from the key architecture decisions.                                                                                                                                                                     把開發人員排除在關鍵架構決策之外，讓他們缺乏主動性和責任感。


9. Concentrates project knowledge and the big picture in one head, limiting (and sometimes preventing) complete understanding for others.                                                                                                                                                                 只精通工程知識和大局一面，對其他方面幾乎一無所知。


10. Contributes to creation of specialized IT verticals that hurt relations with the business.                                                     擅長在縱向專門的IT方面建立聯系，但同時卻切斷了業務上的關聯。

            完成該系統后，所完成的后期維護工作中，最大的以部分就是數據統計查詢分析功能的完善了。

       系統軟件框架提供了一套報表生成系統來完成數據統計查詢的功能。這條報表生成系統可以生成excel和pdf兩種格式的統計報表。

       這個系統使用報表的流程大致為：

       1.每個功能都提供一系列的報表，在軟件中這些報表以二維字符串數組的數據格式保存，每個字符串數組對象包括該報表的唯一鍵值，報表名稱，報表條件提供頁面以及生成該報表的具體的Java類。

       2.選擇需要生成的報表，系統將該報表的唯一鍵值傳入統一的報表控制類，首先是跳轉到生成該報表的條件頁面，按照功能劃分報表的主要原因就是每個功能的報表條件一致，可以使用統一的控制類。

       3.提交條件后，統一的報表控制類會調用該報表的生成類,這些類需要繼承統一的接口,提供了一個統一的方法，返回數據類型為Vector集合的對象，這個Vector對象容器數據對象要求為：

     兩個Vector對象，一個為表頭Vector，一個為表體Vector，這兩個Vector對象中存儲的數據為字符串數組對象。

   在具體應用中，只要將數據填充到字符串數組中，再依次放入Vector中，報表框架會生成報表。

   這個框架的一個確定就是只能接受字符串數組對象，如果生成excel格式的報表，無法根據生成的報表進行計算，必須手動的將數據調整為數字型。

大家喝的是啤酒，這時你入座了，給自己倒了杯可樂，這叫低配置；給自己倒了杯啤酒，這叫標準配置；給自己倒了杯茶水，這茶的顏色還跟啤酒一樣，這叫木馬；給自己倒了杯可樂，還滴了幾滴醋，不僅顏色跟啤酒一樣，不冒熱氣還有泡泡，這叫超級木馬；你同事給你到了杯白酒，這叫推薦配置。

       人到齊了，酒席開始了。你現一個人喝了一小口，這叫單元測試；你跟旁邊的人說哥們咱們隨意，這叫交叉測試；但是他說不行，這杯要干了，這叫壓力測試；于是你說那就大家一起來吧，這叫內部測試；這時候boss向全場舉杯，這叫公開測試。

      菜過三巡，你就不跟他們客氣了，你向對面的人敬酒，這叫p2p；他回敬你，你又再敬他，這叫TCP；你向一桌人挨個敬酒，這叫令牌環；你說只要是兄弟就干了這杯，這叫廣播。

   有一個人過來向這卓敬酒，你說不行，你先過了我這關，這叫防火墻。你的小弟們過來敬你酒，這叫一對多。

   酒過三巡后，你也該活動活動了，你一桌一桌的走，這叫輪詢；你突然看見某一桌的漂亮mm，走了過去，這叫優先級；你去了坐下來就不打算走了，這叫死循環；你的老大舉杯邀你過去，你只好走過去，這叫激活事件。

  你向一桌敬酒，他們說：“不行，不行，我們都喝白的。”于是你也喝白的。這叫本地化；你向boss敬酒，可是boss被圍起來，你只能站在外圍，這叫排隊；你終于到了內圍，小心翼翼的向前一步，這叫訪問臨界區；你拍照boss的肩膀說哥們咱們再喝已被，這叫越界。

                    一個程序員對自己的未來很迷茫，于是去問上帝：“萬能的上帝啊，請你告訴我，我的未來會怎樣？”

            上帝說：“我的孩子，你去問Lippman，他現在領導的程序員的隊伍可能是地球上最大的。”

           于是他去問Lippman，Lippman說：“程序員的未來就是駕馭程序員。”

          這個程序員對這個未來不滿意，于是他又去問上帝：“萬能的上帝呀，請你告訴我，我的未來會怎樣？”

         上帝說：我的孩子，你去問Gates，他現在所擁有的財產可能是地球上最多的。”

         于是他去問Gates，Gates說：“程序員的未來就是榨取程序員。”

        這個程序員對這個未來不滿意，于是他又去問上帝：“萬能的上帝啊，請你告訴我，我的未來會怎樣？”

        上帝說：“我的孩子，你去問侯捷，他寫的計算機書的讀者可能是地球上最多的。”

        于是他去問侯捷。

        侯捷說：“程序員的未來就是誘惑程序員。”

       這個程序員對這個未來不滿意，于是又去問上帝：“萬能的上帝啊，請你告訴我，我的未來會怎樣？”

      上帝搖搖頭：“唉，我的孩子，你還是別當程序員了。”

           該系統軟件框架對sql操作進行了封裝，并提供了一批API幫助客戶程序員更為簡便的進行數據庫操作。這些api包括:

1. 
   
          統一的DbConnection管理，客戶程序員只需將要執行的sql語句作為參數傳入，api會將結果列表以二維字符串數組的形式返回。api提供特殊的方法，例如翻頁處理等都提供了相應的處理。
   
   


2. 
   
          按照功能劃分dao操作類。類的編寫有自身設計的一套規范。首先該功能的dao操作類設計為接口，然后按照數據庫的不同特殊處理實現該接口。例如：接口為TestDAO.java，使用oracle數據庫實現該接口，為OraTestDAO.java，使用sqlserver數據庫實現該接口，為SqlTestDAO.java。dao操作類直接操作框架對數據庫進行操作的DbConnection對象進行業務處理。
   
   


3. 
   
         所有的接口實現的dao操作類在web服務器的一個特殊目錄中存在一個xml格式的配置文件。
   

   xml 代碼

   
   

   
   

   
   

   
   
   1. <DAOLIST>  
   
   
   2. <DAO>  
   
   
   3. <NAME>testdaoNAME>  
   
   
   4. <CLASSNAME>com.test.dao.OraTestDAOCLASSNAME>  
   
   
   5. <DESCRIPTION>測試DESCRIPTION>  
   
   
   6. DAO>  
   
   
   7.  DAOLIST>  
   
   

   
   

   
   
   
   


4. 
   
       在web服務器的同時，會同時啟動一個線程，讀入該xml文件，并讀入數據庫配置參數文件。與hibernate這個框架相比，這個dao管理只能在web應用中使用。
   
   


5. 
   
       前幾篇提到的web層使用的Ctrl控制類，在框架設計中不能直接操作dao操作類，而是存在一個中間層，包括BO類和VOListIter類，編寫這兩個類都需實現框架提供的接口。bo類主要包括數據庫的除獲取數據列表以外的所有操作，如錄入，修改等，VOListIter類專門為實現數據列表翻頁設計，通過該類獲取翻頁數據列表方法，需要首先聲明一個長度為5的Integer類型的數組，DbConnection類的該方法需要這個參數，將該列表的當前頁數和最大頁數返回。
   
   

       這個數據庫框架還提供了一些方便編寫代碼的操作，例如拼裝sql語句，提供了一個這樣的方法：MakeUp類。代碼如下：

java 代碼

這個makeUp方法會將sql語句拼裝好，@表示數字占位，#表示字符占位。

這個系統的數據庫操作管理大致就是這樣了，比較簡單，總的來說就是對dbconncetion 操作進行了重新封裝，方便客戶程序員的使用。

           維護的這個軟件系統使用了一個比較復雜的系統權限管理系統，原本的設計是將用戶對軟件的使用權限控制到以最末級的菜單，并根據公司組織機構的設計，上級組織單位可以將自身所獲得的權限繼續授權到自己的下級公司。

       為了授權權限的操作簡單話，不然每次都從幾百個菜單選項中選擇給該用戶授權的菜單權限，恐怕這個權限系統管理員就要崩潰了。:-)，權限管理系統將權限分為了權限組，權限域，基本權限管理。

      權限組和權限域的區別我至今沒有太分的清楚，郁悶中····在不多的使用當中（主要是設置測試用戶的權限）感覺上這兩種權限范圍設置是評級的，沒有誰是誰的上級的關系，不清楚當初為什么設置成這樣，我用的主要是權限域的設置。

     給用戶授權下權限，前提是已經有相應的權限域設置。

   1.權限域設置：權限域需要相應的設置編碼，并選擇該權限域包括的菜單權限。

   2.在設置好權限域后，就可以直接將該權限域授權到系統用戶。

   權限管理使用了數據庫信息管理，現在使用起來比較笨拙，不過由于最初的設置過于復雜，如果使用現在比較統一的xml文件配置，可能使用起來也不是很方便。

   每個菜單權限項都有一個自身的權限編碼，該系統的菜單全部分為三級，編碼規范為：一級菜單編碼_二級菜單編碼_三級菜單編碼。這樣，在授權權限的時候可以直接將一級菜單授權，用戶相應的也獲得該一級菜單下所有功能的使用權。

    用戶登錄成功后系統會將該用戶的合法權限值壓到一個集合中，放到sessin對象里。

   權限的控制在系統的頁面和后臺控制類都有實現。頁面使用了上一篇提到的頁面邏輯標簽實現控制，在顯示該頁面之前，控制類使用了個系統框架提供的公共權限控制類將該用戶的權限值壓到頁面值中。

  在調用該功能之前，控制類現會判斷該用戶的權限，有一個通用類，將該功能的權限和當前的用戶對象作為參數傳入，該類會判斷在用戶的權限集合中是否包括該權限，以決定是否繼續執行該功能流程。

  這個系統的權限管理部分就是這么多了，下一篇講講這個系統的數據庫管理部分。維護的這個軟件系統使用了一個比較復雜的系統權限管理系統，原本的設計是將用戶對軟件的使用權限控制到以最末級的菜單，并根據公司組織機構的設計，上級組織單位可以將自身所獲得的權限繼續授權到自己的下級公司。

       為了授權權限的操作簡單話，不然每次都從幾百個菜單選項中選擇給該用戶授權的菜單權限，恐怕這個權限系統管理員就要崩潰了。:-)，權限管理系統將權限分為了權限組，權限域，基本權限管理。

      權限組和權限域的區別我至今沒有太分的清楚，郁悶中····在不多的使用當中（主要是設置測試用戶的權限）感覺上這兩種權限范圍設置是評級的，沒有誰是誰的上級的關系，不清楚當初為什么設置成這樣，我用的主要是權限域的設置。

     給用戶授權下權限，前提是已經有相應的權限域設置。

   1.權限域設置：權限域需要相應的設置編碼，并選擇該權限域包括的菜單權限。

   2.在設置好權限域后，就可以直接將該權限域授權到系統用戶。

   權限管理使用了數據庫信息管理，現在使用起來比較笨拙，不過由于最初的設置過于復雜，如果使用現在比較統一的xml文件配置，可能使用起來也不是很方便。

   每個菜單權限項都有一個自身的權限編碼，該系統的菜單全部分為三級，編碼規范為：一級菜單編碼_二級菜單編碼_三級菜單編碼。這樣，在授權權限的時候可以直接將一級菜單授權，用戶相應的也獲得該一級菜單下所有功能的使用權。

    用戶登錄成功后系統會將該用戶的合法權限值壓到一個集合中，放到sessin對象里。

   權限的控制在系統的頁面和后臺控制類都有實現。頁面使用了上一篇提到的頁面邏輯標簽實現控制，在顯示該頁面之前，控制類使用了個系統框架提供的公共權限控制類將該用戶的權限值壓到頁面值中。

  在調用該功能之前，控制類現會判斷該用戶的權限，有一個通用類，將該功能的權限和當前的用戶對象作為參數傳入，該類會判斷在用戶的權限集合中是否包括該權限，以決定是否繼續執行該功能流程。

  這個系統的權限管理部分就是這么多了，下一篇講講這個系統的數據庫管理部分。