網(wǎng)上看了篇文章，覺得很不錯，抄在下面。因原文沒注明作者，在這也不知道作者是誰了。

編程概述

編程術可以看作實用魔法的一個分支。編程魔法師用時間和精力做祭品，與生活在計算機中的精靈訂立契約，以換取駕馭代碼的能力。
---fmddlmyy

要提高編程水平，唯有多看多寫。這篇文章看似經(jīng)驗之談，實質(zhì)還是灌水。本次灌水，擬定了以下幾個主題：

§?????? 編程概述

§?????? 軟件開發(fā)中的方法論

§?????? 編程實踐

§?????? 嵌入式編程的特點

編程概述

本文將從不同角度討論 “ 什么是編程 ” ，或者 “ 什么是編程的本質(zhì)問題 ” 。這些討論并不是要得出什么定義，我們實際上是在表述各種編程思想，以期加深對編程的理解。

1 編程不是藝術

我們的世界是模糊的、連續(xù)的、不精確的，但軟件是精確、離散的、形式化的，這就注定了軟件不能完全描述現(xiàn)實世界。因此我們需要知道描述哪些部分，忽略哪些部分，這就是軟件的本質(zhì)問題。
--- Tom Demarco

編程不是藝術。編程不追求完美，它的目的是解決問題。

和藝術上的 “ 只能意會，不可言傳 ” 相反，編程甚至不能忍受自然語言的模糊性，它要求問題被表述成可編譯、可運行的代碼，文字和圖表只是輔助交流的工具。

每個程序員有兩個面具：職業(yè)的和專業(yè)的。戴上職業(yè)面具后，程序員會用能找到的最好用的工具，以盡可能簡單的方式，在合理的成本內(nèi)解決問題中必須解決的部分。

而戴上專業(yè)面具的程序員，會不厭其煩地學習各種編程知識（很多都不是職業(yè)需要的），積累經(jīng)驗值，吸收可復用的模式和思想。他們會用大量時間去理解程序的表象和 CPU 的匯編代碼之間究竟發(fā)生了什么。他們有著探索未知領域和練功升級的強烈欲望。

他們在不斷接近技藝的完美，而這個技藝本身是以不談完美、但求有效的方式解決問題。他們付出了大量的努力，而這些努力的驅(qū)動力是好奇心和進取心。如同《魔法學徒》中描述的魔法師，一個魔法師所追求的東西只有志趣相投的魔法師才能理解，而不管他們出于哪個陣營。了解事物真相本身帶來的滿足就可以作為一切努力的回報，

2 控制復雜性

任何一個正在構建大型系統(tǒng)的人，天天面對的中心議題就是：如何剔除不必要的、人為的、自找的復雜部分，并控制好剩下的，無可逃避的復雜性。
--- Betrand Meyer

編程可以被看成一種管理工作，管理的對象是代碼，控制的對象是代碼的復雜性。

中國的傳統(tǒng)思維比較喜歡談本質(zhì)，追求一種稱作 “ 道 ” 的東西。而在編程上，表象和本質(zhì)同樣重要。所有程序說到底不過是一些匯編語句的組合，但了解這個本質(zhì)在大多數(shù)場合都不能有助于解決實際問題。

寫代碼是為了解決實際問題。當代碼的數(shù)量增加到一定程度，對代碼自身的控制也會成為一個重要的問題。數(shù)量改變了本質(zhì)。

管理的要訣是削弱、孤立被管理的對象， “ 使民無知 ” ， “ 使民 ”“ 雞犬之聲相聞 ” 卻 “ 至老死 ” 而 “ 不相往來 ” 。每個被管理的對象在完成自身工作的前提下，對其它對象的了解應當盡可能少。通過盡量降低對象間的耦合程度來控制復雜性。

只有有效地控制復雜性，我們才能使用越來越大的信息塊，駕馭越來越多的代碼，用這些 0 和 1 的操作去實現(xiàn)前人沒有，甚至無法完成的工作。

3 復用

編程技藝的核心是代碼的復用。復用已有的知識是積累、提高的前提，否則就會像誰誰誰那樣每天推石頭上山，而不能累進。在上帝看來，重復是一種懲罰的手段。

