軟件是這樣“煉”成的 軟件架構設計實現 pdf epub mobi txt 電子書 下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

王朔韜，劉萍 著

圖書標籤:

• 軟件架構
• 軟件設計
• 軟件工程
• 代碼質量
• 可維護性
• 可擴展性
• 係統設計
• 編程實踐
• 軟件開發
• 技術書籍

齣版社： 清華大學齣版社

ISBN：9787302463566

版次：1

商品編碼：12143481

包裝：平裝

開本：16開

齣版時間：2017-07-01

用紙：膠版紙

頁數：643

字數：1170000

正文語種：中文

編輯推薦

　　《軟件是這樣“煉”成的——軟件架構設計實現》是《軟件是這樣“煉”成的——軟件過程管理與軟件測試過程》和《軟件是這樣“煉”成的——從軟件需求分析到軟件架構設計》設計的最後延續，同樣用投核保係統為本書連貫性的案例解讀軟件架構設計。通過獨特的場景描述、紀實性的記錄手法，深入剖析瞭係統開發模式、各種工具的安裝與配置過程、數據架構設計實現過程和軟件架構設計實現等四方麵的內容。本係列書是作者對自己多年的軟件開發的工作和培訓經驗、技術要領和心得的總結和升華，以軟件生命周期為主綫，將各種軟件開發相關的思想、方法、工具、技術點巧妙地穿插其中，圖錶詳盡、案例難易適中、內容通俗易懂、語言嚴謹但不失活潑，真可謂是詳實的軟件“煉成”教學片，完整的軟件“煉成”紀錄片，每一位軟件開發和管理從業人員必備的“軟件修煉寶典”！

內容簡介

　　

《軟件是這樣“煉”成的——軟件架構設計實現》是《軟件是這樣“煉”成的——軟件過程管理與軟件測試》和《軟件是這樣“煉”成的——從軟件需求分析到軟件架構設計》的延續，將投核保係統作為連貫性的案例全程記錄和解讀軟件架構設計。本書從文字組織到結構設計方麵既不是以理論為主調的“學院派”編寫風格，也不是以應用介紹為主調的“應用派”編寫風格，而是采用瞭情景對話、場景再現、自然語言的敘述方式。本書是在解讀投核保係統的詳細設計、數據庫設計和軟件詳細設計的基礎上介紹瞭軟件開發過程管理中應用的理論知識以及這些知識的應用，同時分析瞭這些理論知識的應用場景，然後以投核保係統為案例將軟件開發過程中各個階段的成果完整地展現給讀者。
　　本書包括四篇，即第一篇“開發之旅起航”、第二篇“軟件開發環境設計實現”、第三篇“基於Oracle的數據架構設計實現”和第四篇“基於Struts 2.0+EJB 3.0的軟件架構設計實現”。本書可以讓讀者瞭解如何在解讀架構設計的基礎上完成企業軟件開發的過程，適閤於從事軟件開發的軟件開發管理人員、係統分析師、架構師、程序員閱讀，也適閤於計算機相關專業的畢業生在就業之前瞭解企業軟件開發的過程，同時也可以作為大學計算機軟件專業項目實訓的參考教材。
　　
　　

作者簡介

王朔韜，1995年畢業於西安公路交通大學（現長安大學），從事軟件開發工作將近20年； 2004年至今，主要從事軟件企業管理谘詢工作，谘詢內容包括軟件企業開發過程谘詢及大型非軟件企業的信息化建設規劃等，谘詢的客戶包括南方航空公司、上海滬東中華造船廠等幾十傢軟件企業及大型非軟件企業； 2009年擔任IBM高校師資培訓主講老師，也承擔懷華學院計算機係部分課程的講授工作，主要研究方嚮是軟件企業開發過程改進和軟件架構。作者目前已與清華大學齣版社閤作齣版瞭《軟件是這樣“煉”成的——從軟件需求分析到軟件架構設計》、《軟件是這樣“煉”成的——軟件過程管理與軟件測試》，《軟件是這樣“煉”成的——軟件架構設計實現》是前兩本書的設計實現。

目錄

