中文名: 編程匠藝:編寫卓越的代碼
原名: Code Craft: The Practice of Writing Excellent Code
作者: (美)Pete Goodliffe
譯者: 韓江 陳玉
資源格式: PDF
版本: 中文高清掃描版
出版社: 電子工業出版社
書號: 9787121069802
發行時間: 2008年9月
地區: 大陸
語言: 簡體中文
簡介:

內容簡介
如果你可以編寫出合格的代碼，但是想更進一步、創作出組織良好而且易於理解的代碼，並希望成為一名真正的編程專家或提高現有的職業技能，那麼《編程匠藝——編寫卓越的代碼》都會為你給出答案。本書的內容遍及編程的各個要素，如代碼風格、變量命名、錯誤處理和安全性等。此外，本書還對一些更廣泛的編程問題進行了探討，如有效的團隊合作、開發過程和文檔編寫，等等。本書各章的末尾均提供一些思考問題，這些問題回顧了各章中的一些關鍵概念，可以促使你像專家一樣思考，從而使本書成為那些渴望作為團隊的一分子，職業並高效地編程的新手們的一本絕佳的參考書。
作譯者
Pete Goodliffe
http://www.china-pub.com/main/sale/renwu/images/4344.gif
Pete Goodliffe是一位軟件開發專家，他在軟件“食物鏈”上從未駐足不前。他在各種各樣的項目中使用過許多種語言。他還在教授和指導程序員方面有著豐富的經驗，並且常年為ACCU的C Vu雜志（www.accu.org）撰寫欄目“編程的職業化”。 Pete癡迷於編寫出色的、沒有錯誤的代碼，這使得他有更多的時間與自己的孩子共度美好時光。.....
譯者序
作為從事軟件開發的程序員，你肯定遇到過這樣的情況：自認為完美的代碼，在項目快要結束的時候，卻總是會發現還有好多內容需要修改。更有甚者，由於人員的變動，那些他們遺留下來的“老代碼”，作為時間留給程序員與項目組的最大遺產，卻可能會成為項目組的災難。.
除了受制於人類自身的缺陷之外，還有由於組織而帶來的問題，如客戶需求不斷變更、必須在有限的時間和預算之內完成項目，來自內部所謂“項目管理”的種種壓力，等等。天哪，這些問題我們絕大部分人都趕上了。
列寧曾在監獄中寫下了《怎麼辦？》，指導了俄國的十月革命。而在軟件業，從一代宗師Frederick P. Brooks的《人月神話》開始，就在找“怎麼辦”這個“銀彈”了。然而，“狼來了”在多次被喊出來後，已經很少有人相信了。我們必須承認，這些都是根本層面的問題，目前還不能得到解決。但是，本書的作者Pete Goodliffe認為，至少我們可以采取一些方式，減少一些開發上的痛苦。因為，除了開發，人生還有許多更為美好的事物在等著我們。我們這次也可以高喊“銀彈來了”。沒有最好，只有更好，誰知道這次不是真的呢？
著名國畫大師齊白石在年輕的時候，曾經做過木匠。據說有一次他和師傅去給地主干活，在路上迎面走來另外一對木匠師徒。齊先生的師傅說，趕緊給別人讓路。師徒倆站在路邊，老師恭敬地目送那兩人漸漸走遠。齊白石不解，問師傅：同是木匠，你我師徒為什麼要給他們讓路。老師傅回頭說：為什麼？別人是做細活的，我們是做粗活的。
Pete Goodliffe在業界的年頭快要超過好多人的年齡了，此君曾經涉獵多個領域、不同的編程語言以及多種架構，並且曾經在采用不相同流程的公司裡從事開發。在本書中，他把多年壓箱底的一些觀念想法和技巧告訴了大家，這些都是時間與智慧的結合，相信無論是開發人員、項目經理甚至測試人員，都可以從中發現阿裡巴巴開啟金庫的鑰匙。
那麼本書有什麼特色呢？對於想了解內容的普通讀者來說，本書至少有以下特點：..
1．貼近實際 《編程匠藝——編寫卓越的代碼》是本書的書名，但也是作者的用心所在。人生有三個境界，最後一個就是“看山是山，看水是水”。這是廢話嗎？當然不是，作者對此給出了最好的解答。作為程序員，我們最喜歡爭論不同工具、平台、方法之間的優劣。而作者卻通過多年經驗，力圖告訴我們應該如何提高質量，並成為一名優秀的程序員。這些方法就像點石成金的手指，它們是方法論，而不是針對具體的工具或者平台的說教。我們現在所缺的，恰恰是這些能使自己更進一階的手段，而不是那些特殊的技術細節。
2．內容豐富翔實 很少有一本書能涵蓋如此多的領域，並且還如此扎實。作為一名程序員，我們可能永遠無法達到完美。而需要處於一種持續不斷地提高的狀態，總會有更多的東西需要學習。那麼下一步應該做什麼呢？這裡就有答案。
3．可作為“秘要心法” 本書不僅適合入門者，也適合需要提高的開發人員，以及那些想管理好所謂代碼猴子的項目經理們。與《項目經理案頭手冊》一樣，這本書也將成為每人的案頭手冊或者枕邊書，可以作為應急或者提升的手段。如果以後碰到了問題，可以隨時參閱相關的章節。
4．心態決定一切 這句話對嗎？有了良好心態，不一定行，如果沒有，肯定不行。我們常常羨慕於老外以四五十歲的年紀仍然能繼續從事編程，為什麼我們不行呢？可能不同的讀者都會找到屬於自己的答案！Pete Goodliffe具有寬闊的視野，扎實的基礎，廣泛的愛好，帶有一種程序員應該具有的高雅和恬淡。這正是我們這個浮躁的時代中積極探索的一代程序員所不具備的。
最後禁不住要抱怨一下，作者Pete Goodliffe以他豐富的閱歷和愛好，給譯者帶來了不小的麻煩，比如出於它對於音樂的愛好，所有章節的標題都來自英國的歌曲名稱。為了理解上的直觀，我們在翻譯的過程中采取的是“信達雅”中的“雅”，以保證國內讀者能很快切入主題。本書每章開始和行文的過程中，作者都引用了歷史上或者現在社會中一些名人的名言，這給翻譯增加了不少的難度，但是由於貼切精辟，這些名言也可稱之為點睛之筆。尤為值得高興的是，此君對我中華文化竟然也有一定的造詣，孔夫子和老子的哲理名言竟然多次出現，而且能夠貼切地表達出這些聖人的思想對軟件開發有哪些啟示，這非常不簡單，難為了作者，也著實難為了譯者。從外國作者的筆下，讓我們著實體會到了自己國家的文化源遠流長。這從一個側面也體現出東海西海，千聖一心。
此書給了我們一個快速成功進階的好范例。我覺得它更像一個程序員的入門或者修行心法。從此入門，我們可以少走很多彎路。同時，我們也要爭取像佛經中“般若波羅密”所講的那樣：大智慧到彼岸，最後連佛法也像渡河的筏子一樣，成佛後立即丟棄。我更希望的是，看過此書的讀者們，最後能夠拍案而起，大聲說：我可以了。...
譯 者
2007-12-2 於北京
截圖




