打造可維護軟體|編寫可維護程式碼的10項法則 (Java版)

Book description

「這些指導方針正確無誤,以簡單明瞭、切實可行的方式,闡述高效開發者如何一貫地撰寫及交付高品質的程式碼。」
— George Marinos, 應用程式架構師, 希臘國家銀行

你可曾在修改他人程式碼時深感挫折與沮喪?今日,難以維護的程式碼已經成為軟體開發的大麻煩,導致代價不斐的時程延宕與程式缺陷。本書從實務出發,作為解決方案的一部分,提供10條切實可行的指導方針,幫助你成功交付容易維護及修改的絕妙軟體,事實上,這些原則可是淬煉自數百個實務系統的分析結果。

本書出自於Software Improvement Group(SIG)的眾顧問之手,不僅針對這個主題提供清晰且明確的解釋,更說明了如何將理論應用到實務的絕佳建議。雖然本書範例均以Java寫成,但這些原則也適用於使用其他語言的開發者。

‧撰寫簡短的程式碼單元:限制方法與建構式的長度
‧撰寫單純的程式碼單元:限制每個方法當中的分支點數量
‧相同的程式碼只撰寫一次,避開複製程式碼臭蟲的風險
‧透過將參數提取到物件中,保持單元介面簡短
‧分離關注點,避免建構龐大的類別
‧保持架構元件鬆散耦合
‧讓頂層元件的數量與尺寸維持平衡
‧讓程式碼基礎盡可能保持小巧
‧自動化測試你的程式碼基礎
‧撰寫乾淨的程式碼,避免蘊含更深層問題的「程式碼異味」

 

