【正文】 b_init_cc （ ）附上補充說明：建立存取iTunes的數(shù)據(jù)庫的同步物件。這么一來，當我們在檢視自己所寫下的樹狀結(jié)構(gòu)時，就能輕易一目了然的理解每個子動作的真正作用。根據(jù)需要了解的粒度，決定展開的層數(shù)我們究竟需要展開多少層呢？這個問題和閱讀程式碼時所需的“粒度（粒度） ”有關(guān)。如果我們只是需要概括性的了解，那么也許展開兩層或三層，就能夠?qū)Τ淌接谢A(chǔ)的認識。倘若需要更深入的了解，就會需要展開更多的層次才行。有時候，你并不是一視同仁地針對每個動作，都展開到相同深度的層次。也許，你會基于特殊的需求，專門針對特定的動作展開至深層。例如，我們閱讀AOL的Winamp的iPod插件的程式目錄，其實是想從中了解究竟應(yīng)該如何存取的iPod上的iTunes的數(shù)據(jù)庫，使我們能夠?qū)P3播放歌曲或播放清單加至此數(shù)據(jù)庫中，并于的iPod中播放。當我們層層探索與分解之后，找到了parseIpodDb （ ） ，從函式名稱判斷它是我們想要的。因為它代表的正是剖析iPod的數(shù)據(jù)庫，正是我們此次閱讀的重點，也就達成閱讀這程式碼的目的。我們強調(diào)一種不同的做法：在閱讀程式碼時，多半采取由上而下的方式，而本文建議了一種記錄閱讀的方式，就是試著記錄探索追蹤時層層展開的樹狀結(jié)構(gòu)。你可以視自己需要，了解的深入程度，再決定要展開的層數(shù)。你更可以依據(jù)特殊的需要，只展開某個特定的節(jié)點，以探索特定的細目。適度地忽略不需要了解的細節(jié)，是一個很重要的態(tài)度，因為你不會一次就需要所有的細節(jié)，閱讀都是有目的的。每次的閱讀也許都在探索程式中不同的區(qū)域。而每次探索時，你都可以增補樹狀結(jié)構(gòu)中的某個子結(jié)構(gòu)。漸漸地，你就會對這個程式更加的了解。閱讀他人的程式碼（ 6 ） 閱讀的樂趣：透過程式碼認識作者即便每個人的寫作模式多半受到他人的影響，程式人通常還是會融合多種風格，而成為自己獨有的特色，如果你知道作者程式設(shè)計的偏好，閱讀他的程式碼就更得心應(yīng)手。閱讀程式碼時，多半會采取由上而下，抽絲剝繭的方式。透過記錄層層展開的樹狀結(jié)構(gòu)，程式人可以逐步地建立起對系統(tǒng)的架構(gòu)觀，而且可以依照需要的粒度（粒度） ，決定展開的層次及精致程度。建立架構(gòu)觀點的認識是最重要的事情。雖然這一系列的文章前提為“閱讀他人的程式碼” ，但我們真正想做的工作，并不在于徹底地詳讀每一行程式碼的細節(jié)，而是想要透過重點式的程式碼“摘讀” ，達到對系統(tǒng)所需程度的了解。每個人在閱讀程式碼的動機不盡相同，需要了解的程度也就有深淺的分別。只有極為少數(shù)的情況下，你才會需要細讀每一行程式碼。閱讀程式碼是新時代程式人必備的重要技能這一系列的文章至此已近尾聲，回顧曾探討的主題，我們首先研究了閱讀程式碼的動機。尤其在開放原始碼的風氣如此之盛的情況下，妥善利用開放原始碼所提供的資源，不僅能夠更快學習到新的技術(shù)，同時在原始碼版權(quán)合適時，還可以直接利用現(xiàn)成的程式碼，大幅地提高開發(fā)階段的生產(chǎn)力。所以，閱讀程式碼儼然成為了新時代程式人必備的重要技能之一。接著，我們提到了閱讀程式碼前的必要準備，包括了對程式語言，命名慣例的了解等等。在此之后，我們反覆提起了“由上而下”的閱讀方向的重要性。由上而下的閱讀方式，是因為我們重視架構(gòu)更勝于細節(jié)。從最外層的架構(gòu)逐一向內(nèi)探索，每往內(nèi)探索一層，我們了解系統(tǒng)的粒度就增加了一個等級。當你識別出系統(tǒng)所用的架構(gòu)時，便能夠輕易了解在這個架構(gòu)下會有的角色，以及它們之間的動態(tài)及靜態(tài)的關(guān)系。如此一來，許多資訊便不言可喻，毋需額外花費力氣，便能夠快速理解。好的名稱能夠摘要性地點出實體的作用追蹤原始碼時，固然可以用本來的方式，利用編輯器開啟所需的檔案，然后利用編輯器提供的機制閱讀，但是倘若能夠善用工具，閱讀程式碼的效率及品質(zhì)都能大大提升。在本系列文章中，我們介紹了一些工具，或許你還可以在坊間找到其他更有用的工具。我在這一系列的文章中，實際帶著大家閱讀，追蹤了一個名為ml_pod的開放原始碼專案。它是一個AOL的Winamp的iPod的外掛程式。在追蹤的過程中，我們試著印證這一系列文中所提到的觀念及方法。我們采用逐漸開展的樹狀結(jié)構(gòu)來記錄追蹤的過程，并借以建立起對系統(tǒng)的概觀認識。就原始碼的閱讀來說，之前的討論涉及了工具面及技巧面。但還有一些主題不在這兩個范疇之內(nèi)，例如，善用名稱賦予你的提示。名稱做為隱喻（隱喻）的作用很大，好的名稱能夠摘要性地點出實體的作用，例如我們看到autoDetectIpod （ ） ，自然而然能夠想像它的作用在于自動（自動）偵測（檢測）的iPod的存在。我們在展開樹狀結(jié)構(gòu)時，有時候需要預(yù)看一層，有時卻不需要這么做，便可得到印證。程式人都會有慣用的名稱以及組合名稱的方法，倘若能夠從名稱上理解，便毋需鉆進細節(jié)，可以省去相當多的時間。例如，當我們看到parseIpodDb （ ）時，便可以輕易了解它是剖析（解析）的iPod的資料庫（ DB ）的，因此便不需要立即鉆進parseIpodDb （ ）中查看底細。盡管如此，能否理解程式人命名的用意，和自身的經(jīng)驗以及是否了解原作者的文化背景，是息息相關(guān)的。命名本身就是一種文化產(chǎn)物。不同的程式人文化，就會衍生出不同的命名文化。當你自己的經(jīng)驗豐富，看過及接觸過的程式碼也多時，對于名稱的感受及聯(lián)想的能力自然會有不同。這種感受和聯(lián)想的能力，究竟應(yīng)該如何精進，很難具體描述。就我個人的經(jīng)驗，多觀察不同命名體系的差異，并且嘗試歸納彼此之間的異同，有助于更快地提升對名稱的感受及聯(lián)想力。轉(zhuǎn)換立場，理解作者的思考方式除了工具及技巧之外， “想要閱讀程式碼，得先試著閱讀寫這個程式碼的程式人的心。 ”這句話說來十分抽象，或許也令人難以理解。當你在閱讀一段程式碼時，或許可以試著轉(zhuǎn)換自己的立場，從旁觀者的角度轉(zhuǎn)換成為寫作者的心態(tài)，揣摩原作者的心理及處境。當你試著設(shè)身處地站在他的立場，透過他的思考方式來閱讀，追蹤他所寫下的程式碼，將會感覺更加流暢。許多軟體專案，都不是由單一程式人所獨力完成。因此，在這樣的專案中，便有可能呈現(xiàn)多種不同的風格。許多專案會由架構(gòu)師決定主體的架構(gòu)及運作，有既定實施的命名慣例，及程式設(shè)計需要遵守方針。在多人開發(fā)的模式下，越是好的軟體專案，越看不出某程式碼片段究竟是由誰所寫下的。不過，有些開放原始碼的專案，往往又整合了其他開放原始碼的專案。有的時候，也很難求風格的統(tǒng)一，便會出現(xiàn)混雜的情況。好比之前提到的ml_pod專案，因為程式碼中混合了不同的來源，而呈現(xiàn)風格不一致的情況。我在閱讀非自己所寫的程式碼時，會觀察原作者寫作的習慣，借以對應(yīng)到腦中所記憶的多種寫作模型。在閱讀的過程中，讀完幾行程式碼，我會試著猜想原作者在寫下這段程式碼時的心境。他寫下這段程式碼的用意是什么？為什么他會采取這樣的寫法？順著原作者的思考理路閱讀，自己的思考才能更貼近對方寫作當時的想法。當你短暫化身為原作者時，才能更輕易的理解他所寫下的程式碼。如果你能知道原作者的背景，程式設(shè)計時的偏好，閱讀他的程式碼，就更能得心應(yīng)手了。從程式碼著手認識作者獨有的風格，進而見賢思齊我在閱讀別人寫下的程式碼時，我會試著猜想，原作者究竟是屬于那一種“流派”呢？每個人都有自己獨特的寫作模式，即便每個人的寫作模式多半受到他人的影響─ ─不論是書籍的作者，學習過程中的指導(dǎo)者，或一同參與專案的同儕，但每個程式人通常會融合多種風格，而成為自己獨有的風格。物件導(dǎo)向的基本教義派，總是會以他心中覺得最優(yōu)雅的物件導(dǎo)向方式來撰寫程式。而閱讀慣用，善用設(shè)計模式的程式人所寫下的程式碼時，不難推想出他會在各種常見的應(yīng)用情境下，套用哪些模式。有些時候，在閱讀之初，你并不知道原作者的習性跟喜好，甚至你也不知道他的功力。但是，在閱讀之后，你會慢慢地從一個程式人所寫下的程式碼，開始認識他。你或許會在閱讀他人的程式碼時，發(fā)現(xiàn)令人拍案叫絕的技巧或設(shè)計。你也有可能在閱讀的同時，發(fā)現(xiàn)原作者所留下的缺失或?qū)懽鲿r的缺點，而暗自警惕于心。這也算是閱讀他人程式碼時的一項樂趣。當你從視閱讀他人的程式碼為畏途，轉(zhuǎn)變成為可以從中獲取樂趣的時候，我想，你又進到了另一個境界。