編程這個職業(yè)知識更新比較快，可以學習的東西也很多。有些人覺得累，但有些人卻覺得其樂無窮，覺得從事這個職業(yè)是很幸運的事情。

編程的實質(zhì)是建筑，根據(jù)應用的需求，不斷建筑更大的信息塊。我們所寫的所有程序，都可以被看作對語言的擴充。事實上，我們在不停地開發(fā)新的語言，我們所寫的每個函數(shù)、每個類都是在為現(xiàn)有語言增加新的功能。我們按照適合特定應用的模式，組合各種信息塊，完成實際的應用。這些信息塊有的是我們自己做的，有的是拿來的。

信息塊可以被組合的關鍵就是簡單、明確的接口。所以，我們應當針對接口編程，而不是針對應用編程。應用意味著變化和不可復用。將應用合理分解為模塊，定義好模塊間的接口，然后按照接口構建模塊。模塊分解的原則是：

§?????? 模塊的耦合程度盡可能得低（有人稱此為最少知識原則）；

§?????? 接口盡可能簡單（有人稱此為接口隔離原則）；

§?????? 如果將變化的因素封裝到模塊中，每個模塊應該只封裝一個因素（有人稱此為單一責任原則）；

§?????? 使特定于應用的代碼盡可能得少 。

針對接口編程的好處有兩個方面：

§?????? 信息塊可以被復用；

§?????? 復雜性可以被更好地控制。

人們用各種方式復用知識，其實 C 語言本身又何嘗不是知識的復用呢？其它復用方式包括：庫函數(shù)、新的語言和編譯器、新的腳本、類庫、程序框架、設計模式、面向?qū)ο蟆⒚嫦蚪M件、面向服務、面向方面、面向領域、各種開源代碼、開發(fā)環(huán)境提供的各種 Wizard 和糖衣、各種代碼生成工具等等。充分了解編程環(huán)境，善于復用各種資源，是程序員的基本功。

?

軟件開發(fā)中的方法論

?

1 項目管理的方法論

1.1 方法論

方法論的英文為 Methodology ，編程的方法論應該是指軟件開發(fā)的一整套方法、過程、規(guī)則、實踐、技術。不過我們一般提到的方法論都偏重于項目、過程和人員的管理。

《 Agile Software Development 》的作者 Alistair Cockburn 提出方法論具有以下要素：角色、個性、技能、團隊、技術、活動、過程、產(chǎn)品、里程碑、標準、質(zhì)量、工具、團隊價值，它們的關系可以用一幅圖來表示：

?

雖然將這幅圖貼在這里，事實上我不了解這些要素及其關系的確切定義，對于這些不能精確描述的東西，我接受起來比較困難。

其實，項目管理的核心是溝通和反饋。只要能夠保證良好的溝通和即時的反饋，開發(fā)團隊即使并沒有采用先進的方法論，一樣可以成功。從另一個角度說，過程和工件能輔助，但不能保證開發(fā)人員、項目經(jīng)理和客戶的良好交流。

1.2 重型方法

有的方法論規(guī)定了大量的中間文檔和復雜的過程管理。那些中間文檔被稱為 artifact ，或工件。需要大量 artifact 和軟件開發(fā)方法被稱作重型（ Heavy Weight ）方法。

這些復雜的方法來源于恐懼。

在中大型的項目中，項目經(jīng)理往往遠離代碼，他們無法有效的了解目前的工程的進度、質(zhì)量、成本等因素。為了克服未知的恐懼感，項目經(jīng)理制定了大量的中間管理方法，希望能夠控制整個項目，最典型的莫過于要求開發(fā)人員頻繁地遞交各種報告。重型方法中的基本假設是過程（及各種 artifact ）比個人可靠。

雖然很多輕型方法都將重型方法作為反面例子，但對于大多數(shù)大型項目，重型方法是管理所必需的。

1.3 輕型方法

為了解決重型方法存在的問題，業(yè)界出現(xiàn)了很多輕型（ Light Weight ）方法論。提出這些方法論的部分作者結成了一個聯(lián)盟：敏捷軟件開發(fā)。他們還有一個宣言：