Table of contents

  1. 書名頁
  2. 英文版權頁
  3. 目錄 (1/2)
  4. 目錄 (2/2)
  5. 關於作者
  6. 前言 (1/2)
  7. 前言 (2/2)
  8. 第一章 簡介
  9. 1.1 什麼是可維護性?
  10. 軟體維護的四種形式
  11. 1.2 可維護性為何重要?
  12. 可維護性嚴重影響商業活動
  13. 可維護性是其他品質特徵的推動者
  14. 1.3 本書指導方針的三大原則
  15. 原則1:恪守簡單的指導方針對於提高可維護性最有幫助
  16. 原則2:可維護性不是開發之後才考慮,而是專案開始即考量,人人都有貢獻
  17. 原則3:違背某些指導方針會產生比較大的影響
  18. 1.4 關於可維護性的各種誤解
  19. 誤解:可維護性與編程語言有關
  20. 誤解:可維護性與產業有關
  21. 誤解:可維護性等同於沒有臭蟲
  22. 誤解:可維護性是一道是非題
  23. 1.5 評估可維護性
  24. 1.6 可維護性指導方針的概述
  25. 第二章 撰寫簡短的程式碼單元
  26. 2.1 動機
  27. 簡短程式碼單元容易測試
  28. 簡短程式碼單元容易分析
  29. 簡短程式碼單元容易重利用
  30. 2.2 如何使用本指導方針?
  31. 在撰寫新的程式碼單元時
  32. 在為程式碼單元添加新功能時
  33. 使用重構技巧應用這個指導方針
  34. 2.3 撰寫簡短單元的常見反對意見
  35. 反對意見:比較多個程式碼單元不利於效能
  36. 反對意見:程式碼分散四處難以閱讀
  37. 反對意見:這個指導方針助長不當的格式化
  38. 反對意見:這個程式碼單元無法再拆分
  39. 反對意見:拆分程式碼單元沒有明顯的好處
  40. 2.4 參考
  41. 第三章 撰寫簡單的程式碼單元
  42. 3.1 動機
  43. 簡單的程式碼單元容易修改
  44. 簡單的程式碼單元容易測試
  45. 3.2 如何應用這個指導方針?
  46. 處理一連串條件語句
  47. 處理嵌套語句
  48. 3.3 常見的反對意見
  49. 反對意見:高複雜度無可避免
  50. 反對意見:拆分方法不會降低複雜度
  51. 3.4 參考
  52. 第四章 不撰寫重複的程式碼
  53. 重複程式碼的類型
  54. 4.1 動機
  55. 重複程式碼比較難分析
  56. 重複程式碼比較難修改
  57. 4.2 如何運用本指導方針?
  58. 提取父類別的重構技巧
  59. 4.3 常見的反對意見
  60. 反對意見:應該允許從其他程式碼基礎複製程式碼
  61. 反對意見:細微的變異無可避免,因而導致程式碼重複
  62. 反對意見:這段程式碼永遠不會改變
  63. 反對意見:應該允許複製完整檔案作為備份
  64. 反對意見:單元測試會幫我發現問題
  65. 反對意見:字串實字的重複是不可避免且無害的
  66. 4.4 參考
  67. 第五章 讓程式碼單元的介面 保持簡單
  68. 5.1 動機
  69. 簡短介面更容易理解及重利用
  70. 具有簡短介面的方法比較容易修改
  71. 5.2 如何使用本指導方針?
  72. 5.3 常見的反對意見
  73. 反對意見:參數物件具有龐大的介面
  74. 反對意見:重構冗長介面並未改善我的情況
  75. 反對意見:框架或程式庫已經定義了具有冗長參數列的介面
  76. 5.4 參考
  77. 第六章 不同模組之間的關注點分離
  78. 6.1 動機
  79. 鬆散耦合的小模組讓開發人員能夠獨立處理程式碼基礎的某個部分
  80. 鬆散耦合的小模組讓我們更容易瀏覽程式碼基礎
  81. 鬆散耦合的小模組避免讓開發新手覺得手足無措
  82. 6.2 如何使用本章指導方針
  83. 根據不同關注點拆分類別
  84. 將特定實作隱藏在介面背後
  85. 使用第三方程式庫/框架替換自定義程式碼
  86. 6.3 常見的反對意見
  87. 反對意見:鬆散耦合與程式碼重利用相衝突
  88. 反對意見:Java介面不單只為鬆散耦合
  89. 反對意見:頻繁呼叫工具類別是不可避免的
  90. 反對意見:不是所有的鬆散耦合都會提升可維護性
  91. 第七章 以鬆散耦合的方式架構元件
  92. 7.1 動機
  93. 低度元件依賴容許獨立的維護
  94. 低度元件依賴可以分離維護職責
  95. 低度元件依賴讓測試變容易
  96. 7.2 如何使用本指導方針?
  97. 抽象工廠設計模式
  98. 7.3 常見的反對意見
  99. 反對意見:因為元件之間相互纏結,所以無法修正元件依賴
  100. 反對意見:沒時間修正元件依賴
  101. 反對意見:透傳調用是需求
  102. 7.4 參考
  103. 第八章 保持架構元件平衡
  104. 8.1 動機
  105. 良好元件平衡能夠讓查詢與分析程式碼變得更容易
  106. 良好的元件平衡能夠隔離維護工作帶來的影響
  107. 良好的元件平衡能夠劃分維護職責
  108. 8.2 如何使用這個指導方針?
  109. 決定將功能性組織成元件的合適概念層級
  110. 釐清系統的各個領域,並且一貫地應用這些領域
  111. 8.3 常見的反對意見
  112. 反對意見:元件不平衡也沒什麼關係
  113. 反對意見:元件彼此纏結不利於元件平衡
  114. 8.4 參考
  115. 第九章 保持小規模的程式碼基礎
  116. 9.1 動機
  117. 以建構大型程式碼基礎為目標的專案比較容易失敗
  118. 大型程式碼基礎較難維護
  119. 大型系統的缺陷密度較高
  120. 9.2 如何應用這個指導方針?
  121. 功能層面的措施
  122. 技術層面的措施
  123. 9.3 常見的反對意見
  124. 反對意見:生產力量測有礙程式碼基礎的規模縮減
  125. 反對意見:編程語言有礙程式碼基礎的規模縮減
  126. 反對意見:系統複雜性促使程式碼不得不複製
  127. 反對意見:因為平台架構的關係,我們無法拆分程式碼基礎
  128. 反對意見:拆分程式碼基礎導致程式碼重複
  129. 反對意見:由於緊密耦合,根本無法拆分程式碼基礎
  130. 第十章 自動化測試
  131. 10.1 動機
  132. 自動化測試讓測試可以反覆進行
  133. 自動化測試讓開發更有效率
  134. 自動化測試讓程式碼行為可預測
  135. 測試是被測試程式碼的說明文件
  136. 撰寫測試能讓你撰寫更好的程式碼
  137. 10.2 如何使用這個指導方針
  138. JUnit測試入門
  139. 撰寫良好單元測試的一般性原則
  140. 以量測覆蓋率來決定測試案例是否足夠
  141. 10.3 常見的反對意見
  142. 反對意見:我們仍然需要手動測試
  143. 反對意見:公司不讓我撰寫單元測試
  144. 反對意見:既然目前的程式碼覆蓋率相當低,為何還要投資單元測試?
  145. 10.4 參考
  146. 第十一章 撰寫乾淨的程式碼
  147. 11.1 不留痕跡
  148. 11.2 如何使用這個指導方針?
  149. 規則1:不要留下單元層級的程式碼壞味道
  150. 規則2:不要撰寫不好的注解
  151. 規則3:不要在注解中撰寫程式碼
  152. 規則4:別留下無用程式碼
  153. 規則5:不要使用冗長的識別符名稱
  154. 規則6:不要使用魔法常數
  155. 規則7:不要留下未正確處理的例外
  156. 11.3 常見的反對意見
  157. 反對意見:注解是我們的文件說明
  158. 反對意見:例外處理增加額外程式碼
  159. 反對意見:為何只有這些撰碼指導方針?
  160. 第十二章 後續工作
  161. 12.1 將指導方針化作實務
  162. 12.2 低層級(程式碼單元)指導方針優先於高層級(元件)指導方針
  163. 12.3 一步一腳印,每次提交都別輕忽
  164. 12.4 下一本書會探討開發流程的最佳實務
  165. 附錄A SIG如何評估可維護性?
  166. 索引 (1/2)
  167. 索引 (2/2)
  168. 出版記事

Product information

  • Title: 打造可維護軟體|編寫可維護程式碼的10項法則 (Java版)
  • Author(s): Joost Visser
  • Release date: June 2017
  • Publisher(s): GoTop Information, Inc.
  • ISBN: None