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

關於作者
前言
第1章 簡介
1.1 什麼是可維護性？
1.2 為什麼可維護性很重要?
1.3 本書的三個基本理論
1.4 對可維護性的誤解
1.5 評價可維護性
1.6 可維護性原則的概述
第2章 編寫短小的代碼單元
2.1 動機
2.2 如何使用本原則
2.3 常見的反對意見
2.4 參考
第3章 編寫簡單的代碼單元
3.1 動機
3.2 如何使用本原則
3.3 常見的反對意見
3.4 參考
第4章 不寫重復代碼
4.1 動機
4.2 如何使用本原則
4.3 常見的反對意見
4.4 參考
第5章 保持代碼單元的接口簡單
5.1 動機
5.2 如何使用本原則
5.3 常見的反對意見
5.4 參考
第6章 分離模塊之間的關注點
6.1 動機
6.2 如何使用本原則
6.3 常見的反對意見
第7章 架構組件松耦合
7.1 動機
7.2 如何使用本原則
7.3 常見的反對意見
7.4 參考
第8章 保持架構組件之間的平衡
8.1 動機
8.2 如何使用本原則
8.3 常見的反對意見
8.4 參考
第9章 保持小規模代碼庫
9.1 動機
9.2 如何使用本原則
9.3 常見的反對意見
**0章 自動化開發部署和測試
10.1 動機
10.2 如何使用本原則
10.3 常見的反對意見
10.4 參考
**1章 編寫簡潔的代碼
11.1 不留痕跡
11.2 如何使用本原則
11.3 常見的反對意見
**2章 後續事宜
12.1 將原則變成實踐
12.2 低層級（代碼單元）原則要優先於高層級（組件）原則
12.3 對每次提交負責
12.4 下一本書會討論開發流程的佳實踐
附錄 ASIG如何來評估可維護?
索引