§?????? Individuals and interactions over processes and tools.

§?????? Working software over comprehensive documentation.

§?????? Customer collaboration over contract negotiation.

§?????? Responding to change over following a plan.

在這些宣言后面還有很多原則。概括起來主要是：尊重個人，強調(diào)溝通和反饋，與客戶緊密合作，保持設計的簡單性等等。敏捷方法在重型方法論和無管理狀態(tài)之間尋求一個平衡點，希望用低成本的管理活動帶來最大的產(chǎn)出。

2 編程的方法論

作為程序員，我更感興趣的是可以指導編程的方法論。

2.1 測試驅(qū)動開發(fā)

2.1.1 未謀進，先謀退

在開始一件事情之前，必須先明確什么時候可以停止。什么 “ 止于至善 ” ，在編程工作中可以一腳踢開。我們必須明確要做什么，做到什么樣子就算完成了。

怎樣才算明確呢？最理想的方法是先寫一個測試程序，然后再編寫代碼，讓測試通過。測試程序規(guī)定了停止的必要條件。

測試程序是針對接口編寫的。要寫出測試程序，必須先定義好接口，然后針對接口編程。測試程序同時示范了接口的使用。

如果有一個運行很方便的測試程序，我們在維護代碼時，就放心得多。可以經(jīng)常跑一跑，測試一下，以保證測試要求的功能還沒有被破壞。相反，如果沒有測試程序，我在修改代碼的 bug 時，心里就很不踏實，因為我不清楚我的修改是否會引入新的 bug 。

2.1.2 保持可運行，可調(diào)試的狀態(tài)

“ 先寫測試程序 ” 適合沒有 UI ，功能相對簡單的模塊。對于功能復雜的軟件系統(tǒng)，需要測試的方面很多，測試時間很長，在開發(fā)前就建立一個比較全面的測試，并且隨時使用，有時是不可能的。

但我們至少應該保證：寫任何程序，都要盡量保持在可運行、可調(diào)試的狀態(tài)。即使要為此寫一些額外的程序，都是值得的。在不能運行的情況下，編寫大量代碼是不可思議的事情。

2.1.3 可測試性

IC 設計上有一個 “Design For Test” 的說法，即 IC 的設計中必須要考慮到如何測試，留好測試的接口。軟件開發(fā)也是一樣的，我們寫每段代碼，都要考慮一下這段代碼是否可以測試，為了保證可測試性，必要的時候可以修改設計。

2.2 重構

《重構》這本書內(nèi)容樸實、但對我個人影響很大。在了解 “ 兩頂帽子 ” 和 “ 小步前進 ” 的方法后，我敢于修改任何代碼，甚至是我不熟悉底層邏輯的代碼。

2.2.1 兩頂帽子

我們有兩頂帽子：一頂是不改變功能的前提下，改善現(xiàn)有現(xiàn)有程序的設計；另一頂是增加新的功能，以適應需求變化。我們在任意階段，應該只戴一頂帽子，絕對不能同時戴兩頂帽子。

在增加新功能的時候，往往需要先改進現(xiàn)有的代碼結構，使之能更好地適應變化。如果功能有較大變動，我們應該將這變動分解成盡可能小的步驟，并讓改進代碼和新增功能的小步驟交替進行。將原有代碼平滑地演變到新代碼，既增加了功能，又改善原有代碼的設計。

重構的正式定義應該是 “ 在代碼寫好之后改進它的設計 ” 。但對我而言，重構的思想已經(jīng)融入了我的開發(fā)過程。在開發(fā)中，我同樣按照 “ 兩頂帽子 ” 和 “ 小步前進 ” 的方針平滑地演變代碼，從無到有，逐步完善。

2.2.2 代碼的壞味道

重構的對象是消除 “ 代碼的壞味道 ” ，保持新鮮、健康的代碼。《重構》中列舉了一些典型的壞味道，例如重復代碼、太長的函數(shù)、太長的參數(shù)列等等。

2.2.3 設計和重構

存在這么一種說法： “ 設計不再是一切動作的前提，而是在整個開發(fā)過程中逐漸浮現(xiàn)出來 ” 的。

