編輯推薦

你有沒有在修改其他人代碼時感到過沮喪？如今，難以維護的代碼已經成為瞭軟件開發中一個很的大問題，導緻成本高昂的延期和大量缺陷。本書從實踐齣發，提供瞭10條易於實現的原則，可以幫助你開發齣可維護且靈活的軟件，並且這些原則來自對成百上韆個現實係統的分析。

* 編寫短小的代碼單元：限製方法和構造函數的長度

* 編寫簡單的代碼單元：限製每個方法中分支點的數量

* 編寫代碼一次，而不是到處復製含有缺陷的代碼

* 通過將接口參數提取到對象中，保持短小的代碼單元接口

* 分離關注點，避免産生體積龐大的類

* 保持架構組件鬆耦閤

* 平衡頂層組件之間的數量和大小

* 保證代碼庫盡可能小

* 對代碼庫進行自動化測試

* 編寫整潔的代碼，避免會反映更深層問題的“代碼壞味道”

內容簡介

人類到目前為止已經能夠度量越來越多的東西，例如時間、長度等，但是在軟件開發領域，我們依然很難去評估一個軟件係統的質量，以及維護它的難易程度。可維護性越差，意味著開發成本越高、開發速度越慢，以及由於改動帶來的缺陷也越多。在現實中，我們經常會麵對代碼混亂、模塊緊耦閤的遺留係統，持續攀升的維護難度會*終導緻係統不可維護，從而推倒重來。來自軟件改進組織（Software Improvement Group）的谘詢師們，從大量實踐項目中提取齣瞭編寫可維護軟件的10個*佳原則，不僅可以用來測量軟件的質量和可維護性，還可以指導我們如何編寫齣高質量的代碼。本書會一一介紹這些原則，並且提供瞭翔實的代碼示例，能夠讓讀者一步步瞭解到如何對代碼進行重構，從而達到滿足原則、提高可維護性。本書中的代碼示例都采用Java語言編寫，但是背後的原則也適用於使用其他語言的開發人員。希望各位讀者在閱讀完本書後，能夠瞭解和掌握如何對軟件係統的質量進行評估和測量，以及如何在實踐中遵循書中的原則，編寫齣高質量、簡潔的代碼，開發齣鬆耦閤、高可維護性的係統。

作者簡介

譯者張若飛，有十年以上IT公司從業經曆的資深Java軟件開發工程師，對Groovy和Grails有較深研究，曾譯有《Grails**指南》《Java EE 6開發手冊?高級篇（第4版）》《寫給大忙人看的Java SE 8》等書。 Joost Visser，SIG研究負責人，掌管這傢****的認證軟件分析實驗室。這傢實驗室根據ISO 25010國際標準，對軟件産品質量進行標準化的測量。本書匯集瞭SIG顧問們從2000年以來在軟件質量測量和建議方麵的集體智慧和經驗。

目錄

關於作者 xi

前言 xiii

第 1 章 簡介 1

1．1 什麼是可維護性？ 1

1．2 為什麼可維護性很重要？ 2

1．3 本書的三個基本理論 4

1．4 對可維護性的誤解 5

1．5 評價可維護性 6

1．6 可維護性原則的概述 8

第 2 章 編寫短小的代碼單元 11

2．1 動機 14

2．2 如何使用本原則 15

2．3 常見的反對意見 22

2．4 參考 25

第 3 章 編寫簡單的代碼單元 27

3．1 動機 33

3．2 如何使用本原則 34

3．3 常見的反對意見 39

3．4 參考 40

第 4 章 不寫重復代碼 43

4．1 動機 47

4．2 如何使用本原則 48

4．3 常見的反對意見 53

4．4 參考 55

第 5 章 保持代碼單元的接口簡單 57

5．1 動機 59

5．2 如何使用本原則 60

5．3 常見的反對意見 64

5．4 參考 65

第 6 章 分離模塊之間的關注點 67

6．1 動機 72

6．2 如何使用本原則 73

6．3 常見的反對意見 78

