編程匠藝

出版時間:2008年  出版社:電子工業(yè)出版社  作者:(美)古德利弗(Goodliffe, P.)著  頁數(shù):582  字數(shù):840000  譯者:韓江,陳玉譯  
Tag標簽:無  

前言

作為從事軟件開發(fā)的程序員,你肯定遇到過這樣的情況:自認為完美的代碼,在項目快要結束的時候,卻總是會發(fā)現(xiàn)還有好多內容需要修改。更有甚者,由于人員的變動,那些他們遺留下來的“老代碼”,作為時間留給程序員與項目組的最大遺產(chǎn),卻可能會成為項目組的災難。除了受制于人類自身的缺陷之外,還有由于組織而帶來的問題,如客戶需求不斷變更、必須在有限的時間和預算之內完成項目,來自內部所謂“項目管理”的種種壓力,等等。天哪,這些問題我們絕大部分人都趕上了。列寧曾在監(jiān)獄中寫下了《怎么辦?》,指導了俄國的十月革命。

內容概要

如果你可以編寫出合格的代碼,但是想更進一步、創(chuàng)作出組織良好而且易于理解的代碼,并希望成為一名真正的編程專家或提高現(xiàn)有的職業(yè)技能,那么《編程匠藝——編寫卓越的代碼》都會為你給出答案。本書的內容遍及編程的各個要素,如代碼風格、變量命名、錯誤處理和安全性等。此外,本書還對一些更廣泛的編程問題進行了探討,如有效的團隊合作、開發(fā)過程和文檔編寫,等等。本書各章的末尾均提供一些思考問題,這些問題回顧了各章中的一些關鍵概念,可以促使你像專家一樣思考,從而使本書成為那些渴望作為團隊的一分子,職業(yè)并高效地編程的新手們的一本絕佳的參考書。

作者簡介

Pete Goodliffe是一位軟件開發(fā)專家,他在軟件“食物鏈”上從未駐足不前。他在各種各樣的項目中使用過許多種語言。他還在教授和指導程序員方面有著豐富的經(jīng)驗,并且常年為ACCU的C Vu雜志(www.accu.org)撰寫欄目“編程的職業(yè)化”。Pete癡迷于編寫出色的、沒有錯誤的代碼

書籍目錄

