代碼不朽：編寫可維護軟件的10大要則（Java版） ( 簡體 字) |
| 作者：張若飛 | 類別：1. -> 程式設計 -> JAVA -> Java |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 45265
詢問書籍請說出此書號！【缺書】
NT售價： 345 元 |
| 出版日：9/1/2016 |
| 頁數：160 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787121297045 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：序言
“上醫治未病，中醫治欲病，下醫治已病。”
——源自《黃帝內經》
軟件是當今信息社會的 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/TuViT 2 認證產品可維護性評估標準（Evaluation Criteria for Trusted Product Maintainability 3 ），它是一組用于系統化評估源代碼可用性的指標集合。
為什么你應該閱讀本書
單獨來看本書中的每一條原則，可能都已經被開發人員廣為熟知。事實上，許多常用的代碼分析工具，都會檢查其中的一部分原則。這些工具都會檢查代碼是否符合第 2 章中所介紹的原則。但是，以下 3 個特點是本書區別于其他一些軟件開發書籍的地方：
我們根據經驗選擇了 10 條最重要的原則
代碼風格工具和靜態代碼分析工具可能會讓人望而卻步。Checkstyle 6.9 包含了近150 個規則，每個都代表著一條原則。雖然它們都有意義，但是對提高可維護性的效果卻不相同。我們已經從中選出了 10 條對提升可維護性最有效的原則。下一頁中的“為什么選擇這十條原則？”中解釋了我們是如何來選擇這些原則的。
我們會告訴你如何才能符合這 10 條原則
告訴一個開發人員什么應該做、或者什么不應該做是一回事（正如很多工具做的那樣），教會他們如何做到是另一回事。在本書中，對于每一條原則，我們都提供了翔實的示例代碼，一步一步講解如何編寫符合原則的代碼。
我們提供來自于真實系統的統計數據及示例代碼
在 SIG，我們已經見過了大量由開發人員在各種實際限制條件下編寫的源代碼，其中包含了各種妥協的處理。因此，我們將自己的基準測試數據分享出來，讓讀者了解到現實中代碼與理想中的差距。
誰應該閱讀本書
本書的目標讀者是使用 Java 語言編程的軟件開發人員。在這些讀者中，本書又針對兩個不同的人群各有側重點。第一種人群是那些接受過計算機科學或軟件工程方面專業學習的開發人員（例如，大學主修這兩個專業之一的）。對于這樣的開發人員，本書可以鞏固他們在專業編程課程上所學的基礎知識。
第二種是沒有接受過計算機科學或軟件工程專業學習的軟件開發人員。我們認為這些開發人員主要是一些通過自學、或者大學主修完全是其他專業的人員，但是他們后來又從事了軟件開發這個行業。我們的經驗是，這類人員除了熟悉所用語言的語法和語義之外，很少接受其他的專業培訓。這也是我們在編寫本書時特別考慮的人群。
為什么選擇這 10 條原則？
本書包含了 10 條原則。前 8 條與《SIG/TuViT 認證產品的可維護性評估標準》( 它是 SIG 評估可維護性的理論基礎 ) 中的系統屬性一一對應。對于 SIG/TuViT 評估標準，我們按照如下原則來選擇評估指標 ：
數量盡可能少
與技術無關
易于測量
可以與實際的企業軟件系統進行有意義的比較
因此，我們就選擇出了 SIG/TuViT 評估標準中的這 8 個系統屬性，而添加另外兩條原則 ( 關于整潔代碼和自動化測試 )，是考慮到它們是最關鍵的，并且可以由開發人員直接控制。
計算機科學和軟件工程中的研究人員已經定義了非常多的源代碼指標。不管你怎么數，幾十個指標總是有的。因此我們這里提煉出的 8 個系統屬性，顯然只是所有可維護性指標中的很小一部分。
但是，我們想說的是，這 8 個 SIG/TuViT 指標是完全適合、并且足夠測量可維護性的，因為它們解決了以下幾個問題 ：
依賴于具體技術實現的指標
有些指標（例如，繼承深度）與具體使用的技術（例如，只有在面向對象的語言中才存在繼承關系）有很大的關系。但是在現實中，面向對象還遠沒有達到完全統治的地位，因此我們也需要考慮評估大量非面向對象代碼（例如用 Cobol、RPG、C 和 Pascal 編寫的系統）的可維護性。
與其他指標緊密相關的指標
有些指標與其他指標之間有非常緊密的關系，系統中的決策點總數就是一個例子。實驗證明，這個指標與代碼量有直接的關系。這意味著一旦你知道系統中代碼行的總數（這很容易測量），那么就幾乎可以非常準確地預測出決策點的數量。我們沒理由去選擇那些較難于測量的指標，因為與較容易測量的指標相比，你不得不花費更多的精力來執行測量并統計結果，但是又得不到什么有用的內容和價值。
在實踐中沒有區別的指標
有些指標從理論角度看很好，但是在軟件開發實踐中，它在所有系統上的表現都幾乎一樣。我們沒理由將這些指標作為評估標準，因為無法用它們的結果來區分各個系統。
誰不應該閱讀本書？
本書使用 Java 語言（本書中的唯一一種語言）來闡述和解釋我們的原則。但是我們并不是要教大家如何使用 Java。我們會假設讀者至少可以閱讀 Java 代碼和 Java 標準庫的 API，并且盡可能地保證示例代碼足夠簡單，只使用 Java 語言的基本特性。
這也不是一本介紹 Java 習慣用法的書，也不是要告訴大家什么才是符合 Java 習慣的代碼。我們不相信熟練使用某種語言就可以達到高可維護性。相反，本書中的原則在很大程度上都與語言無關，因此也與語言的習慣用法無關。
雖然我們在書中會介紹或解釋許多重構模式，但我們并不是想寫一本關于這些模式的書。市場上已經存在了很多關于模式的優秀書籍和網站。我們這本書只關注于為何選擇這些重構模式，以及它們如何能提高可維護性。因此，這本書只是學習重構模式的一個起點。
下一本書
我們知道，單個開發人員并不能控制開發流程的方方面面。使用哪些開發工具、質量控制如何管理、如何搭建部署環境等，這些都是影響軟件質量的重要因素，但它們同時也是一個“團隊”的責任。因此，這些主題已經超出了本書的范圍，我們會在下一本書《構建軟件團隊》中介紹這方面的最佳實踐，以及如何測量它們的結果。
關于 SIG
雖然本書封面只列出了一個作者名字，但是本書的真正作者不止一人。真正的作者是SIG——一個軟件管理咨詢公司。因此說，這本書提煉了 SIG 所有顧問從 2000 年以來，在測量軟件質量和提出建議過程中總結的集體經驗和知識。我們運營著唯一一個經過認證的軟件分析實驗室，可以按照 ISO 25010 國際標準，對軟件產品的質量進行標準化的檢測。
SIG 提供的服務之一是我們的“軟件風險監控”服務。我們的客戶通過該服務，定期（通常每周）上傳他們的源代碼。然后我們的軟件實驗室會自動對上傳源代碼進行檢測。SIG 顧問會評估所有自動分析出的異常情況，并與客戶討論。在本書編寫時，SIG 已經總共分析了 71 億行代碼，每周有將近 7 千多萬行代碼被上傳到 SIG。
SIG 成立于 2000 年。它的歷史可以追溯到荷蘭國家數學與計算機科學研究院。即使在十五年后的現在，我們仍然保持并重視與軟件工程學術界的聯系。SIG 顧問會定期在學術期刊上發表文章，并且許多博士論文都是基于對開發和提高 SIG 質量模型的研究。
關于此版本
這是本書的 Java 版本。所有代碼示例都用 Java 編寫（并且只用 C# 編寫），文中經常提到的工具和名詞都是在 Java 社區中所廣泛使用的。我們假定讀者都擁有一定的Java 編程經驗。如前文所述，本書中用 Java 展示的各條原則，實際上是與語言無關的。本書的 Java 版本由O’Reilly 出版社負責出版發行。
相關書籍
我們列舉了 10 條實現高可維護性的基本原則。雖然這可能是許多人關于可維護性方面閱讀的第一本書籍，但是我們希望它不要成為最后一本。因此我們推薦讀者繼續閱讀以下圖書 ：
《構建軟件團隊》，SIG 著
這是同一批作者編寫的配套書籍。與本書關注于構建可維護軟件的開發原則不同，
這本書關注于軟件開發流程的最佳實踐以及如何使用“目標—問題—指標”的方法
來有效地測量它們。《構建軟件團隊》一書將于 2016 年出版。
《代碼質量》，Diomidis Spinellis 著
這本書也介紹了關于代碼質量的原則，但是同《代碼整潔之道》一樣，它們都處于更高的抽象層次。 |
內容簡介：人類到目前為止已經能夠度量越來越多的東西，例如時間、長度等，但是在軟件開發領域，我們依然很難去評估一個軟件系統的質量，以及維護它的難易程度。可維護性越差，意味著開發成本越高、開發速度越慢，以及由于改動帶來的缺陷也越多。在現實中，我們經常會面對代碼混亂、模塊緊耦合的遺留系統，持續攀升的維護難度會最終導致系統不可維護，從而推倒重來。來自軟件改進組織（Software Improvement Group）的咨詢師們，從大量實踐項目中提取出了編寫可維護軟件的10個最佳原則，不僅可以用來測量軟件的質量和可維護性，還可以指導我們如何編寫出高質量的代碼。本書會一一介紹這些原則，并且提供了翔實的代碼示例，能夠讓讀者一步步了解到如何對代碼進行重構，從而達到滿足原則、提高可維護性。本書中的代碼示例都采用Java語言編寫，但是背后的原則也適用于使用其他語言的開發人員。希望各位讀者在閱讀完本書后，能夠了解和掌握如何對軟件系統的質量進行評估和測量，以及如何在實踐中遵循書中的原則，編寫出高質量、簡潔的代碼，開發出松耦合、高可維護性的系統。 |
目錄：關于作者 ..........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 |
| 序： |