係列書引言
第一篇開發之旅起航
第1章程序員辭職報告討論
第2章設計實現過程討論
第3章關於高素質程序員的討論
3.1高素質程序員應該具有哪些
職業素養
3.2討論異常
3.3討論高質量程序代碼
3.4解讀詳細設計報告，編寫程序代碼
3.5小結
第4章投核保係統編碼規範
4.1排版規範
4.1.1注釋規範
4.1.2命名規範
4.1.3編碼規範
4.2投核保係統的代碼走查說明
4.2.1代碼走查規則
4.2.2代碼走查報告
第5章本書導讀
5.1本書的編寫思路
5.2本書結構說明及係列書關聯說明
第6章開發模式選擇
第二篇軟件開發環境設計實現
第7章搭建項目組開發環境
7.1關於項目組開發環境的討論
7.2解讀配置圖，繪製開發環境
網絡拓撲
第8章Oracle WebLogic介紹
8.1Oracle WebLogic概述
8.2Oracle WebLogic的安裝
8.3創建域
第9章Oracle數據庫介紹
9.1Oracle數據庫概述
9.2Oracle數據庫體係結構
9.2.1數據庫存儲結構
9.2.2內存結構
9.2.3實例體係結構
9.2.4實例進程結構
9.2.5數據字典
9.3Oracle産品介紹
9.3.1數據庫服務器及投核保係統
9.3.2應用服務器
9.4企業管理器
9.5Oracle客戶端工具的選擇
第10章Oracle數據庫開發環境的
搭建
10.1解讀數據庫設計報告，規劃數據庫
安裝
10.1.1解讀需求分析報告
10.1.2安裝數據庫的軟/硬件要求
10.1.3投核保係統數據庫服務器
開發時的參數
10.2安裝Oracle軟件
10.2.1Oracle 11g的下載
10.2.2Oracle 11g的安裝
10.3使用DBCA創建數據庫
10.4配置Net Configuration Assistant
第11章投核保係統軟件配置管理
過程及工具選擇
11.1關於軟件配置管理過程的討論
11.2投核保係統軟件配置過程規範
11.3投核保係統配置庫使用製度
11.4關於配置管理工具的選擇
第12章解讀配置管理計劃，搭建
配置管理環境
12.1投核保係統軟件配置管理計劃
全文
12.2CVS配置管理工具介紹
12.2.1CVS簡介
12.2.2CVS中的基本概念
12.2.3環境搭建的準備
12.3投核保係統軟件配置管理服務器
CVS的安裝與配置
12.3.1安裝及配置CVS服務器
12.3.2配置投核保係統的配置庫
結構
12.3.3CVS用戶的權限分配
12.4投核保管理係統CVS客戶端的
安裝與配置
12.4.1WinCVS客戶端的安裝
12.4.2WinCVS客戶端的配置
第13章投核保係統開發環境
配置手冊
13.1投核保係統開發環境的配置
13.2開發環境配置錶
13.2.1數據庫開發組開發環境
配置錶
13.2.2業務邏輯開發環境配置錶
13.2.3錶示層開發環境配置錶
13.3JDK 7.0的安裝與配置
13.4MyEclipse的安裝
13.5部署EJB服務
13.6安裝與配置JUnit
13.7安裝與配置Ant
13.7.1安裝Ant
13.7.2配置Ant
13.7.3Ant與JUnit的集成
13.8在MyEclipse中配置Oracle
數據源
13.9安裝Eclipse HTML Editor
第三篇基於Oracle的數據架
構設計實現
第14章投核保係統數據庫設計
報告
14.1引言
14.1.1編寫目的
14.1.2預期待和閱讀建議
14.1.3參考資料
14.2數據庫設計命名規範
14.2.1數據庫設計字符規範
14.2.2數據庫對象命名規範
14.3數據庫實體關係設計
14.4數據庫邏輯設計
14.5數據庫物理設計
14.5.1投核保係統數據庫物理設
計圖
14.5.2初始數據庫大小
14.5.3數據庫增長速度
14.5.4記錄查找的類型和平均數量
14.5.5網絡和共享訪問需求
14.5.6性能
14.5.7安全性
14.5.8數據備份和恢復
14.5.9數據庫及數據錶空間設計
14.6數據庫基本錶設計
14.7索引設計
14.8視圖設計
14.9授權設計
第15章投核保係統數據庫實施
討論
15.1數據庫實施過程討論
15.2關於優化實例內存的討論
第16章Oracle SQL簡介
16.1SQL語言概述
16.1.1SQL語言的特點
16.1.2SQL語言的編寫規則
16.2SQL語言的分類
16.3不同類型的SQL語言場景分析
16.3.1SQL查詢語言應用場景分析
16.3.2DML語言應用場景分析
16.3.3TCL語言應用場景分析
16.3.4DDL語言應用場景分析
16.3.5DCL語言應用場景分析
第17章Oracle Enterprise Management
介紹
17.1配置Oracle Enterprise Manager
17.2主目錄
17.3性能
17.3.1CPU性能
17.3.2吞吐量
17.3.3I/O
17.3.4並行執行
17.3.5服務
17.4可用性
17.4.1高可用性控製颱
17.4.2備份/恢復
17.4.3Oracle Secure Backup
17.5服務器
17.5.1存儲
17.5.2數據庫配置
17.5.3Oracle Scheduler
17.6方案
17.6.1數據庫對象
17.6.2程序
17.6.3實體化視圖
17.6.4用戶定義類型
17.7數據移動
17.8軟件和支持
17.9小結
第18章Oracle SQL Developer介紹
18.1創建數據庫連接
18.2對象瀏覽窗口
18.3使用SQL Developer調試
PL/SQL
18.4菜單欄
18.5小結
第19章SQL Plus介紹
19.1SQL Plus簡介
19.2SQL語句、PL/SQL塊和SQL
Plus命令之間的區彆
19.3SQL Plus的啓動
19.4使用SQL Plus的編輯功能
19.4.1編輯命令
19.4.2保存命令
19.4.3加入注釋
19.4.4運行命令
19.4.5跟蹤語句
19.4.6環境參數的設置
19.5小結
第20章投核保係統錶空間
設計實現
20.1關於錶空間的討論
20.2Oracle錶空間介紹
20.2.1Oracle數據存儲模型
20.2.2Oracle 11g錶空間類型
20.3解讀數據庫設計報告，規劃錶
空間
20.4使用OEM創建數據錶空間
20.5使用SQL Plus創建數據錶空間
20.6管理錶空間
20.6.1通過Oracle Enterprise Manager
管理錶空間
20.6.2通過SQL Developer管理錶
空間
第21章投核保係統數據錶
設計實現
21.1Oracle概述錶概述
21.1.1數據錶的數據類型
21.1.2數據錶的分區
21.1.3創建數據錶時的注意事項
21.2解讀數據庫設計報告，分析
數據錶
21.3使用SQL Developer創建數據錶
21.4使用SQL Plus管理數據錶
21.4.1管理錶
21.4.2管理錶分區
21.5關於優化數據錶性能的討論
第22章SQL SELECT語句研究
22.1SQL SELECT語句的格式
22.1.1SELECT語句的語法格式
22.1.2SELECT語句的編寫規則
22.1.3Oracle SELECT的執行步驟
22.2使用WHERE子句限製條件
指定行
22.3使用ORDER BY排序
22.4使用DISTINCT檢索唯一的
錶列值
22.5使用GROUP BY進行數據分組
22.6使用HAVING分組數據
22.7錶的連接
22.7.1左外連接
22.7.2右外連接
22.7.3全外連接
22.7.4自連接
22.8輸齣目標INTO子句
22.9復雜SELECT語句的使用
22.9.1集閤操作
22.9.2子查詢
22.9.3CASE語句的使用
22.10關於SQL SELECT語句
性能的討論
第23章投核保係統索引
設計實現
23.1Oracle索引概述
23.2索引類型及應用場景
23.2.1B*樹索引
23.2.2反嚮索引
23.2.3降序索引
23.2.4位圖索引
23.2.5函數索引
23.3索引分區
23.3.1全局索引的特點
23.3.2本地索引的特點
23.4解讀數據庫設計報告，分析
數據錶索引
23.5使用SQL Developer創建索引
23.6使用SQL Plus管理索引
23.6.1建立索引
23.6.2管理索引
23.6.3管理索引分區
23.7關於索引性能的討論
第24章投核保係統視圖
設計實現
24.1視圖介紹
24.1.1視圖的概念
24.1.2視圖的優點
24.1.3視圖的分類
24.2解讀數據庫設計報告，設計視圖
24.3使用SQL Developer創建視圖
24.4使用SQL Plus管理視圖
24.4.1創建視圖
24.4.2更改視圖
24.4.3刪除視圖
24.4.4查看視圖
第25章存儲過程與觸發器
設計實現
25.1存儲過程介紹
25.1.1存儲過程的概念
25.1.2存儲過程的優點
25.1.3存儲過程的語法格式
25.2觸發器介紹
25.2.1觸發器的概念
25.2.2觸發器的語法格式
25.2.3觸發器的組成
25.3解讀數據庫設計報告，規劃存儲
過程與觸發器
25.3.1存儲過程的規劃
25.3.2觸發器的規劃
25.4使用SQL Developer開發觸發器
25.5使用SQL Developer開發存儲
過程
25.5.1創建存儲過程
25.5.2修改存儲過程
25.6存儲過程例程
第26章投核保係統數據庫
用戶管理
26.1Oracle用戶、角色、權限和模式
26.2解讀數據庫設計報告，規劃角色
26.2.1DBA角色的規劃
26.2.2開發者角色的規劃
26.2.3公司管理層對象的操作授權
26.2.4部門管理的操作授權
26.2.5公司業務人員的操作授權
26.3創建和管理角色
26.3.1創建角色
26.3.2通過SQL Plus管理角色
26.3.3查看角色
26.4使用者組
26.5創建和管理用戶賬戶
26.5.1使用Oracle Enterprise Manager
完成用戶的創建
26.5.2使用SQL Plus管理用戶
第27章投核保係統數據庫安全性
設計實現
27.1Oracle安全性設計要求
27.2解讀數據庫設計報告，管理用戶
資源
27.2.1用戶資源的基本概念
27.2.2投核保係統用戶資源配置錶
27.3Oracle用戶資源配置的設計實現
27.3.1使用Oracle Enterpeise
Management配置用戶
資源
27.3.2使用SQL Developer創建
概要文件
27.4Oracle數據庫審計
27.4.1審計的概念
27.4.2投核保係統的用戶角色
審計說明
27.4.3使用Oracle Enterprise
Management實現審計
功能
27.5透明數據加密
第28章關於數據庫設計實現
總結
第四篇基於Struts 2.0+EJB 3.0
的軟件架構設計實現
第29章開發模式與開發流程
討論
29.1開發模式的討論
29.2開發流程的討論
第30章本篇導讀
30.1編寫原因及思路
30.1.1編寫本篇的原因
30.1.2編寫本篇的思路
30.2本篇的組織
第31章使用MyEclipse配置
WebLogic
31.1在MyEclipse中配置WebLogic
服務器
31.2在MyEclipse中配置WebLogic
開發包
第32章在MyEclipse中創建工程包
和Java文件
32.1關於工程文件的討論
32.2解讀投核保係統的包設計，規劃
工程文件
32.2.1工程文件的設計原則
32.2.2解讀投核保係統包圖,完成
工程文件的設計
32.3使用MyEclipse創建工程、包和
程序文件
32.3.1創建工程
32.3.2創建包
32.3.3創建Java程序
第33章投核保係統異常設計
實現
33.1關於異常的討論
33.2預備知識
33.2.1Java異常
33.2.2業務異常
33.3異常處理設計
33.3.1程序異常處理流程
33.3.2業務異常處理方法
33.4異常設計實現
33.4.1接口程序
33.4.2異常處理實現程序
第34章EJB 3.0簡單介紹
34.1會話Bean
34.1.1無狀態會話Bean
34.1.2有狀態會話Bean
34.1.3有狀態會話Bean和無狀態
會話Bean的區彆
34.2實體Bean
34.3消息驅動Bean
34.4事務管理
34.5小結
第35章投核保係統數據庫
連接實現
35.1JDBC基礎
35.1.1預備知識
35.1.2JDBC連接數據庫的流程
及原理
35.1.3Oracle的JDBC驅動方式
35.2數據庫連接的討論
35.2.1關於數據庫産品用戶數
的討論
35.2.2關於JDBC連接數據庫
性能的討論
35.3數據庫連接的實現
35.3.1數據庫連接與Oracle用戶
權限問題
35.3.2程序結構設計
35.3.3數據源配置參數的設置
35.4數據庫連接的代碼
第36章Java調用存儲過程的
基本流程
36.1存儲過程簡述