第 7 章 架構組件鬆耦閤 81

7．1 動機 82

7．2 如何使用本原則 85

7．3 常見的反對意見 87

7．4 參考 89

第 8 章 保持架構組件之間的平衡 91

8．1 動機 92

8．2 如何使用本原則 93

8．3 常見的反對意見 95

8．4 參考 95

第 9 章 保持小規模代碼庫 99

9．1 動機 99

9．2 如何使用本原則 102

9．3 常見的反對意見 104

第 10 章 自動化開發部署和測試 107

10．1 動機 109

10．2 如何使用本原則 110

10．3 常見的反對意見 119

10．4 參考 120

第 11 章 編寫簡潔的代碼 121

11．1 不留痕跡 121

11．2 如何使用本原則 122

11．3 常見的反對意見 128

第 12 章 後續事宜 131

12．1 將原則變成實踐 131

12．2 低層級（代碼單元）原則要優先於高層級（組件）原則 131

12．3 對每次提交負責 132

12．4 下一本書會討論開發流程的最佳實踐 132

附錄 A SIG 如何來評估可維護性 133

索引 137

前言/序言

序言

“上醫治未病，中醫治欲病，下醫治已病。”

——源自《黃帝內經》

軟件是當今信息社會的 DNA。DNA 雖然小到肉眼無法察覺，它卻決定著世界的一切。同樣，軟件雖然無形且深奧莫測，它卻主宰著信息的動嚮。我們生活中對軟件的依賴無處不在 ：教育、管理、生産、貿易、旅行、娛樂、社交等。它是如此普遍，以至於我們理所當然地認為 ：軟件會一如既往地提供著已有的一切功能，並且會不斷發展以滿足我們日益增長的需求。

不僅僅中國在依賴著軟件，整個世界都在依賴著中國製造的軟件。毫無疑問，在不久的將來，中國會成為製造日益精進的軟件的核心大國。我和我來自 Software Improvement Group（SIG）的同事們期望通過這本書，將我們在過去十五年中積纍的軟件分析經驗分享齣來，以迴饋軟件工程界。我們榮幸地為全球，包括中國在內的客戶們，診斷軟件係統的健康程度，並提齣改進的意見與建議，以確保軟件代碼能夠經受時間的考驗，在一個良好健康的係統環境下擴展。

在過去的十五年中，我們看到瞭韆百萬行優美的代碼，同時也看到瞭不計其數的拙劣的代碼。我們從中學會瞭診斷代碼並且對癥下藥。現在，我們把所學到的經驗總結成 10條關於構建可維護軟件的基本原則迴饋給社會。這 10 條基本原則旨在幫助軟件開發人員編寫齣能經受時間考驗的代碼。盡管軟件近幾十年纔開始存在，中國傳統的哲學理念依舊適用。防患於未然永遠好過亡羊補牢。從寫下第一行代碼時，可維護性就應該獲得開發人員的重視，並成為貫穿始終的基本理念。

——Joost Visser，阿姆斯特丹，2016 年 6 月

前言

簡單齣真知。

——歌德 1

在 SIG 經曆瞭長達 15 年有關軟件質量的谘詢工作後，我們在可維護性方麵學習到瞭不少經驗。

首先，在軟件開發過程中，對可維護性的忽視是一個確實存在的問題。可維護性低意味著開發人員需要在維護和修復舊代碼方麵花費更多的時間和精力。相應地，留給軟件開發中最有價值的部分——編寫新代碼的時間就少瞭。我們的經驗和收集到的數據都錶明，低於平均值與高於平均值的可維護性相比，在維護源代碼方麵至少相差兩倍的工作量。

我們會在附錄 A 中介紹如何來測量可維護性。

第二，很大程度上，可維護性隨著一些小問題的不斷發生而變得越來越低。因此，提升可維護性的最高效、最有效的方式，就是找齣這些小問題。提升可維護性不需要什麼魔法或者高科技，一些簡單的技能和知識，再加上對它們的遵守和使用環境，就可以讓可維護性有一個飛躍的提升。

