完美代碼

《完美代碼》簡單明了地介紹了軟體開發中的最佳實踐,展示了工程流程在編寫優質代碼上的重要性以及測試的重要性,總結了很多資深工程師的經驗教訓,並提供了很多真實案例。書中介紹的經驗可以套用到產品開發周期的每個環節,從設計到開發以及最後的發布和維護。《完美代碼》的中心思想就是要在設計和實現的過程中改進代碼質量,包括類建模、性能、安全性、記憶體使用以及調試,幫助讀者構建完美的項目。《完美代碼》適合專業及業餘程式設計師閱讀。

基本介紹

  • 書名:完美代碼
  • 出版社:機械工業出版社
  • 頁數:229頁
  • 開本:16
  • 品牌:機械工業出版社
  • 作者:馬歇爾(Donis Marshall) John Bruno
  • 出版日期:2010年1月1日
  • 語種:簡體中文
  • ISBN:9787111292401
基本介紹,內容簡介,作者簡介,媒體推薦,圖書目錄,序言,

基本介紹

內容簡介

《完美代碼》:採用一流的工程實踐來幫助你編寫更健壯、無錯的代碼。兩位微軟的.NET開發專家與你分享最佳化軟體開發生命周期的真實案例和經過實戰考驗的解決方案——從避免代價昂貴的編程陷阱,到提高開發團隊整體效率的方法等。無論你是來自哪個層次的託管代碼程式設計師,都能在這裡找到設計、原型開發、實現、調試以及測試的技巧,進一步提升代碼的品質。

作者簡介

作者:(美國)馬歇爾(Donis Marshall) (美國)John Bruno 譯者:徐旭銘
Donis Marshall 是Debuglive.com的CEO,他管理的專家軟體工程師團隊開發出第一個基於Web的Windows應用程式調試器。憑藉20年的開發經驗以及深厚的微軟.NET背景,他編寫了好幾本書,其中包括《Programming Microsoft Visual C# 2008: The Language and .NET Security Programming》。Donis還是一名培訓師和諮詢師,專門講授並主持關於.NET編程、調試、安全性以及設計和架構的研討會 。
John Bruno 是微軟的資深程式經理,有著超過10年的套用開發經驗,他擅長使用微軟.NET技術來設計並構建可擴展的Web套用和服務。加入微軟以來,John對Windows Live的發布起到重要作用,同時他還負責Windows Live Spaces的服務架構和程式設計師平台,Windows Live Spaces目前在全世界的用戶數超過了1億。現在他的主要精力都放在了開發Windows Mobile下一代Web服務上。

媒體推薦

《完美代碼》在管理書籍和技術書籍之間做到了出色的平衡。從如何進行軟體建模,到安全性設計,再到防禦性編程,本書展示了可以改進開發工作的各種最佳實踐。
——Wintellect聯合創始人,John Robbins
《完美代碼》不僅僅是一本關於代碼的書,它闡述了如何開發一個健壯的項目。這本書簡單明了地介紹了軟體開發中的最佳實踐,並提供了很多實際產品中的案例和經驗教訓,幫助讀者構建完美的項目——從設計到開發,以及最後的發布和維護。
——微軟.軟體開發工程師,Jason Blankman
作為一名有20年經驗的軟體工程師,能讓我每過幾年就重讀一遍的書並不多見,而《完美代碼》就是其中之一,每次溫故都能知新。
——微軟,軟體開發工程師,Don Reamey
對任何專業軟體工程師來說,《完美代碼》的價值都是無法衡量的,書中到處都是可以立刻投入使用的實踐經驗。《完美代碼》絕對是一本讓你愛不釋手的必讀書籍。
——ALL Software執行股東,微軟區域總裁,John Alexander
《完美代碼》對任何rr從業人員來說都是必讀書籍,特別是如果你打算使用託管代碼的話。它不僅涵蓋了工程上的最佳實踐,還通過已經過實踐檢驗的案例來展示它們。
——微軟,發布經理,Andres Juarez
這本書提供了在高效軟體開發過程中的最佳實踐,因此可以避免很多典型的程式設計師錯誤。作者提供了可實踐的檢測錯誤的方案,並解釋了微軟是如何進行軟體開發和測試的。
——微軟,測試經理,Venkat B.Iyer
無論你是新手還是專家,任何級別的程式設計師都可以閱讀本書。它為優秀的開發實踐提供了堅實的基礎,不管開發團隊的規模是大還是小,甚至只有一名程式設計師,也應該採用書中的經驗。
——獨立軟體工程師,John Macknight

圖書目錄

