為什麼學習一門新技術時,所能找到的API文件往往無法滿足我們?所以,此時閱讀程式原始碼會是必要的工作?而這是不是意謂著,程式庫或框架發生抽象滲漏了呢?

文件是一層抽象

在接觸一門新技術時,我多半會從一些簡易的入門文件開始,如果這門技術引起了我的興趣,也許會進一步透過書籍的閱讀,有系統地進行認識,然而,有時候會遇上既有的書籍不多,或內容不夠深入的狀況,在那當下,官方的API文件就會是重要的參考來源。

所謂的「不夠深入」是什麼意思呢?舉個實際的例子,在接觸Flutter時,入門文件為了呈現Flutter的易用性,多半會是簡單的元件組合介紹,然而,我想知道元件間必須遵循什麼規則,才能組合在一起。這就像積木,照著成品的組裝圖你也許可以組合出暴龍,然而,若不明白積木間的銜接方式,收起組裝圖之後,就什麼也組不起來。

而在官方的API文件中,往往會描述元件在組裝時,彼此之間要有的結構或行為關係,具體來說就是型態、繼承、回呼、生命週期之類的關係,在最理想的情況下,官方文件的閱讀,應該可以讓開發者在不查看原始碼的情況下,理解程式庫或框架做了什麼事。

也就是說,官方的API文件本身是一種契約,描述了API公開的介面背後做了什麼事情!「等等!你這種說法是在說官方文件揭露實作細節嗎?」不是的!我只是在說,官方的API文件是一層抽象,對具體實作的抽象。

「抽象?那不是API公開的介面在做的事嗎?」

不!「介面不是抽象」。我在先前專欄〈測試與抽象滲漏〉中就談過,介面只是個溝通的管道,以公開函式來說,就是你給它相關的引數,它傳回結果,而在理想的情況下,會希望函式名稱就能說明它做了什麼,不過,事情往往沒那麼簡單,在函式名稱、參數、傳回值無法表達的細節部份,就需要API文件來加以說明。

以Python的asyncio.run為例好了,函式名稱與引數能說明什麼嗎?不行吧!我們要查看API文件,才能知道它做了什麼,然而API文件並不是在描述程式流程的實作細節,它只是在描述會有個事件迴圈,能幫開發者管理協程,可以使用單執行緒運行之類的,讓開發者能掌握這個函式運作時「大致的輪廓」,從而決定是否信賴asyncio.run這個API。

原始碼中的各種抽象

最近我在看文件時,有時會就原文解釋或單字的字源去理解它,「抽象」是abstract的譯文,劍橋詞典線上英英解釋是「existing as an idea, feeling, or quality, not as a material object」,也就是非實物的想法、感受、特性,abstract來自拉丁文的abstractus,是abs-與trahō的組合,字面上是離開、脫離之義。

從這點來說,有些語言的抽象元件,是從某些概念抽離的不具體特性,想理解這些元件,必須知道它是從哪些概念抽離出來,例如,想理解抽象類別(abstract class),必須知道它從哪些概念抽離而得,如果越能掌握那些來源概念,在運用API提供的抽象時,才越能得心應手。

而對於程式庫或框架學習者為何要有探究原始碼的能力與習慣,這也提出了解答。因為API文件提供了一層抽象,然而,有時候僅知道這層抽象,不足以讓開發者有信心能掌握程式庫或框架,這時就必須親自探究一下原始碼了。

「這不是在介入細節嗎?」不!這只是在試圖理解另一層抽象,好的框架或程式庫,在原始碼上應該也有著適當的抽象階層,能讓開發者依需求逐層探查,而不是馬上進入深層的瑣碎細節,例如,在看asyncio.run的原始碼時,也只是進一步看到如何操作事件迴圈實例,然而看不到事件迴圈的運作或實作等細節,你只是站在事件迴圈實例這一層上,試著去理解asyncio.run做了什麼。

另一方面,我們要記得,程式庫或框架提供了一層抽象,然而它從來不是為了隱藏細節。就如《約耳趣談軟體》中〈抽象滲漏法則〉中,所談到的:「抽象可以節省我們工作的時間,然而並沒有節省我們學習的時間」。

在API文件之後,若是接著探查原始碼,同時,也就是付出學習時間的過程。如果原始碼有適當的抽象階層(其實文件上也需要如此),能讓開發者只探討必要的抽象階層,就不算是抽象滲漏。為了掌握程式庫或框架,適當地選擇、認識抽象階層是必要的。

「你是在說可以依賴在實作嗎?」不!理解原始碼中必要的抽象層,是為了更放心地信任API文件上的規範(或者釐清上頭的誤區,相信我,有時API文件不完全是正確的),開發者仍必須依賴在公開的規範,API文件上沒談到的,就算原始碼中有,就不應該依賴。

當然,會有必要介入細節之時,像是生命週期管理,這是程式庫或框架的責任,若要能讓開發者介入這類細節,應該提供掛勾(hook),並在API文件上公開規範,就文件而言,這類公開規範,會是屬於文件中更低層次的抽象階層。

透過寫作建立抽象層

其實真實世界中人的溝通,本身就是個不斷抽象的過程,不同人看到、聽到、接收到的資訊,就是在對現實世界進行抽象,然後在傳達給另一個人時,又會經過一番抽象,也因此人與人與間的資訊傳遞,往往會產生認知落差的原因。

API文件本身是層抽象,是API的寫手在理解程式庫或框架的規範、看過相關原始碼或者透過其他開發者教導之後,抽象出來的成品,因此API文件本身就會有良莠之別,另一方面,當API文件的抽象不足以說服開發者時,進一步探索其他文件或原始碼,就會是必要的。

因為,這時就是在自行建立一個抽象層,一個專屬於開發者,真正能被開發者理解的抽象層。或許不該說一層,因為就個人理解來說,理解的對象有層次,自身就會在理解上建立不同的階層。

這時,寫作就是整理階層時很好用的一個工具了,由於寫作本身就是個線性的過程,也就可以適當地安排自身理解的抽象層次,這是真正專屬於開發者,在理解程式庫、框架,甚至語言時的抽象。

抽象滲漏的層次是否適當?

「那麼,實際上沒有抽象滲漏這回事囉?」不能這麼說!先前談到,抽象是某些概念抽離的不具體特性,如果程式庫或框架在應用的情境超越了抽離時設定的情境,無論如何都會滲漏。舉個最極端的例子,若在一個具有垃圾收集器的語言中,需要在意垃圾收集器的演算法時,你也可以說這是一種滲漏了。

撇開這個極端的例子而言,若要評估抽象是否滲漏,最好的方式是分層,也就是為了進一步理解一個特性,必須深入的層次要有多少。如果老是要突破至最底層才能理解,無疑地就是很嚴重的滲漏;若是依需求不同,只需進到適當的層次就能理解,這就不會是滲漏。根本來說,「開發者要掌握底層」就是這麼一回事。

抽象分層的概念對文件或原始碼都是一樣的道理,或許軟體開發上,抽象滲漏本來就是必要的,只不過滲漏點是否在適當的層次罷了!

作者簡介


Advertisement

更多 iThome相關內容