事實上，在沒有任何軟件工程理論的時代，編程基本上是寫到哪兒算哪兒。歷史是螺旋上升的，在投影上很接近的兩個點在鉛垂線方向上是處于不同高度的。

重構是要糾正過度設計的傾向，告訴程序員：即使開始的設計有缺陷，也沒關系，更不要僵化地保持，我們可以重構代碼，平滑地修改原有設計。這并不是說前期設計不重要。

“ 設計是在整個開發(fā)過程中逐漸浮現(xiàn)出來 ” ，這是在說隨著開發(fā)的深入，我們會對很多問題考慮地更加清楚。在必要的時候，我們應該用重構的方法靈活地改變設計，適應變化。

?

?

編程實踐

鳩集遺失，鑒玩整理，晝夜精勤，每獲一卷，遇一畫，畢孜孜葺綴，竟日寶玩，可致者必貨敝衣 , 減糧食。妻子童仆切切嗤笑，或曰：終日為無益之事何補哉。既而嘆曰：若復不為無益之事，則安能悅有涯之生。
--- 唐 張彥遠 《歷代名畫記》

1 編程的要素

編程有 3 個要素：語言、環(huán)境和思想。

1.1 語言

有人喜歡爭論語言的優(yōu)劣。其實，除了匯編語言，各種語言、腳本、標準庫、類庫、框架都蘊含著大量成熟的編程經(jīng)驗和思想。程序員應該多熟悉一些語言，特別是有代表性的語言。

個人覺得，一個程序員應該掌握一兩種匯編語言（ CISC 的 X86 、 RISC 的 ARM ）、一種面向過程語言（ C ）、兩、三種面向?qū)ο笳Z言（ C++ 、 Java 、 Delphi ）、一兩種腳本語言（ perl 、 python 、 ruby ）。如果有時間，可以再學習一些學術性較強的語言，例如 Scheme 。

學習新的語言，不僅可以吸收語言中蘊含的設計理念，還可以打開連接新空間的大門，使我們可以學習、復用使用該語言的各種資源，例如源代碼、文章、書籍。

1.2 環(huán)境

1.2.1 開發(fā)時和運行時

環(huán)境可以被理解為程序所有外界環(huán)境的總和，包括開發(fā)時環(huán)境、運行時環(huán)境。我們在寫一段程序時，應該對該程序的相關環(huán)境有清楚的了解。

開發(fā)時環(huán)境包括我們使用的編譯（鏈接）環(huán)境、復用的代碼（框架、類庫、控件等），系統(tǒng)的邏輯結構、代碼的文件組織、需要的工具軟件、調(diào)試環(huán)境等等。

運行時環(huán)境包括程序運行時環(huán)境中所包含、發(fā)生的一切，特別是與我們的程序相關的部分。從小處看，我們應該知道如何確定每段代碼運行的 context （線程和堆棧），每個變量所使用的空間的信息。從大處看，我們應該了解系統(tǒng)運行的來龍去脈，各個模塊（邏輯概念）如何相互配合，各個線程（調(diào)度單位）如何相互通信，什么時候可能發(fā)生調(diào)度，系統(tǒng)中有哪些不確定的因素等等。

1.2.2 軟件類型

比較 “ 典型 ” 的軟件類型包括：

1.?? Windows 操作系統(tǒng)；

2.?? Linux 操作系統(tǒng)；

3.?? 編譯器；

4.?? 虛擬機；

5.?? 調(diào)試器；

6.?? Windows 的單機應用程序；

7.?? Windows 的驅(qū)動程序；

8.?? Linux 的應用程序和驅(qū)動程序；

9.?? 基于 socket 的客戶端 - 服務器程序；

10.?? 數(shù)據(jù)庫應用程序；

11.?? 使用數(shù)據(jù)庫的 Web 應用程序；

12.?? 使用 RTOS 的嵌入式軟件；

13.?? 不使用 RTOS 的單片機程序；

14.?? DSP 程序；

15.?? 嵌入式環(huán)境的第三方程序（ J2ME 應用、 BREW 應用、 symbian 的應用程序等等）；