專家推薦

前言
第1章 敏捷世界裡的代碼質量
1.1 軟體開發的傳統方法
1.2 軟體開發的敏捷方法
1.2.1 Scrum
1.2.2 eXtremeProgramming
1.2.3 測試驅動開發
1.3 儘早進行質量控制
1.4 微軟內幕:WindowsLiveHotmail工程
1.4.1 工程準則
1.4.2 成功的關鍵因素
1.5 編寫堅實代碼的方法
1.5.1 專注設計
1.5.2 防禦和調試
1.5.3 分析與測試
1.5.4 改進流程和態度
1.6 總結
1.7 本章要點

第2章 類設計和原型開發
2.1 VisualStudio中的協作
2.2 磨刀不誤砍柴工
2.3 軟體建模
2.3.1 統一建模語言
2.3.2 Visio示例
2.4 原型開發
2.5 跟蹤
2.6 VisualStudio類設計器
2.6.1 創建一個類圖
2.6.2 使用類設計器進行原型開發
2.6.3 原型開發示例
2.7 總結
2.8 本章要點

第3章 元編程
3.1 什麼是元數據
3.2 託管套用里的元數據
3.3 應用程式中的元數據
3.4 微軟內幕:Windows Live Spaces中的配置管理
3.5 總結
3.6 本章要點

第4章 性能也是功能
4.1 常見的性能難點
4.1.1 網路延時
4.1.2 負載大小和網路往返時延
4.1.3 受限的TCP連線
4.1.4 未最佳化的代碼
4.2 分析應用程式性能
4.3 提升Web套用性能的技巧
4.3.1 減小負載大小
4.3.2 有效利用快取
4.3.3 最佳化網路通信
4.3.4 為性能組織編寫代碼
4.4 採用性能最佳實踐
4.5 微軟內幕:解決LiveSearch的性能問題
4.5.1 Web性能準則
4.5.2 成功的關鍵要素
4.6 總結
4.7 本章要點

第5章 伸縮性設計
5.1 理解應用程式伸縮性
5.1.1 伸縮性之路
5.1.2 資料庫的伸縮性
5.2 伸縮Web應用程式的技巧
5.2.1 選擇可伸縮的應用程式設計
5.2.2 設計可伸縮的應用程式基礎設施
5.2.3 抵禦應用程式故障
5.2.4 保證可管理性和可維護性
5.3 微軟內幕:管理Windows Live Messenger服務基礎設施
5.4 總結
5.5 本章要點

第6章 安全性設計和實現
6.1 常見的應用程式安全威脅
6.2 設計安全的應用程式的原則
6.3 安全的應用程式的SD3+C策略和實踐
6.3.1 設計上的安全性
6.3.2 默認值的安全性
6.3.3 部署和通信中的安全性
6.4 理解.NET框架的安全性原則
6.4.1 運行時安全策略
6.4.2 代碼訪問安全
6.4.3 套用運行時安全策略
6.5 其他安全性最佳實踐
6.6 總結
6.7 本章要點

第7章 託管記憶體模型
7.1 託管堆
7.2 垃圾回收
7.2.1 原生對象的託管包裹
7.2.2 GC類
7.2.3 大型對象堆
7.3 終止
7.3.1 不確定的垃圾回收
7.3.2 可丟棄對象
7.3.3 丟棄模式
7.3.4 弱引用
7.4 固定
7.5 託管堆的技巧
7.6 CLR Profiler
7.7 總結
7.8 本章要點

第8章 防禦式編程
8.1 防禦式編程和C#
8.2 警告
8.3 代碼檢查
8.4 軟體測試
8.4.1 測試驅動開發
8.4.2 代碼覆蓋
8.4.3 自我描述的代碼
8.4.4 命名規則
8.4.5 偽代碼
8.4.6 注釋
8.5 用類實現防禦式編程
8.5.1 修飾符
8.5.2 接口
8.6 防禦式編程小結
8.7 設計模式
8.8 總結
8.9 本章要點

第9章 調試
9.1 溢出bug
9.2 Pentium FDIV bug
9.3 符號
9.3.1 符號伺服器
9.3.2 源碼伺服器
9.4 搶先式調試
9.5 主動型調試
9.5.1 託管調試助手
9.5.2 MDA舉例
9.5.3 代碼分析
9.5.4 性能監視
9.6 調試
9.7 調試工具
9.7.1 VisualStudio
9.7.2.NET框架工具
9.7.3 Windows調試工具
9.7.4 CLR Profiler
9.7.5 Sysinternals
9.8 跟蹤
9.8.1 Web應用程式跟蹤
9.8.2 異常處理
9.9 生產調試
9.10 總結
9.11 本章要點