第Ⅰ篇  代碼表面第一部分 第1章  善于防守——健壯代碼的防御性編程技巧      1.1  向優(yōu)秀的代碼前進      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  使用靜態(tài)分析工具       1.5.8  使用安全的數(shù)據(jù)結構       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  正義的戰(zhàn)爭      2.9  總結      2.10  另請參見      2.11  思考       2.11.1  深入思考       2.11.2  結合自己     第3章  名正言順——為有意義的事物起有意義的名稱      3.1  為什么我們應該恰當?shù)孛?     3.2  我們對什么進行命名      3.3  名字游戲       3.3.1  描述性       3.3.2  技術上正確       3.3.3  符合語言習慣       3.3.4  恰當      3.4  具體細節(jié)       3.4.1  命名變量       3.4.2  命名函數(shù)       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  分解為原子函數(shù)       4.2.4  選擇描述性的類型       4.2.5  命名常量       4.2.6  強調重要的代碼       4.2.7  分組相關信息       4.2.8  提供文件頭       4.2.9  恰當?shù)靥幚礤e誤       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  多少注釋是恰當?shù)?     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  錯誤狀態(tài)變量       6.2.4  異常       6.2.5  信號      6.3  檢測錯誤      6.4  處理錯誤       6.4.1  何時處理錯誤       6.4.2  可能的反應       6.4.3  代碼示例      6.5  使地獄浮現(xiàn)      6.6  管理錯誤      6.7  總結      6.8  另請參見      6.9  思考       6.9.1  深入思考       6.9.2  結合自己    第Ⅱ篇  代碼的神秘生命 第7章  欲善其事,先利其器——使用工具構建軟件      7.1  什么是軟件工具      7.2  為什么要在意工具      7.3  使工具發(fā)揮作用       7.3.1  了解它能做些什么       7.3.2  學習如何駕馭它       7.3.3  了解它適合什么任務       7.3.4  檢查它是否可用       7.3.5  找到了解更多信息的途徑       7.3.6  查明新版本何時出現(xiàn)      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  反思現(xiàn)實      8.2  誰、是什么、何時以及為什么       8.2.1  我們?yōu)槭裁匆獪y試       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  缺陷跟蹤系統(tǒng)       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  系統(tǒng)調用跟蹤       9.7.4  內核轉儲       9.7.5  日志      9.8  總結      9.9  另請參見      9.10  思考       9.10.1  深入思考       9.10.2  結合自己     第10章  代碼構建——將源代碼轉換為可執(zhí)行代碼的過程      10.1  語言障礙       10.1.1  解釋型語言       10.1.2  編譯型語言       10.1.3  字節(jié)編譯型語言      10.2  小題大做      10.3  構建軟件版本      10.4  怎樣才算是一個優(yōu)秀的構建系統(tǒng)       10.4.1  簡潔       10.4.2  一致       10.4.3  可重復和可靠       10.4.4  原子性       10.4.5  能夠應付錯誤      10.5  技術細節(jié)       10.5.1  目標的選擇       10.5.2  內務處理       10.5.3  依賴關系       10.5.4  自動構建       10.5.5  構建配置       10.5.6  遞歸地使用make      10.6  請發(fā)布我吧      10.7  構建大師是全能的嗎      10.8  總結      10.9  另請參見      10.10  思考       10.10.1  深入思考       10.10.2  結合自己     第11章  追求速度——優(yōu)化程序和編寫高效的代碼      11.1  優(yōu)化是什么      11.2  是什么使代碼不盡如人意      11.3  為什么不進行優(yōu)化呢   備選方案      11.4  為什么要進行優(yōu)化      11.5  優(yōu)化的具體細節(jié)       11.5.1  證明你需要進行優(yōu)化       11.5.2  找出運行得最慢的代碼       11.5.3  測試代碼       11.5.4  優(yōu)化代碼       11.5.5  優(yōu)化之后      11.6  優(yōu)化的技術       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  整數(shù)溢出      12.5  防范措施       12.5.1  系統(tǒng)安裝技術       12.5.2  軟件設計技術       12.5.3  代碼實現(xiàn)技術       12.5.4  規(guī)程技術      12.6  總結      12.7  另請參見      12.8  思考       12.8.1  深入思考       12.8.2  結合自己    第Ⅲ篇  代碼的形成過程 第13章  崇尚設計——如何創(chuàng)作出優(yōu)秀的軟件設計      13.1  邊設計邊編程      13.2  我們要設計什么      13.3  為什么這么忙亂      13.4  良好的軟件設計       13.4.1  簡潔       13.4.2  優(yōu)雅       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  維護現(xiàn)有代碼      15.6  總結      15.7  另請參見      15.8  思考       15.8.1  深入思考       15.8.2  結合自己    第Ⅳ篇 “一群”程序員第一部分 第16章  代碼猴子——培養(yǎng)正確的編程態(tài)度和方法      16.1  各種各樣的猴子       16.1.1  賣力工作的程序員       16.1.2  代碼猴子       16.1.3  權威       16.1.4  半權威       16.1.5  傲慢的天才       16.1.6  牛仔       16.1.7  規(guī)劃者       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  衛(wèi)星站       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  團隊的創(chuàng)建       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  在代碼樹上創(chuàng)建分支       18.2.5  源代碼控制簡史      18.3  配置管理      18.4  備份      18.5  發(fā)布源代碼      18.6  應該將源代碼放在哪里      18.7  總結      18.8  另請參見      18.9  思考       18.9.1  深入思考       18.9.2  結合自己    第Ⅴ篇  開發(fā)過程的組成部分第一部分 第19章  注意細節(jié)——編寫軟件規(guī)范      19.1  規(guī)范到底是什么      19.2  規(guī)范的類型       19.2.1  需求規(guī)范       19.2.2  功能規(guī)范       19.2.3  系統(tǒng)體系結構規(guī)范       19.2.4  用戶界面規(guī)范       19.2.5  設計規(guī)范       19.2.6  測試規(guī)范      19.3  規(guī)范應當包含哪些內容      19.4  規(guī)范編寫過程      19.5  我們?yōu)槭裁磿痪帉懸?guī)范      19.6  總結      19.7  另請參見      19.8  思考       19.8.1  深入思考       19.8.2  結合自己     第20章  代碼審查——執(zhí)行代碼審查      20.1  什么是代碼審查      20.2  何時進行審查       20.2.1  是否要進行審查       20.2.2  審查哪些代碼      20.3  執(zhí)行代碼審查       20.3.1  代碼審查會議       20.3.2  集成審查      20.4  審查你的態(tài)度       20.4.1  作者的態(tài)度       20.4.2  審查人員的態(tài)度      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章  程序秘方——代碼開發(fā)的方法和過程      22.1  編程風格       22.1.1  結構化編程       22.1.2  面向對象的程序設計       22.1.3  函數(shù)式編程       22.1.4  邏輯編程      22.2  烹飪方法:做什么與怎樣做      22.3  開發(fā)過程       22.3.1  混亂       22.3.2  瀑布模型       22.2.3  SSADM和PRINCE       22.3.4  V模型       22.3.5  原型設計       22.3.6  迭代和增量開發(fā)       22.3.7  螺旋模型       22.3.8  敏捷的方法       22.3.9  其他開發(fā)過程      22.4  已經(jīng)夠了!      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  系統(tǒng)編程      23.4  嵌入式編程      23.5  分布式編程      23.6  網(wǎng)絡應用程序編程      23.7  企業(yè)編程      23.8  數(shù)字編程      23.9  那又怎樣      23.10  總結      23.11  另請參見      23.12  思考       23.12.1  深入思考       23.12.2  結合自己     第24章  下一步呢——結果好就一切都好      但下一步該做什么呢?    答案和討論    參考書目    索引

