打造可維護軟體|編寫可維護程式碼的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

You might also like

book

建構Android應用程式--使用HTML、CSS和JavaScript 第二版

by Jonathan Stark, Brian Jepson

使用標準網站工具 『行動上網越來越重要:使用傳統桌上型電腦上網的人將轉移到手持式裝置。Jonathan的書提供最快的路徑,讓手機網站應用程式從無到販賣。這些書是phoneGap的入門最佳方法,但更重要的是,它展現了現代行動網站開發的強大,效用和簡單。』--Brian LeRoux Adobe Systems 別懷疑!假如你懂HTML、CSS和JavaScript,就已經擁有開發Android應用程式的能力了。現在馬上下載最新版本的PhoneGap,這本書將教你使用像HTML5之類的網站標準技術(open web standards),開發設計適用於任何Android系統裝置上的應用程式。 學會在你所選的手機平台上,開發適用於Android系統的網站程式,然後用PhoneGap(Adobe公司所開發的免費軟體)將你開發的網站程式轉換成純粹的Android應用程式。體會到為什麼能夠偵測裝置的手機程式是未來的潮流,並且開始建構更有彈性與能廣泛使用的應用程式。 本書主題: ‧將網站轉成網站程式,加上進度標示等功能 ‧使用JQTouch製作動畫,使你的網站應用程式用起來更像原本Android應用程式 ‧利用本地端資料儲存機制,讓Android裝置離線時也能運作程式 ‧利用PhoneGap結合進階的Android功能,包含加速度計(Accelerometer), 地理位置定位( geolocation)和警告訊息(alerts) …

book

成為卓越程式設計師的38項必修法則

by Pete Goodliffe

“本書會引發你對程式設計藝術與科學的熱情。Pete 知道:卓越的軟體,是優秀的人們盡最大努力所完成的。” -Lisa Crispin 《Agile Testing: A Practical Guide for Testers and Agile Teams》作者 如果你熱愛程式設計,想要提升自己的能力,那你就找到正確的資源了。《Code Craft …

book

深入淺出平面幾何

by Lindsey Fallow, Dawn Griffiths

『《深入淺出平面幾何》讓你察覺到,幾何不只是課堂中的學問,而是圍繞在你每天生活周遭的一部份。』 —Herbert Tracey,羅耀拉大學數學系講師 『這種訊息呈現與組織的方式,讓學習更加簡單而有效。本書可協助你建立穩固的基礎,更進一步學習進階的知識。要是我當年在學習幾何時,就有這本書那該有多好!』 —Amanda Borcky,大學生 『傳統教科書經常動不動就把學生拉進一個充滿學術術語的叢林中,但《深入淺出平面幾何》卻反其道而行。本書藉由清晰易讀的方式,透過一些有趣的例子和好玩的設計,以對話的形態來傳達知識,這是一般教科書都應該好好學習的地方。』 —Dan Meyer,高中數學老師 你將從本書學到什麼? 你覺得幾何很難搞定嗎?一看到π、畢式定理或是角度計算,你的頭就發暈嗎?放輕鬆點,不用那麼緊張啦。現在有了《深入淺出平面幾何》,不管你遇到三角形、四邊形,甚至是多邊形,都不用再害怕了。你會從全等和相似的觀念中,學習到很多節省時間的秘密,而且不只是快而已,過程不但一點都不痛苦,而且還很好玩呢! 這本書為何如此與眾不同? 我們認為你的時間寶貴,不應該浪費在與新概念周旋不下的窘境之中。運用認知科學與學習理論的最新研究成果,我們精心建構出一段引發多重感知的學習體驗。《深入淺出平面幾何》針對大腦運作而設計,採用了豐富的視覺化風格,至於那些令你昏昏欲睡的冗贅敘述?那就免了吧。

video

Spotlight on Data: Refactoring a Million-Line Codebase with Maude Lemaire

by Maude Lemaire

In late 2017, Slack's largest customers were plagued with relentless performance-related outages, due in part to …