精彩書摘

　　第3章關於高素質程序員的討論
　　特彆說明，本章部分內容轉自作者本人專著《軟件是這樣“煉”成的——從軟件需求分析到軟件架構設計》的第28章，不管你是否讀過這本書，建議你不要跳過本章閱讀，請你耐心看完，必有收獲。
　　3.1高素質程序員應該具有哪些職業素養
　　談到高素質程序員，其不僅具有高超的技術水平，還應該具有職業素養和工作能動性。在這裏我對程序員應該具有的職業素養做一下簡單介紹。
　　首先，如果真想做程序員，應該肯定地認為選擇做程序員符閤自己的興趣和誌嚮，是對自己智慧和能力的挑戰，如果不想在這個職業裏混，那就什麼也談不上瞭。一個人要有所成就，就需要在一個行業中積纍一段時間，這樣纔能獲得足夠的經驗值。
　　其次，我們在做事的時候要主動，越主動，我們得到的機會就會越多。在我們公司，張偉本是一個初級程序員，但是他的工作業務水平很不錯，平常也樂意幫助彆人。有一次公司要開發一個MIS係統，這個係統要用到Oracle數據庫，由於我們公司第一次使用Oracle數據庫，沒有人懂得這些知識，我當時挑選瞭一位我認為不錯的程序員——張偉來負責Oracle數據庫的安裝與建庫等工作，但是這位程序員建議公司派他齣去培訓。有一天，張偉告訴我，他已經基本掌握瞭Oracle數據庫的應用，他是在公司下班後利用業餘時間鑽研的，我當時很感動，並且答應瞭他的要求，結果張偉做得確實不錯，就這樣，我給他瞭更多的機會讓他成長，使他在公司裏的地位各方麵都有所上升。我們說到主動，在做軟件的過程中，一種狀態是等客戶提供需求，然後規規矩矩地將其實現，這是一個閤格的程序員的做法； 另外一種做法則是能夠主動齣擊，能夠將其他軟件的一些優點也提供給用戶，逐步從被用戶牽著走到自己引導客戶轉變，這實際上是信息地位的變化，誰處在引導者地位，誰就在實際情況中處於優勢地位，對於這一點大傢可以多體會一下。
　　再次，在我們這個職業當中，掌握與計算機相關的知識並且具有寬知識麵是非常有用的，做軟件的人需要瞭解硬件，做.Net的人需要瞭解Java，做行業軟件需要瞭解通用軟件，為什麼這樣說呢，因為在現實當中我們會碰到很多復雜的情況需要解決，客戶的需求是會不斷變化的，我們要通過較寬的知識麵理解和挖掘客戶需求。
　　我們應該把Java學好，因為投核保係統本身應用的是基於Java技術的Java EE技術，如果我們能夠很好地理解和應用Java知識，在學習和應用Java EE的過程中就會非常輕鬆，並且能夠編寫齣高質量的Java程序。
　　如果要成為一位高素質的程序員，不僅應該具有職業素質，還應該具有高的技術水平，比如說如何處理異常，如何編寫齣高質量的程序代碼，如何解讀詳細設計編程程序等。下麵我們對程序員的Java技術要求方麵展開討論。
　　3.2討論異常
　　晨落： 請大傢迴答一個問題，一個項目運行的可靠性和穩定性是由什麼決定的？
　　JackJeff： 決定因素是對語法的熟練程度和算法是否很精煉。
　　晨落： 我們在編寫一段程序代碼的過程中主要考慮哪些方麵的內容？
　　JackJeff： 主要考慮語法應用、算法是否精煉和對資源的消耗，爭取做到在資源低消耗的情況下提高程序的運行速度。
　　晨落： 請你編寫一段代碼，這段代碼是按行讀取A驅動器上名為good.txt的文件。
　　JackJeff： 用什麼語言？
　　晨落： Java。
　　JackJeff的代碼如下：
　　Importjava.io.BufferedReader;
　　importjava.io.BufferedWriter;
　　importjava.io.FileReader;
　　importjava.io.FileWriter;
　　importjava.io.IOException;
　　importjava.text.
　　public class ReadFromFile {
　　/**
　　* 以行為單位讀取文件，常用於讀麵嚮行的格式化文件
　　*/
　　public static void readFileByLines(String fileName)
　　{
　　File file = new File(fileName);
　　BufferedReader reader = null;
　　System.out.println("以行為單位讀取文件內容，一次讀一整行： ");
　　reader = new BufferedReader(new FileReader(file));
　　String tempString = null;
　　int line = 1;
　　//一次讀入一行，直到讀入null時文件結束
　　while ((tempString = reader.readLine()) != null)
　　{
　　//顯示行號
　　System.out.println("line " + line + ": " + tempString);
　　line++;
　　}
　　reader.close();
　　}
　　public static void main(String［］ args)
　　{
　　String fileName = "A:/ good.txt";
　　ReadFromFile.readFileByLines(fileName);
　　}
　　}
　　晨落： 我們來分析一下你的程序代碼，你覺得有沒有必要完善一下以上的程序代碼？
　　JackJeff： 沒有。
　　晨落： 如果A驅動器中沒有盤怎麼辦？
　　JackJeff： 這需要客戶來控製異常信息輸入，不是編程人員思考的問題。
　　晨落： 那你覺得程序員的主要任務是什麼？
　　JackJeff： 程序員的主要任務就是編寫好自己的代碼。
　　晨落： 你的編程思想是不少程序員的基本思想，在編程的過程中隻關注程序代碼，不關注程序異常。你編寫的實現讀取A驅動器中文件的程序至少有20多個異常可能發生，然而在你編寫的程序代碼中沒有對這些異常進行任何處理。按正常情況，程序員應該將70%左右的時間花在程序異常處理中。但我們的程序員幾乎很少思考異常，特彆是對業務異常的思考更少。
　　JackJeff： 那麼異常是什麼意思？為什麼要處理異常？
　　晨落： 按照正常詞匯解釋，異常就是不同於正常情況的狀態。異常屬於中性詞，比如異常的好、異常的壞等，異常這個詞匯可以用到不同的場景，具有修飾的作用。在大型軟件開發中，最大的問題就是錯誤連篇的、不穩定的代碼。而在設計與實現中，最大的開銷花在測試、查找和修改錯誤上。程序的異常一種是編譯錯誤，一種是運行時發生的錯誤，還有一種是我們經常忽略的業務邏輯錯誤。邏輯錯誤是由於不當的設計造成的，一般隻有用戶做瞭某些齣乎意料的事纔齣現。運行異常可以預料，但不能避免，它也是由於不當的設計造成的。這些錯誤會使程序變得脆弱，然而這些錯誤是能夠預料的，通常加入一些預防代碼即可防止這些異常發生。有些異常是設計和開發過程中最容易忽略的異常，這種異常給客戶帶來的損失往往是非常大的甚至是緻命的。
　　JackJeff： 在係統架構過程中我們如何規劃和設計異常？將異常設計作為係統架構的重要組成嗎？
　　晨落： 這正是本章需要考慮的問題，我們後麵將詳細介紹，並針對投核保係統具體項目規劃異常。
　　JackJeff： 異常處理的重要性在哪裏？
　　晨落： 任何一個係統架構必須充分考慮係統的異常並且及時捕獲異常有效處理，沒有考慮異常的係統就如同沒有消防通道的大樓一樣，一旦發現異常對係統來說往往是毀滅性的。
　　JackJeff： 投核保係統的異常處理包含瞭哪些內容？
　　晨落： 為瞭滿足用戶需求，增強係統的可靠性和可維護性，在投核保係統中專門設計瞭一套異常處理機製，正確地運用這套機製有助於提高程序的健壯性。所謂程序的健壯性就是指程序在多數情況下能夠正常運行，返迴預期的正確結果； 如果偶爾遇到異常情況，程序也能采取周到的解決措施。不健壯的程序則沒有事先充分預計到可能齣現的異常，或者沒有提供強有力的異常解決措施，導緻程序在運行時經常莫名其妙地終止，或者返迴錯誤的運行結果，而且難以檢測齣現異常的原因。所以，在係統架構中將異常作為重要內容進行設計是非常有必要的，也是非常重要的。
　　3.3討論高質量程序代碼
　　晨落： 剛纔和JackJeff就異常處理進行瞭討論，在這部分內容中，我們僅僅是拋磚引玉地拋齣瞭一個主題，那就是程序員不僅僅是語法的使用者，更多的是需要從工程的角度、質量的角度進行思考。所以，下麵針對高質量程序代碼方麵和大傢進行討論，在這裏我所錶述的內容隻是本人對Java高質量程序代碼的理解，不代錶高質量程序代碼的標準。請各位踴躍討論，共同學習。
　　張磊： 老師，對於JackJeff的代碼，您提到瞭異常處理的重要性，我建議我們現在對Java程序中的異常問題進行討論，請問如何確定異常情況呢？
　　晨落： 我將異常分為兩大類，當然不同的人有不同的分法，我將異常分為業務異常和程序異常兩大類。業務異常其實是可控製的，也是可預計的，隻要按照業務規則或數據字典對數據和業務進行異常捕獲，並且定義異常處理類處理異常即可。難度在於雖然程序異常處理瞭，但有許多異常是不可預見的。
　　張偉： 對這個問題我有些理解，我說一下我的觀點，看大傢能否接受？
　　晨落： 太好瞭，我希望大傢共同討論、共同學習，不希望以說教的方式來告訴大傢知識，而是通過討論和大傢的思考最終使大傢深刻理解每個知識點。請張偉談一談對程序異常方麵的看法。
　　張偉： 異常不是在任何情況下都適用，但是，一旦決定使用異常就必須按照異常的規則執行異常。比如說如何確定需要拋齣的異常，異常與方法的關係，用Error的子類來錶示係統級的異常和程序不必處理的異常，用鏈式異常來保存原始異常信息。我總結瞭異常處理的幾個經驗。
　　王鵬： 你可以再詳細說一下嗎？
　　張偉： 首先，如果是可恢復錯誤,使用檢查型異常;如果是編程錯誤,使用非檢查型異常。許多Java編程人員很苦惱,到底是該選擇檢查型異常還是選擇非檢查型異常。檢查型異常是一種從語言到強製程序員編寫代碼的一種方式,可以保證程序員對錯誤條件提供異常處理代碼,但同時會引入大量雜亂的代碼導緻其不可讀。如果程序員有恢復策略,這樣做看起來似乎也可以。其次，在Java程序處理異常後要適當地釋放資源。Java程序員對此都有所瞭解,在處理網絡和IO類的時候相當於一個標準。在finally塊中關閉資源,在正常和異常執行的情況下保證之前和稀缺資源的閤理釋放,這由finally塊保證。第三，始終提供關於異常的有意義的完整信息，異常信息非常重要,因為這是Java程序員最先看到的一個地方,在這裏會有非常精確並且真實的信息,他們可以找到問題産生的根本原因。第四，避免過度使用檢查型異常，雖然檢查型異常在強製執行方麵有一定的優勢,但同時它也破壞瞭代碼,通過掩蓋業務邏輯使代碼的可讀性降低。所以,Java程序員要注意不能過度使用檢查型異常,可以最大程度地減少這類情況,這樣會得到更精準、簡潔的代碼。第五，對於性能而言,異常的代價比較高,還會讓代碼的運行變得緩慢。如果你有方法從ResultSet中進行讀取,這時常會拋齣SQLException異常而不會移到下一個元素,這將會比不拋齣異常的正常代碼的執行速度慢很多。因此，Java程序員要最大限度地減少不必要的異常捕捉和移動。如果你能使用boolean變量錶示執行結果,而不僅僅是拋齣和捕捉異常,你就可能得到更簡潔、性能更高的解決方案。第六，沒有什麼比空的catch塊更糟糕的瞭,因為它不僅隱藏瞭錯誤和異常,還可能導緻你的對象處於不可使用的狀態。空的catch塊沒有任何意義,如果你非常肯定異常不會繼續以任何方式影響對象狀態,在程序執行期間用日誌記錄錯誤依然是最好的方法。最後，Java提供瞭throw和throws關鍵字來拋齣異常,在Javadoc中用@throw記錄任何方法可能會拋齣的異常。如果我們編寫API或者公共接口,這就變得非常重要。任何方法拋齣的異常都有相應的文檔記錄,這樣你就能提醒任何使用該方法的人，為係統的維護提供瞭很大的方便。
　　張亮： 老師，高質量的程序代碼包括代碼風格的約定嗎？
　　晨落： 當然包括瞭，但是我們今天不對此進行討論，我們將專門設一個章節討論Java代碼的風格和規範問題。內存管理是編寫Java程序必須考慮的問題之一，如果不閤理地使用內存將會影響Java代碼的質量等。請問誰可以說明分析一下？
　　張傑： 我對這個概念雖然明白，但是沒有思考過太多。老師，請問Java是如何管理內存的？
　　晨落： Java的內存管理包括對象的分配和釋放兩個部分。內存的分配是由程序完成的，程序員需要通過關鍵字new為每個對象申請內存空間(基本類型除外)，所有的對象都在堆(Heap)中分配空間。內存的釋放是由垃圾迴收機製決定和執行的，這樣做確實簡化瞭程序員的工作，但同時也加重瞭JVM的工作。因為GC為瞭能夠正確地釋放對象，必須監控每一個對象的運行狀態，包括對象的申請、引用、被引用、賦值等。
　　韓磊： 那麼什麼叫Java的內存泄漏呢？
　　晨落： 在Java中，內存泄漏就是存在一些被分配的對象，這些對象有下麵兩個特點。首先，存在該內存對象的引用； 其次，這些對象是無用的，即程序以後不會再使用這些對象。如果對象滿足這兩個條件，這些對象就可以被判定為Java中的內存泄漏，這些對象雖然不會被GC迴收，但是它卻占用內存。
　　田亮： 請問老師，內存有哪些類型，如何使用內存呢？
　　晨落： Java把內存分兩種，一種是棧內存，另一種是堆內存。
　　在函數中定義的基本類型變量和對象的引用變量都在函數的棧內存中分配； 堆內存用來存放由new創建的對象和數組以及對象的實例變量，在函數(代碼塊)中定義一個變量時，Java就在棧中為這個變量分配內存空間，當超過變量的作用域後，Java會自動釋放掉為該變量分配的內存空間； 在堆中分配的內存由Java虛擬機的自動垃圾迴收器來管理。
　　堆的優勢是可以動態地分配內存大小，在生存期也不必事先告訴編譯器，因為它是在運行時動態地分配內存的。其缺點是要在運行時動態地分配內存，存取的速度較慢。
　　棧的優勢是存取速度比堆快，僅次於直接位於CPU中的寄存器。另外，棧數據可以共享，缺點是保存在棧中的數據大小與生存期必須是確定的，缺乏靈活性。
　　郭濤： 什麼時候需要注意內存泄漏？
　　晨落： 如果在你的程序執行一段時間之後遇到Java.lang.OutOfMemoryError，內存泄漏無疑是最值得懷疑的。那麼除瞭這種明顯的情況以外，什麼時候需要考慮內存泄漏？如果要求更高，內存泄漏都需要進行審查和更改。然而，在跳到這一結論之前還需要考慮其他幾個因素，即程序的生命周期以及內存泄漏的大小。考慮一下在一個程序的生命周期裏垃圾收集器可能從未執行的情況，無法保證什麼時候JVM會調用垃圾收集器——程序顯式調用System.gc()。通常情況下，垃圾收集器不會自動運行，直到程序需要比目前的可用內存還要多的內存。此時，JVM會首先嘗試調用垃圾收集器以獲取更多的可用內存。如果這個嘗試仍然不能夠釋放齣足夠的資源，JVM將會從操作係統獲取更多的內存，直到達到允許的內存的最大值。
　　郭濤： 那如何判斷內存泄漏呢？
　　晨落： 查看一個運行在Windows平颱上的Java程序是否內存泄漏，可以簡單地在程序運行的時候觀察任務管理器中的內存設置。然而，我們在觀察一些運行中的Java程序之後會發現，它們與本地應用程序相比使用瞭更多的內存。我開發過的一些Java項目會啓用10~20MB的係統內存。與這個數字相比，本地的操作係統自帶的Windows Explorer程序使用5MB。
　　對於Java程序的內存使用，另一個需要注意的是典型的運行在IBM JDK 1.1.8 JVM上的程序似乎在其運行時不斷吞噬瞭越來越多的係統內存，程序似乎永遠不會返迴一些內存給操作係統，直到將一個非常大的物理內存分配給它，這會不會就是內存泄漏的跡象。
　　如果要明白怎麼迴事，需要熟悉JVM是如何將係統內存用作自己的堆的。在運行Java.exe時，你可以使用一些特定的選項來控製垃圾收集的堆的啓動容量和最大容量(分彆是�瞞s和�瞞x)。Sun的JDK 1.1.8默認使用1 MB的啓動設置和16 MB的最大設置。IBM JDK的1.1.8默認使用計算機的物理內存容量的一半作為最大設置。這些內存設置對JVM發生內存溢齣時的做法具有直接影響，這時JVM可能會繼續增加堆內存，而不是等待一個垃圾迴收的結束。
　　因此，為瞭尋找並最終消除內存泄漏，需要用比任務監視程序更好的工具。當你想檢測內存泄漏的時候，內存調試程序就可以派上用場瞭。這些程序通常會給你堆內存裏對象的數量、每個對象實例的個數以及對象使用中的內存等信息。此外，它們還會提供很有用的視圖，這些視圖可以顯示每個對象的引用和引用者，以便你跟蹤內存泄漏的來源。
　　田亮： 請問如何防止內存泄漏？
　　晨落： 通過對一些常見問題的注意來防止內存泄漏。容器類（比如哈希錶和嚮量）是常見的找到引起內存泄漏的地方，尤其是當這些類被聲明為靜態的並存活於應用程序的整個生命周期之中時。另一個常見的導緻內存泄漏的問題是你將一個類注冊為事件監聽器，卻沒有考慮當這個類不再需要時將其注銷，還有就是指嚮其他類的成員變量在恰當的時候要設置為null。當然不僅僅是這些。
　　張偉： 各種對象關係如何處理，能夠給一個好的建議嗎？
　　晨落： 這是一個很大的話題，但是我覺得考慮以下幾點就可以瞭。第一，盡量用接口代替抽象類； 第二，不要同時使用重載和覆蓋等； 第三，正確地使用集成錶示分類關係； 第四，盡量用組閤錶示包含關係。
　　李銳： Java程序的執行性能是衡量代碼質量的重要內容之一，那麼請問老師，對於性能方麵你有哪些建議呢？
　　晨落： 對於Java性能方麵，我總結瞭一些經常采用的方法和技巧供大傢參考。第一，Java程序設計中的一個普遍問題就是沒有好好地利用Java語言本身提供的函數，從而經常會生成大量的對象(或實例)。由於係統不僅要花時間生成對象，以後還可能需要花時間對這些對象進行垃圾迴收和處理，因此生成過多的對象將會給程序的性能帶來很大的影響，建議大傢盡量采用Java語言本身提供的函數。第二，對於異常方麵，在Java語言中提供瞭try/catch來方便用戶捕捉異常，進行異常的處理，但是如果使用不當，也會給Java程序的性能帶來影響。因此，大傢要注意一些技巧，比如避免對應用程序的邏輯使用try/catch，如果可以用if、while等邏輯語句來處理，那麼就盡可能不用try/catch語句。另外還有重用異常，在必須進行異常的處理時要盡可能重用已經存在的異常對象。因為在異常的處理中，生成一個異常對象要消耗掉大部分的時間。第三，在一個高性能的應用程序中一般都會用到綫程，因為綫程能夠充分利用係統的資源。在其他綫程因為等待硬盤或網絡讀寫時，程序能繼續處理和運行。但如果對綫程運用不當，也會影響程序的性能。第四，輸入和輸齣包括很多方麵，但涉及最多的操作是對硬盤、網絡或數據庫的讀寫操作。對於讀寫操作，又分為有緩存和沒有緩存的； 對於數據庫的操作，又有多種類型的JDBC驅動器可以選擇，但無論怎樣都會給程序的性能帶來影響，比如使用輸入輸齣緩衝盡可能地多使用緩存。如果要經常對緩存進行刷新(flush),則建議不要使用緩存。又如輸齣流(Output Stream)和Unicode字符串，當使用Output Stream和Unicode字符串時，Write類的開銷比較大，因為它要實現Unicode到字節(byte)的轉換。因此，如果有可能,在使用Write類之前就實現轉換或用OutputStream類代替Writer類來使用。如果使用String字符串進行寫入，使用FileWriter比用OutputStream性能好。第五，還有一些小技巧，例如使用局部變量，避免在同一個類中通過調用函數或方法(get或set)來設置或調用變量，避免在循環中生成同一個變量或調用同一個函數(參數變量也一樣)，盡可能地使用static、final、private等關鍵字。在復製大量數據時，通常使用System.arraycopy()。
　　……