章節(jié)摘錄

1.5.11  在聲明位置初始化所有變量這是一個顯而易見的問題。如果你初始化了每個變量,它們的用途就會是明確的。依靠像“如果我不初始化它,我就不關心初始值”的經(jīng)驗主義是不安全的。代碼將會發(fā)展。未初始化的值以后可能隨時都會變成問題。C和C++使這個問題更加復雜化。如果你意外地使用了一個沒有初始化的變量,那么你的程序在每次運行的時候都將得到不同的結果,這取決于當時內存中的垃圾信息是什么。在一個地方聲明一個變量,隨后再對它進行賦值,在這之后再使用它,這樣會為錯誤打開一個窗口。如果賦值的語句被跳過,你就會花費大量的時間來尋找程序隨機出現(xiàn)各種行為的原因。在聲明每個變量的時候就對它進行初始化,就可以把這個窗口關上,因為即使初始化時賦的值是錯誤的,至少出現(xiàn)的錯誤行為也是可以預知的。比較安全的語言(如Java和c}})通過為所有變量定義初始值,回避了這個易犯的錯誤。在聲明變量的時候對它進行初始化仍然是一種好的做法,這樣可以提高代碼的明確性。1.5.12 盡可能推遲一些聲明變量盡可能推遲一些聲明變量,可以使變量的聲明位置與使用它的位置盡量接近,從而防止它干擾代碼的其他部分。這樣做也使得使用變量的代碼更加清晰。你不再需要到處尋找變量的類型和初始化,在附近聲明使這些都變得非常明顯。不要在多個地方重用同一個臨時變量,即使每次使用都是在邏輯上相互分離的區(qū)域中進行的。變量重用會使以后對代碼重新完善的工作變得異常復雜。每次都創(chuàng)建一個新的變量——編譯器會解決任何有關效率的問題。1.5.13 使用標準語言工具在這方面,C和C++都是一場噩夢。它們的規(guī)范有許多不同的版本,使得許多情況成為了其他實現(xiàn)的未定義行為?,F(xiàn)如今有很多種編譯器,每個編譯器都有一些與其他編譯器稍有不同的行為。這些編譯器大部分是相互兼容的,但是仍然存在大量的繩索會套住你的脖子。明確地定義你正在使用的是哪個語言版本。除非你的項目要求你(最好是有一個好的理由),否則不要將命運交給編譯器,或者對該語言的任何非標準的擴展。如果該語言的某個領域還沒有定義,就不要依賴你所使用的特定編譯器的行為(例如,不要依賴你的C編譯器將char作為有符號的值對待,因為其他的編譯器并不是這樣的)。這樣做會產(chǎn)生非常脆弱的代碼。當你更新了編譯器之后,會發(fā)生什么?一位新的程序員加入到開發(fā)團隊中,如果他不理解那些擴展,會發(fā)生什么?依賴于特定編譯器的個別行為,將導致以后難以發(fā)現(xiàn)的錯誤。

媒體關注與評論

