中文名: 編寫高質量代碼：改善Java程序的151個建議
作者: 秦小波
圖書分類: 軟件
資源格式: PDF
版本: 掃描版
出版社: 機械工業出版社
書號: 9787111362593
發行時間: 2012年1月1日
地區: 大陸
語言: 簡體中文
簡介:



內容簡介：
　　在通往“java技術殿堂”的路上，本書將為你指點迷津！內容全部由java編碼的最佳實踐組成，從語法、程序設計和架構、工具和框架、編碼風格和編程思想等五大方面，對java程序員遇到的各種棘手的疑難問題給出了經驗性的解決方案，為java程序員如何編寫高質量的java代碼提出了151條極為寶貴的建議。對於每一個問題，不僅以建議的方式從正反兩面給出了被實踐證明為十分優秀的解決方案和非常糟糕的解決方案，而且還分析了問題產生的根源，猶如醍醐灌頂，讓人豁然開朗。
　　本書一共12章，第1～3章針對java語法本身提出了51條建議，例如覆寫變長方法時應該注意哪些事項、final修飾的常量不要在運行期修改、匿名類的構造函數特殊在什麼地方等；第4～9章重點針對jdk api的使用提出了80條建議，例如字符串的拼接方法該如何選擇、枚舉使用時有哪些注意事項、出現nullpointerexception該如何處理、泛型的多重界限該如何使用、多線程編程如何預防死鎖，等等；第10～12章針對程序性能、開源的工具和框架、編碼風格和編程思想等方面提出了20條建議。
　　本書針對每個問題所設計的應用場景都非常典型，給出的建議也都與實踐緊密結合。書中的每一條建議都可能在你的下一行代碼、下一個應用或下一個項目中嶄露頭角，建議你將此書擱置在手邊，隨時查閱，一定能使你的學習和開發工作事半功倍。
作者簡介：
秦小波，資深軟件開發工程師、項目經理、系統分析師和架構師（獲Sun架構師認證），從事IT行業10余年，經驗極其豐富，現就任於交通銀行軟件研發中心。精通設計模式，對設計模式有深刻認識和獨到見解，創造性地提出了自己在大量實踐中總結出來的新的設計模式。擅長於SSH、iBatis、jBPM等Java技術，對ESB、BPEL整合技術也有一定的研究。此外，具有IBM DB2 DBA資格認證，對海量數據處理有深入的研究。
內容截圖：

編輯推薦：
　　從語法、程序設計和架構、工具和框架、編碼風格、編程思想5個方面深入探討編寫高質量Java代碼的技巧、禁忌和最佳實踐。

目錄:


前言
第1章 java開發中通用的方法和准則
建議1： 不要在常量和變量中出現易混淆的字母
建議2： 莫讓常量蛻變成變量
建議3： 三元操作符的類型務必一致
建議4： 避免帶有變長參數的方法重載
建議5： 別讓null值和空值威脅到變長方法
建議6： 覆寫變長方法也循規蹈矩
建議7： 警惕自增的陷阱
建議8： 不要讓舊語法困擾你
建議9： 少用靜態導入
建議10： 不要在本類中覆蓋靜態導入的變量和方法
建議11： 養成良好習慣，顯式聲明uid
建議12： 避免用序列化類在構造函數中為不變量賦值
建議13： 避免為final變量復雜賦值
建議14： 使用序列化類的私有方法巧妙解決部分屬性持久化問題
建議15： break萬萬不可忘
建議16： 易變業務使用腳本語言編寫
建議17： 慎用動態編譯
建議18： 避免instanceof非預期結果
建議19： 斷言絕對不是雞肋
建議20： 不要只替換一個類
第2章 基本類型
建議21： 用偶判斷，不用奇判斷
建議22： 用整數類型處理貨幣
建議23： 不要讓類型默默轉換
建議24： 邊界，邊界，還是邊界
建議25： 不要讓四捨五入虧了一方
建議26： 提防包裝類型的null值
建議27： 謹慎包裝類型的大小比較
建議28： 優先使用整型池
建議29： 優先選擇基本類型
建議30： 不要隨便設置隨機種子
第3章 類、對象及方法
建議31： 在接口中不要存在實現代碼
建議32： 靜態變量一定要先聲明後賦值
建議33： 不要覆寫靜態方法
建議34： 構造函數盡量簡化
建議35： 避免在構造函數中初始化其他類
建議36： 使用構造代碼塊精煉程序
建議37： 構造代碼塊會想你所想
建議38： 使用靜態內部類提高封裝性
建議39： 使用匿名類的構造函數
建議40： 匿名類的構造函數很特殊
建議41： 讓多重繼承成為現實
建議42： 讓工具類不可實例化
建議43： 避免對象的淺拷貝
建議44： 推薦使用序列化實現對象的拷貝
建議45： 覆寫equals方法時不要識別不出自己
建議46： equals應該考慮null值情景
建議47： 在equals中使用getclass進行類型判斷
建議48： 覆寫equals方法必須覆寫hashcode方法
建議49： 推薦覆寫tostring方法
建議50： 使用package-info類為包服務
建議51： 不要主動進行垃圾回收
第4章 字符串
建議52： 推薦使用string直接量賦值
建議53： 注意方法中傳遞的參數要求
建議54： 正確使用string、stringbuffer、stringbuilder
建議55： 注意字符串的位置
建議56： 自由選擇字符串拼接方法
建議57： 推薦在復雜字符串操作中使用正則表達式
建議58： 強烈 建議使用utf編碼
建議59： 對字符串排序持一種寬容的心態
第5章 數組和集合
建議60： 性能考慮，數組是首選
建議61： 若有必要，使用變長數組
建議62： 警惕數組的淺拷貝
建議63： 在明確的場景下，為集合指定初始容量
建議64： 多種最值算法，適時選擇
建議65： 避開基本類型數組轉換列表陷阱
建議66： aslist方法產生的list對象不可更改
建議67： 不同的列表選擇不同的遍歷方法
建議68： 頻繁插入和刪除時使用linkedlist
建議69： 列表相等只需關心元素數據
建議70：子列表只是原列表的一個視圖
建議71： 推薦使用sublist處理局部列表
建議72： 生成子列表後不要再操作原列表
建議73： 使用comparator進行排序
建議74： 不推薦使用binarysearch對列表進行檢索
建議75： 集合中的元素必須做到compareto和equals同步
建議76： 集合運算時使用更優雅的方式
建議77： 使用shuffle打亂列表
建議78： 減少hashmap中元素的數量
建議79： 集合中的哈希碼不要重復
建議80： 多線程使用vector或hashtable
建議81： 非穩定排序推薦使用list
建議82： 由點及面，一葉知秋—集合大家族
第6章 枚舉和注解
建議83： 推薦使用枚舉定義常量
建議84： 使用構造函數協助描述枚舉項
建議85： 小心switch帶來的空值異常
建議86： 在switch的default代碼塊中增加assertionerror錯誤
建議87： 使用valueof前必須進行校驗
建議88： 用枚舉實現工廠方法模式更簡潔
建議89： 枚舉項的數量限制在64個以內
建議90： 小心注解繼承
建議91： 枚舉和注解結合使用威力更大
建議92： 注意@override不同版本的區別
第7章 泛型和反射
建議93： java的泛型是類型擦除的
建議94： 不能初始化泛型參數和數組
建議95： 強制聲明泛型的實際類型
建議96： 不同的場景使用不同的泛型通配符
建議97： 警惕泛型是不能協變和逆變的
建議98： 建議采用的順序是list[t]、list[?]、list[object]
建議99： 嚴格限定泛型類型采用多重界限
建議100： 數組的真實類型必須是泛型類型的子類型
建議101： 注意class類的特殊性
建議102： 適時選擇getdeclared×××和get×××
建議103： 反射訪問屬性或方法時將accessible設置為true
建議104： 使用forname動態加載類文件
建議105： 動態加載不適合數組
建議106： 動態代理可以使代理模式更加靈活
建議107： 使用反射增加裝飾模式的普適性
建議108： 反射讓模板方法模式更強大
建議109： 不需要太多關注反射效率
第8章 異常
建議110： 提倡異常封裝
建議111： 采用異常鏈傳遞異常
建議112： 受檢異常盡可能轉化為非受檢異常
建議113： 不要在finally塊中處理返回值
建議114： 不要在構造函數中拋出異常
建議115： 使用throwable獲得棧信息
建議116： 異常只為異常服務
建議117： 多使用異常，把性能問題放一邊
第9章 多線程和並發
建議118： 不推薦覆寫start方法
建議119： 啟動線程前stop方法是不可靠的
建議120： 不使用stop方法停止線程
建議121： 線程優先級只使用三個等級
建議122： 使用線程異常處理器提升系統可靠性
建議123： volatile不能保證數據同步
建議124： 異步運算考慮使用callable接口
建議125： 優先選擇線程池
建議126： 適時選擇不同的線程池來實現
建議127： lock與synchronized是不一樣的
建議128： 預防線程死鎖
建議129： 適當設置阻塞隊列長度
建議130： 使用countdownlatch協調子線程
建議131： cyclicbarrier讓多線程齊步走
第10章 性能和效率
建議132： 提升java性能的基本方法
建議133： 若非必要，不要克隆對象
建議134： 推薦使用“望聞問切”的方式診斷性能
建議135： 必須定義性能衡量標准
建議136： 槍打出頭鳥—解決首要系統性能問題
建議137： 調整jvm參數以提升性能
建議138： 性能是個大“咕咚”
第11章 開源世界
建議139： 大膽采用開源工具
建議140： 推薦使用guava擴展工具包
建議141： apache擴展包
建議142： 推薦使用joda日期時間擴展包
建議143： 可以選擇多種collections擴展
第12章 思想為源
建議144： 提倡良好的代碼風格
建議145： 不要完全依靠單元測試來發現問題
建議146： 讓注釋正確、清晰、簡潔
建議147： 讓接口的職責保持單一
建議148： 增強類的可替換性
建議149： 依賴抽象而不是實現
建議150： 拋棄7條不良的編碼習慣
建議151： 以技術員自律而不是工人