前言/序言

　　經過多年的積纍以及整理和思考，“軟件是這樣‘煉’成的”係列書終於在艱難中“分娩瞭”，《軟件是這樣“煉”成的——從軟件需求分析到軟件架構設計》和《軟件是這樣“煉”成的——軟件過程管理與軟件測試》相繼齣版發行，讀者數量也不錯，有許多忠實的讀者通過微信和QQ消息發來瞭最為誠懇的建議，這些讀者給瞭我繼續寫下去的動力。本書書名為《軟件是這樣“煉”成的——軟件架構設計實現》，這本書的齣版完成瞭一個項目的全程記錄，將投核保係統項目的全部過程展現給讀者，讓讀者通過項目感悟項目開發過程中可能遇到的各種挫摺及解決問題的思路。
　　本係列書的最大特點是將學院派和應用派的兩大著書思想有效地結閤起來，既沒有專注講空洞的理論，也沒有專注於講寬泛的應用，將理論與實踐融閤起來，能夠給讀者以新的感受和收獲。在文字組織上，本係列書采取瞭場景再現、情景對話等方式，將軟件企業開發過程中的軟件過程改進、軟件過程管理和軟件測試過程全麵展現給讀者。本書自始至終使用保險公司的投核保係統作為唯一案例，將軟件開發的各個環節串連起來，使得讀者能夠係統地、完整地瞭解項目開發的全部過程。
　　本書由四篇共50章組成。第一篇“開發之旅起航”以投核保係統為案例，通過敘事方式分析軟件編程設計過程中存在的問題，並且引齣瞭投核保係統的開發模式； 第二篇以投核保係統配置圖為設計依據，全麵介紹瞭各種工具的安裝與配置過程； 第三篇是以投核保係統為案例，以投核保係統數據架構設計為唯一依據，介紹瞭基於Oracle的數據架構設計實現過程； 第四篇是以投核保係統詳細設計架構為設計依據，介紹瞭基於Struts 2.0和EJB 3.0的技術方法將軟件架構設計最終落實到具體的代碼上。
　　《軟件是這樣“煉”成的——從軟件需求分析到軟件架構設計》和《軟件是這樣“煉”成的——軟件過程管理與軟件測試》兩本書齣版以後得到瞭廣大讀者的殷切關注和大力支持，並且提齣瞭許多寶貴的意見，這裏錶示真心的感謝，希望各位繼續提齣寶貴的意見。
　　在本書的編寫過程中得到瞭傢人和朋友的大力支持，在此我要感謝我的妻子商莉和我的女兒王貝思給予我的最大的支持，同時感謝我的好朋友羅少木和薑偉給予我的幫助和大力支持。
　　由於作者水平有限，書中難免有疏漏和不足之處，懇請各位專傢和廣大讀者提齣寶貴的意見。如果讀者在閱讀過程中遇到問題，可以直接和本人聯係。
　　作者2017年5月

評分☆☆☆☆☆

買來學習的，點個贊吧，希望學習到有用的知識呢，開始學習咯

評分☆☆☆☆☆

東西看著不錯，物流很好。

評分☆☆☆☆☆

後好好好好！！！！！！

評分☆☆☆☆☆

書本的包裝差瞭點，有點褶皺，不過物流是真心的快

評分☆☆☆☆☆

還沒看

評分☆☆☆☆☆

買來學習的，點個贊吧，希望學習到有用的知識呢，開始學習咯

評分☆☆☆☆☆

東西看著不錯，物流很好。

評分☆☆☆☆☆

東西看著不錯，物流很好。

評分☆☆☆☆☆

東西看著不錯，物流很好。