16.?? 各種中大型程序的腳本環(huán)境，插件的開發(fā)、運行環(huán)境；

17.?? Office 應用程序開發(fā)；

18.?? flash 編程；

軟件的種類實在太多，所謂 “ 典型 ” 只是我個人的理解，肯定還有很多軟件類型沒有被列出來。程序員應該了解開發(fā)和運行這些軟件時，究竟發(fā)生了什么。

對于 Windows 、 Linux 操作系統(tǒng)，我們應該有個概要的了解：從 BIOS 程序讀 Master Boot Record ，到系統(tǒng)的裝載運行；應用程序或動態(tài)連接庫（ Linux 的 SO ）的裝載；操作系統(tǒng)的基本模塊（包括內(nèi)核）的功能； Windows 如何通過 COM 機制將各個功能模塊組合起來等等。這些內(nèi)容是 PC 程序的基本運行環(huán)境。

嵌入式環(huán)境相對 PC 環(huán)境要簡單一些，特別是用 NOR flash ，代碼直接從 ROM 運行的系統(tǒng)。一方面，程序員通常可以看到系統(tǒng)運行的所有代碼；另一方面，嵌入式環(huán)境有時不提供第三方程序運行機制，有時提供比較簡單的機制，有時用 java 虛擬機當作第三方程序運行機制。不過，智能手機的應用處理器一般使用 NAND flash ，從 BIOS 運行一小段啟動代碼，將系統(tǒng)裝載到 RAM 運行，同時支持應用程序裝載運行，已經(jīng)很接近 PC 環(huán)境。

編寫單機應用程序，除了語言外，主要要熟悉各種庫、框架、組件。一些通用庫提供了常用函數(shù)、各種容器和算法、 GUI 、典型的程序框架，系統(tǒng) API 的封裝等等，例如：

§?????? 移植性比較好的 C 標準庫、 STL 、 boost 、 TK 等；

§?????? Windows 上的 MFC 、 VCL （ Delphi/C++ Builder ）；

§?????? Linux 上的 ncurses 、 X Windows 、 GTK 、 Qt 等；

§?????? 訪問數(shù)據(jù)庫： VC++ 的 ODBC 、 DAO 、 ADO ， Borland 的 BDE 等；

§?????? Borland 做了一些在源代碼級跨平臺的庫： Delphi/Kylix 的 CLX 、 dbExpress ；

§?????? CPAN 上的大量 perl 模塊、 java 的類庫等等；

上面列出的是一些比較通用的庫。還有用于各種語言的大量專用庫，各種提供二進制接口的組件、控件。

編譯器、虛擬機也是單機應用程序（在嵌入式環(huán)境，虛擬機可能是系統(tǒng)軟件的一個模塊）。不過它們的地位比較特殊。作為程序員，我們應該了解編譯器、集成開發(fā)環(huán)境、軟件框架、虛擬機、操作系統(tǒng)分別為我們做了什么。

作為程序員，我們同樣應該理解調(diào)試器也是一個應用程序，調(diào)試器的基本原理，它能做什么，有什么限制。如果調(diào)試器與目標程序運行在不同的 CPU 上，調(diào)試是如何實現(xiàn)的，有哪些不同的實現(xiàn)方式？例如 JTAG 調(diào)試利用了目標 CPU 的調(diào)試接口直接調(diào)試目標程序；串口調(diào)試要求將一段調(diào)試代碼和目標程序鏈接在一起下到目標 CPU 中，由嵌入的調(diào)試代碼與 PC 機的調(diào)試器通信實現(xiàn)調(diào)試。不同的實現(xiàn)手段決定了調(diào)試器的能力和限制。

目前最熱門的軟件類型就是使用數(shù)據(jù)庫的 Web 應用了，例如各種網(wǎng)站、網(wǎng)絡游戲、各種企業(yè)、行業(yè)、政府機構的管理系統(tǒng)，在這個領域集中了處于食物鏈不同環(huán)節(jié)的大量廠商，各種 Web 服務器、基礎平臺、應用開發(fā)框架。隨便列一下，也能列出一堆名詞：

