體系結構風格

1、體系結構風格：我以前做的都是ERP和OA系統(tǒng)，所以體系結構的選擇是基于怎么更好的完成業(yè)務處理1、 事務處理a) 簡單系統(tǒng)可以采用數據庫的事務處理功能優(yōu)勢：簡單、易學、性能高劣勢：將業(yè)務邏輯綁定在數據庫一層，很難使用高級語言來實現b) 復雜系統(tǒng)可以使用EJB來實現優(yōu)勢：支持分布式不同廠家數據庫上的事務處理，可以使用高級語言來實現劣勢：開發(fā)復雜，執(zhí)行效率低c) 注意：需要事務處理的地方不能選用MS的產品和框架，他們的事務處理完全依靠數據庫完成，基本沒有擴展的可能。WebService不支持事務，不能承載業(yè)務處理接口，只能提供一些可出錯或出錯后可重試的功能。2、 業(yè)務邏輯的實現：高級語言vs存儲過程

2、除非使用EJB，否則使用存儲過程來實現業(yè)務處理。從數據庫中讀取出數據，經過計算，寫回計算結果。這樣的過程是無法做到訪問互斥的。如果同時有線程在處理這些數據，就會產生沖突。就算使用數據庫事務也無法解決這個問題，因為數據的讀取并不受事務控制，系統(tǒng)不會保證讀取、計算和寫回的原子性。所以，使用存儲過程來實現復雜業(yè)務邏輯是可靠的。特別是如果系統(tǒng)是采用結構化的開發(fā)風格，存儲過程可以作為最底層的模塊供高級語言實現的模塊調用。3、 軟件系統(tǒng)的分層a) 數據庫b) 數據持久層：如果需要用高級語言來實現業(yè)務邏輯，則這一層需要提供讀寫鎖操作。Hibernate好像提供了這種功能，一般還是使用ejb。c) 業(yè)務邏輯層

3、：實現核心業(yè)務邏輯，例如：入庫操作d) 業(yè)務外觀（facade）層：組織業(yè)務邏輯層發(fā)布的接口完成業(yè)務邏輯處理，還負責一些外圍工作：數據校驗、錯誤處理、日志記錄等等e) 界面表現層i. 界面構件：一些基礎界面構件，頁面框架，樣式表等ii. 界面程序對象化編程風格：1、 和OO課上講的差不多結構化編程風格：1、 模塊間公共的常量要用宏定義，模塊內的公共常量要用靜態(tài)變量定義2、 不被外部調用的函數不要在頭文件中申明3、 模塊對外的接口要使用簡單數據類型：不要為了接口函數看著簡單而把多個參數包裝成一個結構體，而是直接使用多個簡單數據類型的參數。好處：易于理解、便于復用、不會造成模塊之間依賴關系復雜4、

4、 模塊對外的接口中不變的參數需要描述為const，告訴調用方這些數據不會被破壞5、 模塊分通常劃分為三類：a) 定義類模塊i. 定義一些公共變量和公共數據結構。針對公共數據類型的公用操作函數，例如：結構的初始化、釋放、序列化等等函數ii. 還有一個邏輯無關的處理函數可以放在這里，例如：日志打印b) 邏輯處理模塊：這類模塊一般有很強的內聚性，一般不依賴或少依賴其他模塊。一般只依賴一些定義類模塊。這類模塊一般針對特定數據結構進行計算操作，不會訪問文件、網絡等等外部設備。c) 組裝模塊i. 接口模塊：負責在對邏輯處理模塊進行包裝。例如：為了使用方便，將邏輯處理模塊中的一個處理函數包裝成多種參數的多個

5、函數。在這類模塊中，接口函數可以使用結構體作為參數，而不用嚴格遵循接口函數簡單變量的規(guī)定。ii. 調度模塊：負責調度各種多個處理單元合作完成工作，及一些高層邏輯，例如：多線程管理、網絡套接字管理、緩存管理等等代碼風格：1、 函數頭要寫注釋，說明函數的用途、輸入變量的含義和取值范圍，輸出的結果2、 變量名不要怕長，多個小寫英文詞用下劃線連接3、 函數要進行分類a) 功能簡單明確的函數：需要寫注釋描述函數頭b) 將上述簡單函數組合起來完成復雜功能的函數：需要在內部寫注釋說明為什么進行分支判斷和調用那些簡單函數4、 不能省略大括號，即：if (xxx=yyy) do_somthing();雖然只有一