“有些書你不得不讀,有些書你必須去讀。Pete的書就屬于后者--它不僅非常有用,而且十分有趣,能夠讓你成為一名更加優(yōu)秀的程序員?!?Jez HiggiBS,AOCU主席Pete Goodlifie在業(yè)界的年頭快要超過好多人的年齡了,此君曾經(jīng)涉獵多個領域、不同的編程語言以及多種架構,并且曾經(jīng)在采用不同流程的公司里從事過開發(fā)工作。在本書中,他把多年壓箱底的一些觀念想法和技巧告訴了大家,這些都是時間與智慧的結合,相信無論是開發(fā)人員、項目經(jīng)理甚至測試人員,都可以從中發(fā)現(xiàn)阿里巴巴開啟金庫的鑰匙。--譯者

圖書封面

圖書標簽Tags

評論、評分、閱讀與下載


    編程匠藝 PDF格式下載


用戶評論 (總計24條)

 
 

  •   這本書能對把編程當作一生的事業(yè)的人非常有幫助。他把作者若干年的經(jīng)驗都寫進去了,對于處于人生迷茫的程序員來說就像明燈一樣,對于以后在軟件工廠里工作的指導作用非比尋常!
  •   和編程技巧沒太大關系。不過深入潛出的述說了編程相關的各種內容,值得一看的書
  •   整本書從內容到版面都很好,尤其內容。全書講了做為一名程序員的基本素養(yǎng),很多是我們平時忽略甚至誤解的地方。至少我認為這里一本可以改變一個程序員一生的書。如果有一天我有機會面試前來應聘的程序員的話我可能會問他這個問題:“你認為一名優(yōu)秀的程序員是什么樣的?”。
  •   軟件開發(fā)中的很多東西講的都比較清楚,感覺很不錯
  •   程序員必讀的書,開拓你的視野!
  •   我比較喜歡,看起來不像技術書,那么累
  •   剛開始在讀,感覺很不錯
  •   個人認為程序不只要算法優(yōu)秀,軟件結構要合理科學.代碼要漂亮容易維護.......都是要考慮的.書中不只給出了編寫的意見和經(jīng)驗,好有讓你如何適應團隊等內容.(適合程序編寫中級參考提供)
  •   編程本來就是一件有意思的事情,這本書的作者有著孩子一般的心,寫出來的東西讓人讀起來很輕松。作者以一種簡單的方式表達了他工作中的經(jīng)驗,我感覺這比看那些枯燥的說教書有意思多了??梢钥纯?,適合茶余飯后休閑翻閱。
  •   閱讀完前5章感覺還可以對我的一些編程習慣有了一定的改善是我喜歡的類型呵呵
  •   不過最好是帶著問題看比較好,不然覺得有點泛了。。嘿嘿,感覺整體適合在作完整項目的朋友看:)一般朋友看I部分還行:)
  •   phpchina推薦讀物,個人也比較認同
  •   信息量極大,章節(jié)分得很細,優(yōu)點是例子舉得很貼切,缺點是翻譯還是不到位,國內的技術翻譯還是偏理工科多,文科太弱。。
  •   應該是一本好書,各人感受
  •   還沒拜讀,但應該是本不錯的書.不是技術性的,是思想性的.合我胃口
  •   感覺一般般的
  •   適合沒事的時候看當休閑書看吧呵呵
  •   不知道是原著這么爛 還是翻譯的問題 通篇沒有細節(jié) 大道理一篇
  •   還可以的書,值的一買
  •   和通常的技術類書籍不一樣,這本書看起來一點也不枯燥,作者以生動的語言談論了編程的整個過程中需要注意的問題和方法,特別是每一章引用的一些名言,非常切合章節(jié)內容,居然還有孔子的話,發(fā)覺老外寫的書很多都喜歡這樣,給人感覺作者的文化修養(yǎng)不一般。強烈推薦這本書
  •   RT,很有啟發(fā)!
  •   感覺是一本程序員必讀的一本書!
  •   逛卓越的時候無意中發(fā)現(xiàn)這本書,看了一下目錄和簡介以及之前兩位用戶的評論,立即購買了此書。粗略瀏覽該書之后,理解喜歡上了該書---這真是一本不可多得的好書。... 閱讀更多
  •   看這本書第一印象好厚哦!里面講了很多關于怎么樣寫好代碼的東西,有些還是蠻實用的,但是還是那句話,理論要結合實際,書上講了很多的東西要經(jīng)常的對已有的代碼進行簡單的走查,看看以前自己的代碼是什么樣的,一段時間以后,再看看現(xiàn)在的代碼是什么樣的,那么你會從中得到很多的東西.
 

250萬本中文圖書簡介、評論、評分,PDF格式免費下載。 第一圖書網(wǎng) 手機版

京ICP備13047387號-7