第10章 代碼分析
10.1 投資測試過程
10.1.1 定義測試的節奏
10.1.2 建立測試工作項的跟蹤
10.2 採用自動化的代碼分析
10.2.1 使用靜態代碼分析工具
10.2.2 編寫應用程式測試代碼
10.2.3 使用VisualStudio進行測試
10.3 通過度量來理解質量
10.3.1 衡量代碼的複雜度和可維護性
10.3.2 通過透視來理解質量
10.4 微軟內幕:Microsoft.com的Web分析平台的質量管理
10.4.1 代碼質量的重要性
10.4.2 測試投資
10.4.3 管理質量
10.5 總結
10.6 本章要點

第11章 改進工程流程
11.1 工程流程改進的技巧
11.1.1 建立起關注質量的項目節奏
11.1.2 實現源碼控制和提交流程
11.1.3 每日發布和測試代碼
11.1.4 自動化每日構建
11.1.5 使用MSBuild
11.1.6 創建並執行質量指標
11.2 總結
11.3 本章要點

第12章 態度決定一切
12.1 激情
12.2 線性還是疊代
12.3 銷售為王
12.4 靈活性
12.5 解決實際問題
12.6 你要負責
12.7 把移植代碼當做新代碼來寫
12.8 重構
12.9 優先權
12.10 從實際出發
12.11 擁抱變化
12.12 拓展視野
附錄A 敏捷開發資源
附錄B Web性能資源

序言

軟體工程和傳統意義上的工程完全不同。作為一名軟體程式設計師,我非常自豪可以自稱是一名工程師。工程師能夠通過細緻的計畫思考並製造出一次就能工作的東西。所以,在我的職業里包含“工程師”這個詞實在是一件很酷的事情。
我們先來看看要是把普通的軟體工程方法套用到航空工程里會發生什麼事情。一駕飛機正停在登機口等待乘客登機,這時一名航空工程師(不管是一時興起還是被老闆強迫)打算要換掉尾翼部分。畢竟那只是一個尾翼而已,直接把它弄下來換一個上去就好了。絕對沒問題,絕對能行!要是航空工程採用和軟體工程一樣的流程的話,我估計乘客都會瞬間逃離飛機的。但是,這類改變在軟體項目的世界裡基本上每天都要發生。過去有種自相矛盾的老笑話說是“軍事情報”,我覺得“軟體工程”也屬於這類範疇(這種笑話就是把兩個矛盾或者互斥的詞放在一起,通常都是為了幽默搞笑——譯者注)。而更讓人頭疼的是,雖然軟體真的是在“統治”這個世界,但是幾乎所有人在創建它時所採用的方法無一可以稱得上是“工程”。
為什麼我敢說我現在正在使用的計算機可以正常工作,但是我正在使用的程式(MicrosoftWord)卻可能會搞亂我列表的自動編號呢?我這么說可能會得罪我那些電子工程的朋友,但是我還是要說,因為硬體比較簡單。電子工程師要對付的只是很有限的輸入,不像軟體工程師要面對幾乎無限可能的輸入。
管理學也認為電子工程是“真正的工程”,所以管理的時候可以給予適當的時間和資源。而軟體業,作為一個獨特的領域,還算不上成熟,它真正存在的時間不是很長。其實說起來,我比軟體這個行業年輕不了多少,所以我“不成熟”的看法才能透露出這些問題。要是我和電子工程一樣老的話,那么現在我就該躺在墳墓里寫書了。
軟體開發的另一個難題有時候是軟體工程師自己。老實說,成為一名軟體工程師的門檻還是很低的。我就是一個現成的例子:在獲得計算機科學學士學位之前,我就已經是一名全職的軟體工程師了。當初獲得這份寫程式的工作只不過是因為我在面試的時候“特別能吹”而已。我的老闆根本就不在乎我沒有受過正規的教育,畢竟我要求的工資比較低。
在所有真正的工程領域裡,你都必須先獲得認證資格後才能在名字里加上專業工程師(Pro.fessional Engineer,PE)的頭銜。在軟體行業里就沒這種規定。其中一部分原因是這個行業太年輕了,沒有人知道在從業之前應該必須掌握什麼知識才能成為一個軟體工程師。而在其他領域裡,專業工程師通常意味著大量管理上的責任。如果一名有資格的工程師覺得一個設計是行不通的,她就不會在計畫書上籤名,項目也就不可以進行下去。

相關詞條

熱門詞條

聯絡我們