§?????? HTML/CSS 和 CGI ；

§?????? java applet 、 java script 、 ActiveX 控件；

§?????? php 、 asp 、 jsp 、 servlet ；

§?????? .net 家族： asp.net 、 ado.net 等；

§?????? J2EE with/without EJB 、 Spring 、 Struts 、 Hibernate ；

§?????? Ruby on Rails 、 Plone 等；

在一種軟件類型上，集中了這么多開發(fā)技術、框架、模式，也可以稱得上蔚為壯觀了。不過，這個領域里確實是各種最新的編程思想、方法、設計模式的演武廳，如同當年的編譯器，值得所有程序員研究、學習。

1.3 思想

COM 可以被看作 OLE 發(fā)展的衍生品。但它的重要性遠遠超過了 OLE 。它首被獨立出來，成為 OLE 、 ActiveX 的基礎，然后逐步成為在 Windows 進行二進制集成的基礎。 COM 和 RPC 的結合產(chǎn)生了 DCOM 。 DCOM 和 MTS 的結合產(chǎn)生了 COM+ 。雖然這些技術都是用于 Windows 平臺的，但組件技術的基本思想是獨立于具體環(huán)境的。也就是說，對程序員而言，存在著獨立于語言和環(huán)境之外的領域，這就是編程的思想。

例如看看 Qualcomm 的 BREW ，就會發(fā)現(xiàn)它從 COM 中學習了多少東西。嵌入式平臺的程序員使用 PC 平臺的技術，這就是編程思想的價值。對于程序員來說，各種編程思想、設計模式，是最為寶貴的東西。這里所說的設計模式并不局限于 GOF 的《設計模式》，任何慣用的手法都可以被看作模式。

一些基本的編程思想起源于更普遍的智慧。例如：

心智的活動，除了盡力產(chǎn)生各種簡單的認識之外，主要表現(xiàn)在以下三個方面： 1) 將若干簡單認識組合成一個復合認識，由此產(chǎn)生出各種復雜的認識。 2) 將兩個認識放在一起對照（在這樣做時并不將它們合而為一），不管它們?nèi)绾魏唵位蛘邚碗s，由此得到有關它們的相互關系的認識。 3) 將有關認識與那些在實際中和它們同在的所有其他認識隔離開，這就是抽象。所有具有普遍性的認識都是這樣得到的。
--- John Locke, 有關人類理解的隨筆

程序員從這段 1690 年的文字中能看到什么。組合、對照、抽象，這些基本的思維工具同樣也是程序員最基本的工具。

2 編程規(guī)則

編程是一門技藝，如同我們必須跳到水里才能學會游泳，我們必須多看、多寫程序，才能學會編程。

任何技藝的學習都包括知識和能力兩個部分。知識是明確的，可以用時間換取。能力是說不清的，不易掌握的。一般而言，能力高的人能夠更快地積累知識，善于從已有的實踐中總結規(guī)律，善于復用已有的模式，他們能更快地對復雜的環(huán)境形成清晰的認識，用最簡潔、優(yōu)雅的方式解決問題。如何提高編程能力應該是因人而異，每個人應該找到自己的學習路徑，有自己的規(guī)劃。

編程的表象千變?nèi)f化，但在表象背后，還是有一定規(guī)律的。在某些條件下，這樣做會比那樣做更好一些。我們可以將這些東西稱作經(jīng)驗、原則、規(guī)則，或者其它任何名詞。

下面松散地列舉了一些規(guī)則。我們應該在實踐中檢驗已知的規(guī)則，總結自己的規(guī)則。

規(guī)則一 這世界上唯一的真理就是不要盲目相信真理

從某種意義看，原則、規(guī)矩這類東西就是用來打破的。所謂原則，就是對歷史上某種經(jīng)驗的總結。如果我們踏入的河流和前人非常接近，我們可以參考前人的經(jīng)驗。我們是主動地拿來，而不是被動的遵守。

規(guī)則二 未蘊而變，自欺也；知律而變，智者之道也