6、行，但不要省略大括號，便于別人閱讀時知道判斷的作用范圍5、 不能使用魔鬼數字：不要告訴別的開發(fā)人員1代表什么，2又代表什么。把這些都定義成宏或常量6、 goto一般用于出錯處理（跳到錯誤處理段，通常在函數最后），不允許往上跳7、 避免用同一個函數名來定義不同參數的多個函數8、 避免使用遞歸函數基于CVS的分支開發(fā)方法本方法適合多人針對同一個模塊進行開發(fā)，各人的開發(fā)都是在原有模塊上增加無關的新功能。為了避免別人的修改造成自己開發(fā)和測試中發(fā)生問題，所以使用CVS的分支開發(fā)功能1、 針對每個新功能，在當前最新版本的基礎上建立代碼分支XXX_BRANCH2、 在分支上進行開發(fā)，版本號的最后一位表示送測

7、次數。如果一次就測試通過則版本號最后一位為0，如果測試發(fā)現錯誤后修改了再送測則版本號最后一位加13、 分支開發(fā)、測試完畢，則將模塊最新版本合并到當前分支上。創(chuàng)建分支時，模塊發(fā)布的最新版本號可能是x.y.z，分支測試完畢后x.y.z可能已經發(fā)布了。就需要在XXX_BRANCH分支中合并版本x.y.z到x.y.z版本之間的變更?？梢允褂胏vs up j x.y.z實現。合并完畢后再對合并結果進行回歸測試。把XXX_BRANCH定一個版本號，例如：t_XXX_BRANCH4、 合并測試之后，需要將XXX_BRANCH合并到當前release版本x.y.z上。首先使用cvs up dr x.y.z把當

8、前目錄下的代碼切換到x.y.z版本。再使用命令cvs up j t_XXX_BRANCH j x.y.z來合并從t_XXX_BRANCH到x.y.z的代碼變化。（由于t_XXX_BRANCH分支已經合并過一次x.y.z，所以這一步一般不會發(fā)生什么變化，如果發(fā)生變化則說明x.y.z之后又有人發(fā)布了新版本，哪么就需要重新合并分支并重新測試）5、 發(fā)布t_XXX_BRANCH，并確定新的基線版本號為x.y+1.z單元測試風格（一般是開發(fā)人員完成，測試人員沒有能力干）1、 測試框架：測試框架一般分兩部分a) 測試數據的自動生成和結果的比對自動生成比較困難，一般都是在單元測試中由開發(fā)人員寫程序來模擬產生

9、。但多版本程序的輸出數據的存儲、管理、比對應該由框架完成b) 測試用例的承載這部分需要解決的是測試用例該如何編寫，以及系統(tǒng)怎么執(zhí)行這些用例及怎么反饋測試用例的執(zhí)行情況2、 函數級測試根據函數的重要性可以決定是否對其編寫測試函數。測試函數中可以硬編碼許多（20-100個）測試數據，在調用被測試函數之后判斷返回結果是否符合預期。3、 模塊級測試針對模塊對外提供的接口進行測試，由于模塊的輸入輸出可能很復雜，可以用數據文件作為輸入。測試框架應當提供將被測函數的輸出數據存儲成文件的功能。若該模塊經過其他測試能保證質量，則生成的輸出文件可以作為標準輸出供下一次模塊測試使用。例如：對該模塊進行修改后可以用相同輸入文件進行測試，獲得新輸出數據文件。比較這兩個文件是否存在差異。4、 系統(tǒng)級測試系統(tǒng)級測試的正確性測試方法和模塊級測試完全相同。系統(tǒng)級測試過程中還應當考察一些特殊內容。例如：性能和容錯性可以使用一些dummy模塊來模擬該模塊被破壞的情況下系統(tǒng)整體運行情況，一個模塊發(fā)生錯誤系統(tǒng)可能采用以下方式進行處理：容忍錯誤（整體系統(tǒng)能“正?！边\行）、錯誤報警（需要測試是否發(fā)出報警及多快發(fā)生報警）、修復錯誤（一般來說是通過重新啟動出錯模塊來完成的。）性能測試需要測試系統(tǒng)在不同的壓力下的表現，需要在日志中記錄