目錄:
第Ⅰ篇 代碼表面第一部分
第1章 善於防守——健壯代碼的防御性編程技巧
1.1 向優秀的代碼前進
1.2 設想：最壞的選擇
1.3 什麼是防御性編程
1.4 又大又壞的世界
1.5 防御性編程技巧
1.5.1 使用好的編碼風格和合理的設計
1.5.2 不要倉促地編寫代碼
1.5.3 不要相信任何人
1.5.4 編碼的目標是清晰，而不是簡潔
1.5.5 不要讓任何人做他們不該做的修補工作
1.5.6 編譯時打開所有警告開關
1.5.7 使用靜態分析工具
1.5.8 使用安全的數據結構
1.5.9 檢查所有的返回值
1.5.10 審慎地處理內存(和其他寶貴的資源)
1.5.11 在聲明位置初始化所有變量
1.5.12 盡可能推遲一些聲明變量
1.5.13 使用標准語言工具
. 1.5.14 使用好的診斷信息日志工具
1.5.15 審慎地進行強制轉換
1.5.16 細則
1.6 約束
1.6.1 約束的內容
1.6.2 移除約束
1.7 總結
1.8 另請參見
1.9 思考
1.9.1 深入思考
1.9.2 結合自己
第2章 精心布局——源代碼的版面和樣式
2.1 什麼是關鍵
2.2 了解你的讀者
2.3 什麼是好的樣式
2.4 使用括號
2.4.1 K&R括號風格
2.4.2 懸掛式的括號風格
2.4.3 縮進的括號風格
2.4.4 其他的括號風格
2.5 主宰一切的風格
2.6 內部風格(以及在哪裡使用它們)
2.7 設立標准
2.8 正義的戰爭
2.9 總結
2.10 另請參見
2.11 思考
2.11.1 深入思考
2.11.2 結合自己
第3章 名正言順——為有意義的事物起有意義的名稱
3.1 為什麼我們應該恰當地命名呢
3.2 我們對什麼進行命名
3.3 名字游戲
3.3.1 描述性
3.3.2 技術上正確
3.3.3 符合語言習慣
3.3.4 恰當
3.4 具體細節
3.4.1 命名變量
3.4.2 命名函數
3.4.3 命名類型
3.4.4 命名名字空間
3.4.5 命名宏
3.4.6 命名文件
3.5 玫瑰不叫玫瑰
3.5.1 保持前後一致
3.5.2 利用上下文
3.5.3 使用對你有利的名稱
3.6 總結
3.7 另請參見
3.8 思考
3.8.1 深入思考
3.8.2 結合自己
第4章 不言自明——編寫“自文檔化”代碼的技巧
4.1 自文檔化的代碼
4.2 編寫自文檔化代碼的技術
4.2.1 使用好的樣式編寫簡單的代碼
4.2.2 選擇有意義的名稱
4.2.3 分解為原子函數
4.2.4 選擇描述性的類型
4.2.5 命名常量
4.2.6 強調重要的代碼
4.2.7 分組相關信息
4.2.8 提供文件頭
4.2.9 恰當地處理錯誤
4.2.10 編寫有意義的注釋
4.3 實用的自文檔化方法
4.3.1 文學性編程
4.3.2 文檔化工具
4.4 總結
4.5 另請參見
4.6 思考
4.6.1 深入思考
4.6.2 結合自己
第5章 隨篇注釋——如何編寫代碼注釋
5.1 什麼是代碼注釋
5.2 注釋看上去是什麼樣的
5.3 多少注釋是恰當的
5.4 注釋中應該有些什麼
5.4.1 解釋為什麼，而不是怎麼樣
5.4.2 不要描述代碼
5.4.3 不要取代代碼
5.4.4 確保注釋有用
5.4.5 避免分心
5.5 實踐
5.6 從審美的角度看注釋
5.6.1 一致性
5.6.2 清晰的塊注釋
5.6.3 縮進的注釋
5.6.4 行尾注釋
5.6.5 幫助你閱讀代碼
5.6.6 選擇一種維護成本較低的風格
5.6.7 分隔板
5.6.8 標志
5.6.9 文件頭注釋
5.7 使用注釋
5.7.1 幫助你編寫例行程序
5.7.2 錯誤修正通告
5.7.3 注釋過時
5.7.4 維護和空洞無物的注釋
5.8 總結
5.9 另請參見
5.10 思考
5.10.1 深入思考
5.10.2 結合自己
第6章 人非聖賢——處理不可避免的情況——代碼中的錯誤情形
6.1 從何而來
6.2 錯誤報告機制
6.2.1 不報告
6.2.2 返回值
6.2.3 錯誤狀態變量
6.2.4 異常
6.2.5 信號
6.3 檢測錯誤
6.4 處理錯誤
6.4.1 何時處理錯誤
6.4.2 可能的反應
6.4.3 代碼示例
6.5 使地獄浮現
6.6 管理錯誤
6.7 總結
6.8 另請參見
6.9 思考
6.9.1 深入思考
6.9.2 結合自己
第Ⅱ篇 代碼的神秘生命
第7章 欲善其事，先利其器——使用工具構建軟件
7.1 什麼是軟件工具
7.2 為什麼要在意工具
7.3 使工具發揮作用
7.3.1 了解它能做些什麼
7.3.2 學習如何駕馭它
7.3.3 了解它適合什麼任務
7.3.4 檢查它是否可用
7.3.5 找到了解更多信息的途徑
7.3.6 查明新版本何時出現
7.4 哪個工具
7.4.1 源代碼編輯工具
7.4.2 代碼構建工具
7.4.3 調試和調查工具
7.4.4 語言支持工具
7.4.5 其他工具
7.5 總結
7.6 另請參見
7.7 思考
7.7.1 深入思考
7.7.2 結合自己
第8章 測試時代——測試代碼的魔術
8.1 反思現實
8.2 誰、是什麼、何時以及為什麼
8.2.1 我們為什麼要測試
8.2.2 誰來進行測試
8.2.3 測試的內容有些什麼
8.2.4 何時進行測試
8.3 測試並不難……
8.4 測試的類型
8.5 選擇單元測試用例
8.6 為測試而設計
8.7 看！不要用手！
8.8 面對故障該怎麼辦
8.9 你能管理它嗎
8.9.1 缺陷跟蹤系統
8.9.2 bug審查
8.10 總結
8.11 另請參見
8.12 思考
8.12.1 深入思考
8.12.2 結合自己
第9章 尋找缺陷——調試：當事情進展得不順利時該怎麼辦
9.1 生活的真相
9.2 bug的種類
9.2.1 從遠處看
9.2.2 從近處看
9.2.3 從更近處看
9.3 消滅害蟲
9.3.1 地下之路
9.3.2 地上之路
9.4 搜尋bug
9.4.1 編譯時錯誤
9.4.2 運行時錯誤
9.5 如何修正缺陷
9.6 預防
9.7 除蜂劑、驅蟲劑、捕蠅紙
9.7.1 調試器
9.7.2 內存訪問校驗器
9.7.3 系統調用跟蹤
9.7.4 內核轉儲
9.7.5 日志
9.8 總結
9.9 另請參見
9.10 思考
9.10.1 深入思考
9.10.2 結合自己
第10章 代碼構建——將源代碼轉換為可執行代碼的過程
10.1 語言障礙
10.1.1 解釋型語言
10.1.2 編譯型語言
10.1.3 字節編譯型語言
10.2 小題大做
10.3 構建軟件版本
10.4 怎樣才算是一個優秀的構建系統
10.4.1 簡潔
10.4.2 一致
10.4.3 可重復和可靠
10.4.4 原子性
10.4.5 能夠應付錯誤
10.5 技術細節
10.5.1 目標的選擇
10.5.2 內務處理
10.5.3 依賴關系
10.5.4 自動構建
10.5.5 構建配置
10.5.6 遞歸地使用make
10.6 請發布我吧
10.7 構建大師是全能的嗎
10.8 總結
10.9 另請參見
10.10 思考
10.10.1 深入思考
10.10.2 結合自己
第11章 追求速度——優化程序和編寫高效的代碼
11.1 優化是什麼
11.2 是什麼使代碼不盡如人意
11.3 為什麼不進行優化呢
備選方案
11.4 為什麼要進行優化
11.5 優化的具體細節
11.5.1 證明你需要進行優化
11.5.2 找出運行得最慢的代碼
11.5.3 測試代碼
11.5.4 優化代碼
11.5.5 優化之後
11.6 優化的技術
11.6.1 設計更改
11.6.2 代碼更改
11.7 編寫高效的代碼
11.8 總結
11.9 另請參見
11.10 思考
11.10.1 深入思考
11.10.2 結合自己
第12章 不安全感綜合症——編寫安全的程序
12.1 危險
12.2 敵人
12.3 借口，都是借口
12.4 感到很脆弱
12.4.1 不安全的設計和體系結構
12.4.2 緩沖溢出
12.4.3 嵌入的查詢字符串
12.4.4 競爭狀況
12.4.5 整數溢出
12.5 防范措施
12.5.1 系統安裝技術
12.5.2 軟件設計技術
12.5.3 代碼實現技術
12.5.4 規程技術
12.6 總結
12.7 另請參見
12.8 思考
12.8.1 深入思考
12.8.2 結合自己
第Ⅲ篇 代碼的形成過程
第13章 崇尚設計——如何創作出優秀的軟件設計
13.1 邊設計邊編程
13.2 我們要設計什麼
13.3 為什麼這麼忙亂
13.4 良好的軟件設計
13.4.1 簡潔
13.4.2 優雅
13.4.3 模塊化
13.4.4 良好的接口
13.4.5 可擴展性
13.4.6 避免重復
13.4.7 可移植性
13.4.8 符合語言習慣
13.4.9 良好地文檔化
13.5 如何設計代碼
13.5.1 設計方法和過程
13.5.2 設計工具
13.6 總結
13.7 另請參見
13.8 思考
13.8.1 深入思考
13.8.2 結合自己
第14章 軟件體系結構——奠定軟件設計的基礎
14.1 什麼是軟件體系結構
14.1.1 軟件藍圖
14.1.2 視圖
14.1.3 在何時和何處進行體系結構設計
14.1.4 用體系結構來做什麼
14.1.5 關於組件和連接
14.2 什麼是良好的體系結構
14.3 體系結構風格
14.3.1 沒有體系結構
14.3.2 分層的體系結構
14.3.3 管道和過濾器體系結構
14.3.4 客戶端/服務器體系結構
14.3.5 基於組件的體系結構
14.3.6 框架
14.4 總結
14.5 另請參見
14.6 思考
14.6.1 深入思考
14.6.2 結合自己
第15章 改良與革命——代碼是如何成長的
15.1 軟件腐爛
15.2 警告信號
15.3 代碼是如何成長的
15.4 相信不可能之事
15.5 對此我們可以做些什麼
15.5.1 編寫新代碼
15.5.2 維護現有代碼
15.6 總結
15.7 另請參見
15.8 思考
15.8.1 深入思考
15.8.2 結合自己
第Ⅳ篇 “一群”程序員第一部分
第16章 代碼猴子——培養正確的編程態度和方法
16.1 各種各樣的猴子
16.1.1 賣力工作的程序員
16.1.2 代碼猴子
16.1.3 權威
16.1.4 半權威
16.1.5 傲慢的天才
16.1.6 牛仔
16.1.7 規劃者
16.1.8 老前輩
16.1.9 狂熱者
16.1.10 單線條程序員
16.1.11 拖沓者
16.1.12 勉強的團隊領導
16.1.13 你
16.2 理想的程序員
16.3 那麼該怎麼辦
16.4 最愚蠢的人
16.5 總結
16.6 另請參見
16.7 行為表格
16.8 思考
16.8.1 深入思考
16.8.2 結合自己
第17章 團結就是力量——團隊合作與個人程序員
17.1 我們的團隊——概覽
17.2 團隊組織
17.2.1 管理方法
17.2.2 責任劃分
17.2.3 組織和代碼結構
17.3 團隊合作工具
17.4 團隊疾病
17.4.1 巴別塔
17.4.2 獨裁制
17.4.3 民主制
17.4.4 衛星站
17.4.5 大峽谷
17.4.6 流沙
17.4.7 旅鼠
17.5 良好團隊合作的個人技巧和特點
17.5.1 溝通
17.5.2 謙虛
17.5.3 處理沖突
17.5.4 學習和適應能力
17.5.5 了解你的不足之處
17.6 團隊合作原則
17.6.1 集體代碼所有制
17.6.2 尊重別人的代碼
17.6.3 編碼准則
17.6.4 定義成功
17.6.5 定義責任
17.6.6 避免倦怠
17.7 團隊的生命周期
17.7.1 團隊的創建
17.7.2 團隊的成長
17.7.3 團隊合作
17.7.4 團隊結束
17.8 總結
17.9 另請參見
17.10 行為表格
17.11 思考
17.11.1 深入思考
17.11.2 結合自己
第18章 安全措施——源代碼控制與自我控制
18.1 我們的責任
18.2 源代碼控制
18.2.1 修訂控制
18.2.2 訪問控制
18.2.3 處理代碼庫
18.2.4 在代碼樹上創建分支
18.2.5 源代碼控制簡史
18.3 配置管理
18.4 備份
18.5 發布源代碼
18.6 應該將源代碼放在哪裡
18.7 總結
18.8 另請參見
18.9 思考
18.9.1 深入思考
18.9.2 結合自己
第Ⅴ篇 開發過程的組成部分第一部分
第19章 注意細節——編寫軟件規范
19.1 規范到底是什麼
19.2 規范的類型
19.2.1 需求規范
19.2.2 功能規范
19.2.3 系統體系結構規范
19.2.4 用戶界面規范
19.2.5 設計規范
19.2.6 測試規范
19.3 規范應當包含哪些內容
19.4 規范編寫過程
19.5 我們為什麼會不編寫規范
19.6 總結
19.7 另請參見
19.8 思考
19.8.1 深入思考
19.8.2 結合自己
第20章 代碼審查——執行代碼審查
20.1 什麼是代碼審查
20.2 何時進行審查
20.2.1 是否要進行審查
20.2.2 審查哪些代碼
20.3 執行代碼審查
20.3.1 代碼審查會議
20.3.2 集成審查
20.4 審查你的態度
20.4.1 作者的態度
20.4.2 審查人員的態度
20.5 完美的代碼
20.6 代碼審查之外
20.7 總結
20.8 另請參見
20.9 清單
20.10 思考
20.10.1 深入思考
20.10.2 結合自己
第21章 時間估計——軟件時間范圍估計的魔術
21.1 在黑暗中摸索
21.2 為什麼估計這麼困難？
21.3 壓力之下
21.4 實用的估計方法
21.5 計劃游戲
21.6 堅持！
21.7 總結
21.8 另請參見
21.9 思考
21.9.1 深入思考
21.9.2 結合自己
第Ⅵ篇 從高處鳥瞰
第22章 程序秘方——代碼開發的方法和過程
22.1 編程風格
22.1.1 結構化編程
22.1.2 面向對象的程序設計
22.1.3 函數式編程
22.1.4 邏輯編程
22.2 烹饪方法：做什麼與怎樣做
22.3 開發過程
22.3.1 混亂
22.3.2 瀑布模型
22.2.3 SSADM和PRINCE
22.3.4 V模型
22.3.5 原型設計
22.3.6 迭代和增量開發
22.3.7 螺旋模型
22.3.8 敏捷的方法
22.3.9 其他開發過程
22.4 已經夠了！
22.5 選擇一種過程
22.6 總結
22.7 另請參見
22.8 思考
22.8.1 深入思考
22.8.2 結合自己
第23章 編程領域大觀——不同的編程分支
23.1 應用程序編程
23.1.1 塑裝軟件
23.1.2 定制應用程序
23.2 游戲編程
23.3 系統編程
23.4 嵌入式編程
23.5 分布式編程
23.6 網絡應用程序編程
23.7 企業編程
23.8 數字編程
23.9 那又怎樣
23.10 總結
23.11 另請參見
23.12 思考
23.12.1 深入思考
23.12.2 結合自己
第24章 下一步呢——結果好就一切都好
但下一步該做什麼呢？
答案和討論
參考書目
索引