這句話談的是學詞，必須先了解格律，然后才談得上變化，否則就是自欺欺人了。在編程上，也是一樣。在有資格打破一條原則前，首先要了解這條原則。先了解事物的規(guī)律，然后才是變化和靈活的應用。不要打倒自己不了解的東西。

規(guī)則三 尋找結構和成本的平衡點。當結構不能容納變化時，重構代碼到新的平衡點

開閉原則要求：一個軟件實體應該對擴展開放，對修改關閉。即軟件的結構要達到：允許在不修改軟件的前提下擴展軟件功能。

但好結構是要花成本的。程序員總是在折衷，尋找結構和成本的平衡點。我們會放一些余量，讓結構能承受一定的變化。

規(guī)則四 要針對接口編程，不要針對應用編程

前面談過了。我們總希望通過工作得到一些收獲，積累一些經(jīng)驗。只有將代碼分解成盡可能獨立的模塊，然后針對接口編程，才能保護我們的成果，讓我們有所積累。

規(guī)則五 最少知識原則：模塊對外界的了解應當盡可能少

前面也談過了。所謂 “ 圣人之治 ” ，經(jīng)常是 “ 虛其心，實其腹；弱其志，強其骨，常使民無知無欲 ” 。讓被管理的對象盡可能得弱，對象間的關系盡可能得簡單，可以降低管理的成本。

在面向?qū)ο缶幊讨?/span> “ 組合優(yōu)于繼承 ” ，就是因為繼承將基類的實現(xiàn)細節(jié)暴露給子類，兩者的耦合性太強了。另外，繼承的實現(xiàn)是靜態(tài)的，而組合可以更靈活地實現(xiàn)。

規(guī)則六 尊重習慣

在任何領域編程，應該盡量了解這個領域的習慣，盡量符合這些習慣。這樣，別人可以更容易地理解和使用我們的程序，更不容易出錯。

規(guī)則七 程序中不要出現(xiàn) magic number 或其它神奇的東西

magic number 就是諸如 17 、 42 這類數(shù)字。請用有描述性的常數(shù)名替代它們。常數(shù)名、變量名、函數(shù)名就是最好的注釋。結構清晰的代碼甚至可以不需要其它注釋。

“ 需要很多注釋的代碼 ” 是代碼壞味道的一種，常常意味著需要重構代碼，使它更容易被理解。

規(guī)則八 “ 兩頂帽子 ” 和 “ 小步前進 ”

“ 兩頂帽子 ” 前面講過了。面對復雜的問題，我們不僅要從結構上分解它，還要將實現(xiàn)步驟盡可能地分小，在一時一地以壓倒性優(yōu)勢解決問題的一小部分。 n-1 個總比 n 個好對付，我們越來越強大，敵人越來越弱小，我們要做的只是將優(yōu)勢保持到最后。 “ 保持優(yōu)勢 ” 的關鍵是正確的理解、合理的劃分。

規(guī)則九 適當?shù)匾胫虚g層，可以解決所有問題

這條規(guī)則是實質(zhì)是 “ 抽象 ” 。在遇到問題時，多引入一層接口，將問題封裝起來。

抽象本身并沒有消除系統(tǒng)的復雜性，但它減少了在某個時刻需要處理的細節(jié)的數(shù)量。或者說，抽象將復雜性控制在接口和模型的后面，可以推遲我們處理這些復雜性的時刻。

這條規(guī)則的另一個說法是 “ 多做白日夢 ” 。假設我們已經(jīng)得到了需要的東西，然后會怎么樣？通過 “ 白日夢 ” 我們可以在更高的層次考察問題，可能找到解決問題的線索，也有可能發(fā)現(xiàn)這個問題毫無價值。即使毫無收獲，我們也的損失也很小。

規(guī)則十 不要依賴調(diào)試，盡可能地依賴分析和推理

我經(jīng)常會在頭腦中預演調(diào)試的過程，計算我要做什么，我能得到什么。 “ 預演 ” 的結果經(jīng)常是我沒有必要這樣調(diào)試，或者應該試一試另一個方法。

根據(jù)測不準原理，任何實際的測量、調(diào)試都會改變、影響被研究的對象。用調(diào)試輔助、驗證我們的推測，但不要依賴調(diào)試。

?