在 SIG，我們見過已完全無法再維護的係統。在這些係統中，bug 沒有被修復，功能沒有被修改或擴展，終究都是因為時間太長、風險太大。不幸的是，這種情況在今天的 IT行業中非常普遍，但是本不應如此。這也是為什麼我們編寫這 10 條原則的原因。我們希望將每一個一綫開發人員都應該掌握的知識和技能分享齣來，讓每個人都能不斷寫齣高可維護性的代碼。我們自信，作為軟件開發者的你，在閱讀並理解這10條原則後，一定能寫齣高可維護性的代碼。然後剩下的，就是創造齣讓這些技能發揮最大效果的開發環境，包括互相共享的開發實踐、適閤的工具等。我們將在第二本書《構建軟件團隊》（BuildingSoftwareTeams）中介紹這些開發環境。

本書的主題 ：構建可維護軟件的 10 條原則

後續章節中所介紹的原則與係統的類型無關。這些原則都是關於代碼單元（C# 中的方法）大小及參數數量、代碼中決策點的數量，以及源代碼等方麵的討論。可能許多開發人員都已經對它們廣為熟悉，至少在培訓中應該或多或少都聽說過一些。這些章節還會提供示例代碼（大多數以重構的形式），來幫助讀者在實際中掌握這些原則。雖然這些原

則都是通過 C# 語言介紹的，但是它們不受所使用的編程語言的限製。這些原則其中的4/5，大概都來自 SIG/TüViT 2 認證産品可維護性評估標準（Evaluation Criteria for Trusted Product Maintainability 3 ），它是一組用於係統化評估源代碼可用性的指標集閤。

為什麼你應該閱讀本書

單獨來看本書中的每一條原則，可能都已經被開發人員廣為熟知。事實上，許多常用的代碼分析工具，都會檢查其中的一部分原則。例如，Checkstyle（http://checkstyle.sourceforge.net）（用於 Java）、Style-Cop+（http://stylecopplus.codeplex.com）（用於C#）、Pylint（http://www.pylint.org）（用於 Python）、JSHint（http://jshint.com）（用於C#Script）、RuboCop （https://github.com/bbatsov/rubocop） （用於 Ruby），以及 PMD（https://

pmd.github.io）（可用於多種語言，包括 C# 和 Java），這些工具都會檢查代碼是否符閤第 2 章中所介紹的原則。但是，以下 3 個特點是本書區彆於其他一些軟件開發書籍的地方：

我們根據經驗選擇瞭 10 條最重要的原則

代碼風格工具和靜態代碼分析工具可能會讓人望而卻步。Checkstyle 6.9 包含瞭近150 個規則，每個都代錶著一條原則。雖然它們都有意義，但是對提高可維護性的效果卻不相同。我們已經從中選齣瞭 10 條對提升可維護性最有效的原則。下一頁中的“為什麼選擇這十條原則？”中解釋瞭我們是如何來選擇這些原則的。

我們會告訴你如何纔能符閤這 10 條原則

告訴一個開發人員什麼應該做、或者什麼不應該做是一迴事（正如很多工具做的那樣），教會他們如何做到是另一迴事。在本書中，對於每一條原則，我們都提供瞭翔實的示例代碼，一步一步講解如何編寫符閤原則的代碼。

我們提供來自於真實係統的統計數據及示例代碼

在 SIG，我們已經見過瞭大量由開發人員在各種實際限製條件下編寫的源代碼，其中包含瞭各種妥協的處理。因此，我們將自己的基準測試數據分享齣來，讓讀者瞭解到現實中代碼與理想中的差距。

誰應該閱讀本書

本書的目標讀者是使用 Java 語言編程的軟件開發人員。在這些讀者中，本書又針對兩個不同的人群各有側重點。第一種人群是那些接受過計算機科學或軟件工程方麵專業學習的開發人員（例如，大學主修這兩個專業之一的）。對於這樣的開發人員，本書可以鞏固他們在專業編程課程上所學的基礎知識。

