如何快速讀懂大型C++程式程式碼
阿新 • • 發佈：2019-01-09
六個章節：
（ 1 ）讀懂程式碼，使心法皆為我所用。
（ 2 ）摸清架構，便可輕鬆掌握全貌。
（ 3 ）優質工具在手，讀懂程式非難事。
（ 4 ）望文生義，進而推敲元件的作用。
（ 5 ）找到程式入口，再由上而下抽絲剝繭。
（ 6 ）閱讀的樂趣，透過程式碼認識作者。
閱讀他人的程式碼（ 1 ） ---讀懂程式碼，使心法皆為我所用
程式碼是別人寫的，只有原作者才真的瞭解程式碼的用途及涵義。許多程式人心裡都有一種不自覺的恐懼感，深怕被迫去碰觸其他人所寫的程式碼。但是，與其抗拒接收別人的程式碼，不如徹底瞭解相關的語言和慣例，當成是培養自我實力的基石。
對大多數的程式人來說，撰寫程式碼或許是令人開心的一件事情，但我相信，有更多人視閱讀他人所寫成的程式碼為畏途。許多人寧可自己重新寫過一遍程式碼，也不願意接收別人的程式碼，進而修正錯誤，維護它們，甚至加強功能。
這其中的關鍵究竟在何處呢？若是一語道破，其實也很簡單，程式碼是別人寫的，只有原作者才真的瞭解程式碼的用途及涵義。許多程式人心裡都有一種不自覺的恐懼感，深怕被迫去碰觸其他人所寫的程式碼。這是來自於人類內心深處對於陌生事物的原始恐懼。
讀懂別人寫的程式碼，讓你收穫滿滿
不過，基於許多現實的原因，程式人時常受迫要去接收別人的程式碼。例如，同事離職了，必須接手他遺留下來的工作，也有可能你是剛進部門的菜鳥，而同事經驗值夠了，升級了，風水輪流轉，一代菜鳥換菜鳥。甚至，你的公司所承接的專案，必須接手或是整合客戶前一個廠商所遺留下來的系統，你們手上只有那套系統的原始碼（運氣好時，還有數量不等的檔案）。
諸如此類的故事，其實時常在程式人身邊或身上持續上演著。許多程式人都將接手他人的程式碼，當做一件悲慘的事情。每個人都不想接手別人所撰寫的程式碼，因為不想花時間去探索，寧可將生產力花在產生新的程式碼，而不是耗費在瞭解這些程式碼上。
先了解系統架構與行為模式，再細讀
如果你不能熟悉這項工作，不僅在遭逢你所不願面對的局面時，無法解決眼前接手他人程式碼的難題，更重要的是，當你看著眼前現成的程式碼，卻不知如何從中擷取自己所需，導致最後只能入寶山空手回，望之興嘆。
接觸他人的程式碼，大致上可以分為三種程度：一，瞭解，二，修改，擴充，三，抽取，提煉。瞭解別人的程式碼是最基礎的工作，倘若不能瞭解自己要處理的程式碼，就甭論修改或擴充，更不可能去蕪存菁，從中萃取出自己所需，回收再利用別人所撰寫的程式碼。雖說是“閱讀” ，但程式碼並不像文章或小說一樣，透過這種做法，便能夠獲得一定程度的瞭解。閱讀文章或小說時，幾乎都是循序地閱讀，你只消翻開第一頁，一行行閱讀下去即可。但是，有許多程式人在試著閱讀其他人的程式碼時，卻往往有不知如何讀起的困難。
或許找到系統的第一頁（也就是程式碼執行的啟始點）並不難，但是複雜度高的系統，有時十分龐大，有時千頭萬緒。
從程式碼的啟始點開始讀起，一來要循序讀完所有的程式碼曠日費時，二來透過這種方式來了解系統，很難在腦中構建出系統的面貌，進而瞭解到系統真正的行為。所以，閱讀程式碼的重點，不在於讀完每一行程式碼，而是在於有效率地透過探索及閱讀，從而瞭解系統的架構及行為模式。以便在你需要了解任何片段的細節實作時，能夠很快在腦上對映到具體的程式碼位置，直到那一刻，才是細讀的時機。
熟悉溝通語言與慣例用語
首先，你最好得了解程式碼寫成的程式語言。想要讀懂法文寫成的小說，總不能連法文都不懂吧。有些情況則很特殊。我們雖然不懂該程式碼撰寫所用的語言，但是因為現代語言的高階化，而且流行的程式語言多半都是血統相近，所以即使不那麼熟悉，有時也可勉力為之。
除了認識所用語言之外，再來就是要先確認程式碼所用的命名慣例（命名慣例）。瞭解命名慣例很重要，不同的程式人或開發團隊，差異可能很大。
這命名慣例涵蓋的範圍通常包括了變數的名稱，函式的名稱，類別（如果是物件導向的話）的名稱，原始碼檔案，甚至是專案建構目錄的名稱。倘若使用了像設計模式之類的方法，這些名稱更有一些具體的表述方式。
命名慣例有點像是程式人在程式語言之上，另行建構的一組溝通行話。程式人會透過共通約束，遵守的命名慣例，來表達一些較高階的概念。例如，有名的匈牙利式命名法，便將變數名稱以屬性，型別，說明合併在一起描述。對程式人來說，這種方式能夠提供更豐富的資訊，以瞭解該變數的作用及性質。
對程式碼閱讀來說，熟悉這個做法之所以重要，是因為當你瞭解整個系統所採用的慣例時，你便能試著以他們所共同操用的語彙來進行理解。倘若，不能瞭解其所用的慣例，那麼這些額外提供的資訊，就無法為你所用。像以設計模式寫成的程式碼，同樣處處充滿著模式的名稱，諸如：工廠，門面，代理等等。以這些名稱指涉的類別，也直接透過名稱，表達了它們自身的作用。對於懂得這命名慣例的讀者來說，不需要深入探索，也能很快捕捉到這些類別的意義。
當你拿到一套必須閱讀的程式碼時，最好先取得命名慣例的說明檔案。然而，並不是每套程式碼都附有此類的說明檔案。另一個方式，就是自己到程式碼中，大略瀏覽一遍，有經驗的程式人可以輕易發掘出該系統所用的命名慣例。
常見的命名方式不脫那幾類，這時候經驗就很重要，倘若你知道的慣例越多，就越能輕易識別他人所用的慣例。如果運氣很糟，程式碼所用的慣例是前所未見的，那麼你也得花點時間歸納，憑自己的力量找出這程式碼命名上的規則。
掌握程式碼撰寫者的心態與習慣
想要閱讀程式碼，得先試著體會程式碼作者的“心” 。想要這麼做，就得多瞭解對方所使用的語言，以及慣常運用的語彙。在下一回中，我們將繼續探討閱讀程式碼的相關議題。
閱讀他人的程式碼（ 2 ） -摸清架構，便可輕鬆掌握全貌
在本文中，我們的重點放在：要了解一個系統，最好是採取由上至下的方式。先試著捕捉系統架構性的觀念，不要過早鑽進細節，因為那通常對於你瞭解全貌，沒有多大的幫助。閱讀程式碼不需要從第一行讀起，我們的目的並不是在於讀遍每一段程式碼。
基於許多原因，程式人需要閱讀其他人所寫成的程式碼。而對程式設計2.0時代的程式人來說，最正面的價值在於，能讀懂別人程式的人，才有能力從中萃取自己所需的程式，藉以提高生產力。
閱讀程式碼的目的，在於瞭解全貌而非細節
想要讀懂別人程式碼的根本基礎，便是瞭解對方所用的程式語言及命名慣例。有了這個基礎之後，才算是具備了基本的閱讀能力。正如我之前提到的─ ─想要讀懂法文寫成的小說，總不能連法文都不懂吧。閱讀程式碼和閱讀文學作品，都需要了解撰寫所用的語言及作者習用的語彙。
但我們在閱讀文學作品通常是採循序的方式，也就是從第一頁開始，一行一行地讀下去，依循作者為你鋪陳的步調，逐漸進到他為你準備好的世界裡。閱讀程式碼卻大大不同。我們很少從第一行開始讀起，因為除非它是很簡單的單執行緒程式，否則很少這麼做。因為要是這麼做，就很難了解整個系統的全貌。是的，我們這邊提到了一個重點，閱讀程式碼的目的在於瞭解系統的全貌，而不是在於只是為了地毯式的讀遍每一段程式碼。
就拿物件導向程式語言所寫成的系統來說，整個系統被拆解，分析成為一個個獨立的類別。閱讀個別類別的程式碼，或許可以明白每項類別物件個別的行為。但對於各類別物件之間如何互動影響，如何協同工作，又很容易陷入盲人摸象的困境。這是因為各類別的程式碼，只描述個別物件的行為，而片段的閱讀就只能造就片面的認識。
由上而下釐清架構後，便可輕易理解組成關係
如果你想要跳脫困境，不想浪費大量時間閱讀程式碼，卻始終只能捕捉到對系統片段認識，就必須轉換到另一種觀點來看待系統。從個別的類別行為著手，是由下至上（自下而上）的方法;在閱讀程式碼時，卻應該先採由上至下（自上而下）的方式。對程式碼的閱讀來說，由上至下意謂著，你得先了解整個系統架構。
系統的架構是整個系統的骨幹，支柱。它表現出系統最突出的特徵。知道系統架構究竟屬於那一種型別，通常大大有益於瞭解系統的個別組成之間的靜態及動態關係。有些系統因為所用的技術或框架的關係，決定了最上層的架構。例如，採用的Java Servlet的/ JSP的技術的應用系統，最外層的架構便是以J2EE的（或起碼的J2EE中的Web容器）為根本。
使用的Java Servlet的/ JSP的技術時，決定了某些組成之間的關係。例如， Web容器依據web.xml中的內容載入所有的Servlets ，聽眾，以及過濾器。每當語境發生事件（例如初始化）時，它便會通知監聽類別。每當它收到來自客戶端的請求時，便會依循設定的所有過濾器鏈，讓每個過濾器都有機會檢查並處理此一請求，最後再將請求導至用來處理該請求的Servlet的。
當我們明白某個系統採用這樣的架構時，便可以很容易地知道各個組成之間的關係。即使我們還不知道究竟有多少Servlets ，但我們會知道，每當收到一個請求時，總是會有個相對應的伺服器來處理它。當想要關注某個請求如何處理時，我應該去找出這個請求對應的伺服器。
瞭解架構，必須要加上層次感
同樣的，以爪哇寫成的網頁應用程式中，也許會應用諸如Struts的之類的的MVC框架，以及像Hibernate的這樣的資料存取框架。它們都可以視為最主要的架構下的較次級架構。而各個應用系統，甚至有可能在Struts的及休眠之下，建立自有的更次級的架構。
（ 1 ）讀懂程式碼，使心法皆為我所用。
（ 2 ）摸清架構，便可輕鬆掌握全貌。
（ 3 ）優質工具在手，讀懂程式非難事。
（ 4 ）望文生義，進而推敲元件的作用。
（ 5 ）找到程式入口，再由上而下抽絲剝繭。
（ 6 ）閱讀的樂趣，透過程式碼認識作者。
閱讀他人的程式碼（ 1 ） ---讀懂程式碼，使心法皆為我所用
程式碼是別人寫的，只有原作者才真的瞭解程式碼的用途及涵義。許多程式人心裡都有一種不自覺的恐懼感，深怕被迫去碰觸其他人所寫的程式碼。但是，與其抗拒接收別人的程式碼，不如徹底瞭解相關的語言和慣例，當成是培養自我實力的基石。
對大多數的程式人來說，撰寫程式碼或許是令人開心的一件事情，但我相信，有更多人視閱讀他人所寫成的程式碼為畏途。許多人寧可自己重新寫過一遍程式碼，也不願意接收別人的程式碼，進而修正錯誤，維護它們，甚至加強功能。
這其中的關鍵究竟在何處呢？若是一語道破，其實也很簡單，程式碼是別人寫的，只有原作者才真的瞭解程式碼的用途及涵義。許多程式人心裡都有一種不自覺的恐懼感，深怕被迫去碰觸其他人所寫的程式碼。這是來自於人類內心深處對於陌生事物的原始恐懼。
讀懂別人寫的程式碼，讓你收穫滿滿
不過，基於許多現實的原因，程式人時常受迫要去接收別人的程式碼。例如，同事離職了，必須接手他遺留下來的工作，也有可能你是剛進部門的菜鳥，而同事經驗值夠了，升級了，風水輪流轉，一代菜鳥換菜鳥。甚至，你的公司所承接的專案，必須接手或是整合客戶前一個廠商所遺留下來的系統，你們手上只有那套系統的原始碼（運氣好時，還有數量不等的檔案）。
諸如此類的故事，其實時常在程式人身邊或身上持續上演著。許多程式人都將接手他人的程式碼，當做一件悲慘的事情。每個人都不想接手別人所撰寫的程式碼，因為不想花時間去探索，寧可將生產力花在產生新的程式碼，而不是耗費在瞭解這些程式碼上。
先了解系統架構與行為模式，再細讀
如果你不能熟悉這項工作，不僅在遭逢你所不願面對的局面時，無法解決眼前接手他人程式碼的難題，更重要的是，當你看著眼前現成的程式碼，卻不知如何從中擷取自己所需，導致最後只能入寶山空手回，望之興嘆。
接觸他人的程式碼，大致上可以分為三種程度：一，瞭解，二，修改，擴充，三，抽取，提煉。瞭解別人的程式碼是最基礎的工作，倘若不能瞭解自己要處理的程式碼，就甭論修改或擴充，更不可能去蕪存菁，從中萃取出自己所需，回收再利用別人所撰寫的程式碼。雖說是“閱讀” ，但程式碼並不像文章或小說一樣，透過這種做法，便能夠獲得一定程度的瞭解。閱讀文章或小說時，幾乎都是循序地閱讀，你只消翻開第一頁，一行行閱讀下去即可。但是，有許多程式人在試著閱讀其他人的程式碼時，卻往往有不知如何讀起的困難。
或許找到系統的第一頁（也就是程式碼執行的啟始點）並不難，但是複雜度高的系統，有時十分龐大，有時千頭萬緒。
從程式碼的啟始點開始讀起，一來要循序讀完所有的程式碼曠日費時，二來透過這種方式來了解系統，很難在腦中構建出系統的面貌，進而瞭解到系統真正的行為。所以，閱讀程式碼的重點，不在於讀完每一行程式碼，而是在於有效率地透過探索及閱讀，從而瞭解系統的架構及行為模式。以便在你需要了解任何片段的細節實作時，能夠很快在腦上對映到具體的程式碼位置，直到那一刻，才是細讀的時機。
熟悉溝通語言與慣例用語
首先，你最好得了解程式碼寫成的程式語言。想要讀懂法文寫成的小說，總不能連法文都不懂吧。有些情況則很特殊。我們雖然不懂該程式碼撰寫所用的語言，但是因為現代語言的高階化，而且流行的程式語言多半都是血統相近，所以即使不那麼熟悉，有時也可勉力為之。
除了認識所用語言之外，再來就是要先確認程式碼所用的命名慣例（命名慣例）。瞭解命名慣例很重要，不同的程式人或開發團隊，差異可能很大。
這命名慣例涵蓋的範圍通常包括了變數的名稱，函式的名稱，類別（如果是物件導向的話）的名稱，原始碼檔案，甚至是專案建構目錄的名稱。倘若使用了像設計模式之類的方法，這些名稱更有一些具體的表述方式。
命名慣例有點像是程式人在程式語言之上，另行建構的一組溝通行話。程式人會透過共通約束，遵守的命名慣例，來表達一些較高階的概念。例如，有名的匈牙利式命名法，便將變數名稱以屬性，型別，說明合併在一起描述。對程式人來說，這種方式能夠提供更豐富的資訊，以瞭解該變數的作用及性質。
對程式碼閱讀來說，熟悉這個做法之所以重要，是因為當你瞭解整個系統所採用的慣例時，你便能試著以他們所共同操用的語彙來進行理解。倘若，不能瞭解其所用的慣例，那麼這些額外提供的資訊，就無法為你所用。像以設計模式寫成的程式碼，同樣處處充滿著模式的名稱，諸如：工廠，門面，代理等等。以這些名稱指涉的類別，也直接透過名稱，表達了它們自身的作用。對於懂得這命名慣例的讀者來說，不需要深入探索，也能很快捕捉到這些類別的意義。
當你拿到一套必須閱讀的程式碼時，最好先取得命名慣例的說明檔案。然而，並不是每套程式碼都附有此類的說明檔案。另一個方式，就是自己到程式碼中，大略瀏覽一遍，有經驗的程式人可以輕易發掘出該系統所用的命名慣例。
常見的命名方式不脫那幾類，這時候經驗就很重要，倘若你知道的慣例越多，就越能輕易識別他人所用的慣例。如果運氣很糟，程式碼所用的慣例是前所未見的，那麼你也得花點時間歸納，憑自己的力量找出這程式碼命名上的規則。
掌握程式碼撰寫者的心態與習慣
想要閱讀程式碼，得先試著體會程式碼作者的“心” 。想要這麼做，就得多瞭解對方所使用的語言，以及慣常運用的語彙。在下一回中，我們將繼續探討閱讀程式碼的相關議題。
閱讀他人的程式碼（ 2 ） -摸清架構，便可輕鬆掌握全貌
在本文中，我們的重點放在：要了解一個系統，最好是採取由上至下的方式。先試著捕捉系統架構性的觀念，不要過早鑽進細節，因為那通常對於你瞭解全貌，沒有多大的幫助。閱讀程式碼不需要從第一行讀起，我們的目的並不是在於讀遍每一段程式碼。
基於許多原因，程式人需要閱讀其他人所寫成的程式碼。而對程式設計2.0時代的程式人來說，最正面的價值在於，能讀懂別人程式的人，才有能力從中萃取自己所需的程式，藉以提高生產力。
閱讀程式碼的目的，在於瞭解全貌而非細節
想要讀懂別人程式碼的根本基礎，便是瞭解對方所用的程式語言及命名慣例。有了這個基礎之後，才算是具備了基本的閱讀能力。正如我之前提到的─ ─想要讀懂法文寫成的小說，總不能連法文都不懂吧。閱讀程式碼和閱讀文學作品，都需要了解撰寫所用的語言及作者習用的語彙。
但我們在閱讀文學作品通常是採循序的方式，也就是從第一頁開始，一行一行地讀下去，依循作者為你鋪陳的步調，逐漸進到他為你準備好的世界裡。閱讀程式碼卻大大不同。我們很少從第一行開始讀起，因為除非它是很簡單的單執行緒程式，否則很少這麼做。因為要是這麼做，就很難了解整個系統的全貌。是的，我們這邊提到了一個重點，閱讀程式碼的目的在於瞭解系統的全貌，而不是在於只是為了地毯式的讀遍每一段程式碼。
就拿物件導向程式語言所寫成的系統來說，整個系統被拆解，分析成為一個個獨立的類別。閱讀個別類別的程式碼，或許可以明白每項類別物件個別的行為。但對於各類別物件之間如何互動影響，如何協同工作，又很容易陷入盲人摸象的困境。這是因為各類別的程式碼，只描述個別物件的行為，而片段的閱讀就只能造就片面的認識。
由上而下釐清架構後，便可輕易理解組成關係
如果你想要跳脫困境，不想浪費大量時間閱讀程式碼，卻始終只能捕捉到對系統片段認識，就必須轉換到另一種觀點來看待系統。從個別的類別行為著手，是由下至上（自下而上）的方法;在閱讀程式碼時，卻應該先採由上至下（自上而下）的方式。對程式碼的閱讀來說，由上至下意謂著，你得先了解整個系統架構。
系統的架構是整個系統的骨幹，支柱。它表現出系統最突出的特徵。知道系統架構究竟屬於那一種型別，通常大大有益於瞭解系統的個別組成之間的靜態及動態關係。有些系統因為所用的技術或框架的關係，決定了最上層的架構。例如，採用的Java Servlet的/ JSP的技術的應用系統，最外層的架構便是以J2EE的（或起碼的J2EE中的Web容器）為根本。
使用的Java Servlet的/ JSP的技術時，決定了某些組成之間的關係。例如， Web容器依據web.xml中的內容載入所有的Servlets ，聽眾，以及過濾器。每當語境發生事件（例如初始化）時，它便會通知監聽類別。每當它收到來自客戶端的請求時，便會依循設定的所有過濾器鏈，讓每個過濾器都有機會檢查並處理此一請求，最後再將請求導至用來處理該請求的Servlet的。
當我們明白某個系統採用這樣的架構時，便可以很容易地知道各個組成之間的關係。即使我們還不知道究竟有多少Servlets ，但我們會知道，每當收到一個請求時，總是會有個相對應的伺服器來處理它。當想要關注某個請求如何處理時，我應該去找出這個請求對應的伺服器。
瞭解架構，必須要加上層次感
同樣的，以爪哇寫成的網頁應用程式中，也許會應用諸如Struts的之類的的MVC框架，以及像Hibernate的這樣的資料存取框架。它們都可以視為最主要的架構下的較次級架構。而各個應用系統，甚至有可能在Struts的及休眠之下，建立自有的更次級的架構。