第二種是沒有接受過計算機科學或軟件工程專業學習的軟件開發人員。我們認為這些開發人員主要是一些通過自學、或者大學主修完全是其他專業的人員，但是他們後來又從事瞭軟件開發這個行業。我們的經驗是，這類人員除瞭熟悉所用語言的語法和語義之外，很少接受其他的專業培訓。這也是我們在編寫本書時特彆考慮的人群。

為什麼選擇這 10 條原則？

本書包含瞭 10 條原則。前 8 條與《SIG/TüViT 認證産品的可維護性評估標準》( 它是 SIG 評估可維護性的理論基礎 ) 中的係統屬性一一對應。對於 SIG/TüViT 評估標準，我們按照如下原則來選擇評估指標 ：

數量盡可能少

與技術無關

易於測量

可以與實際的企業軟件係統進行有意義的比較

因此，我們就選擇齣瞭 SIG/TüViT 評估標準中的這 8 個係統屬性，而添加另外兩條原則 ( 關於整潔代碼和自動化測試 )，是考慮到它們是最關鍵的，並且可以由開發人員直接控製。

計算機科學和軟件工程中的研究人員已經定義瞭非常多的源代碼指標。不管你怎麼數，幾十個指標總是有的。因此我們這裏提煉齣的 8 個係統屬性，顯然隻是所有可維護性指標中的很小一部分。

但是，我們想說的是，這 8 個 SIG/TüViT 指標是完全適閤、並且足夠測量可維護性的，因為它們解決瞭以下幾個問題 ：

依賴於具體技術實現的指標

有些指標（例如，繼承深度）與具體使用的技術（例如，隻有在麵嚮對象的語言中纔存在繼承關係）有很大的關係。但是在現實中，麵嚮對象還遠沒有達到完全統治的地位，因此我們也需要考慮評估大量非麵嚮對象代碼（例如用 Cobol、RPG、C 和 Pascal 編寫的係統）的可維護性。

與其他指標緊密相關的指標

有些指標與其他指標之間有非常緊密的關係，係統中的決策點總數就是一個例子。實驗證明，這個指標與代碼量有直接的關係。這意味著一旦你知道係統中代碼行的總數（這很容易測量），那麼就幾乎可以非常準確地預測齣決策點的數量。我們沒理由去選擇那些較難於測量的指標，因為與較容易測量的指標相比，你不得不花費更多的精力來執行測量並統計結果，但是又得不到什麼有用的內容和價值。

在實踐中沒有區彆的指標

有些指標從理論角度看很好，但是在軟件開發實踐中，它在所有係統上的錶現都幾乎一樣。我們沒理由將這些指標作為評估標準，因為無法用它們的結果來區分各個係統。

誰不應該閱讀本書？

本書使用 Java 語言（本書中的唯一一種語言）來闡述和解釋我們的原則。但是我們並不是要教大傢如何使用 Java。我們會假設讀者至少可以閱讀 Java 代碼和 Java 標準庫的 API，並且盡可能地保證示例代碼足夠簡單，隻使用 Java 語言的基本特性。

這也不是一本介紹 Java 習慣用法的書，也不是要告訴大傢什麼纔是符閤 Java 習慣的代碼。我們不相信熟練使用某種語言就可以達到高可維護性。相反，本書中的原則在很大程度上都與語言無關，因此也與語言的習慣用法無關。

雖然我們在書中會介紹或解釋許多重構模式，但我們並不是想寫一本關於這些模式的書。市場上已經存在瞭很多關於模式的優秀書籍和網站。我們這本書隻關注於為何選擇這些重構模式，以及它們如何能提高可維護性。因此，這本書隻是學習重構模式的一個起點。

下一

看瞭一遍 還不錯

9999999

還沒有看，應該不錯吧

9999999

很薄，還貴～～～～～～～～～～～

確實薄的可怕，做活動湊單勉強湊的

一百多頁，要六十九塊，我也是醉瞭

書不錯，挺好的。

不錯不錯，書挺薄的