[閱讀報告]關於軟體設計與實現的透明性與可顯性

資料名稱	Transparency: Let There Be Light
作 者	Eric S.Raymond
作者單位
出 處	The Art of UNIX Programming
閱讀時間	2008.12.20~2008.12.25
主要講述內容
這篇文章介紹了關於軟體設計的兩個重要的品質： 透明性和可顯性。作者首先用通俗的語言定義了這兩個性質，並且分別從使用者和開發人員的角度闡述了透明性和可顯性的重要。 本文用較大的篇幅分析了幾個展示透明性和可顯性的Unix 設計執行個體。這些執行個體包括了audacity 、fetchmail 、GCC 、kmail 、SNG 、Terminfo 、Freeciv 等Unix 軟體。在介紹完全部執行個體後本文嘗試從中總結經驗，在總結的同時，作者講述了他的設計方法與理念，如資料文本化、將機制與策略分離、減少抽象層的厚度、模組化編碼等。
涉及到的問題
什麼是透明性和可顯性？ 軟體設計為什麼要滿足透明性和可顯性? 為透明性和可顯性編碼的原則? 怎樣在設計時帶來透明性和可顯性?
作者的觀點
作者在文中試圖定義透明性和可顯性。作者認為透明性是一種被動品質。如果能預測到程式行為的全部或大部分情況，並能建立簡單的心理模型，這個程式就是透明的。另一方面，如果軟體系統所包含的功能是為了協助人們對軟體建立正確的“做什麼、怎樣做”的心理模型而設計， 這個軟體系統是可顯的。 定義了這兩個性質之後，文章講述了軟體設計要滿足這兩個性質的必要性。作者首先從美學的角度說明。軟體之美在於其是力量與簡潔的結合，這種結合也可以看作是一種優雅(elegance) 。從使用者的角度來看，優雅的軟體意味著簡單直接的GUI 介面，平緩的學習曲線。從軟體開發人員的角度來看，優雅的代碼意味著不僅將演算法傳達給電腦，同時也把信心和見解傳遞給閱讀代碼的人, 優雅的代碼也給軟體系統帶來穩定性和可維護性。 作者在第二節中講述為透明性和可顯性編碼的原則，具體包括八條原則： 1 ＞ 程式調用層次中最大的靜態深度一般不超過四。 2 ＞ 代碼具有強大、明顯的不變性質(invariable) ，編碼時用前置和後置斷言來實現。 3 ＞ API 的函數調用滿足正交性和緊湊性。 4 ＞ 存在一些順手可用的關鍵資料結構或全域唯一的記錄器，捕獲了系統的高層級狀態。 5 ＞ 資料結構和它們所代表的外部實體之間存在清晰的一對一映射。 6 ＞ 函數和模組簡單易懂。 7 ＞ 儘可能減少特殊情況和隱含的衝突。 8 ＞ 代碼的魔數( 意義含糊的常量) 太多，限制（如關鍵緩衝區大小）太明顯。 本文在最後幾節總結了一些面向透明性和可顯性的一些設計方法，主要包括如下幾點： 1 ＞ 不要在具體操作的代碼上疊放太多的抽象層。 2 ＞ 將資料文本化，這樣能使得資料更易讀取和維護。 3 ＞ 將資料（策略）和引擎（機制）分離出來，這個觀點主要是從Freeciv 軟體執行個體中總結得到。
自我評價
通過閱讀這篇文章，理解了軟體設計中透明性和可顯性的定義和重要性，掌握了評價軟體執行個體的基本方法。
提出的待改進和提高之處
這篇文章雖然提出了一些有價值的觀點，但部分表述有一定的局限性。 1 作者在設計時崇尚資料的文本化，但現實中並不是所有的應用都適用這一原則。比如說對實用性要求高的嵌入式應用和網路應用。 2 作者對文中選取的幾個軟體執行個體的評價不準確。比如作者推崇audacity 軟體的介面，認為其介面清晰自然。查看audacity 軟體的後，我覺得audacity 的介面布局缺欠美感，功能展示得不明確。 3 文章在總結部分提出了很多觀點，但闡述得過於零散，沒有條理。
閱讀者的觀點
經過前面一段時間的努力，今年的專案工作已經基本完成，我想結合自己今年的項目經曆，對軟體的設計和實現方法進行總結，於是我選擇閱讀了<<UNIX 編程藝術>> 書中講述軟體設計的這篇文章。 回想起今年的項目經曆，這篇文章提出的很多觀點得到我的共鳴。比如說資料文本化和策略和機制分離的軟體設計方法都在我們的項目中得以體現。在宣武項目中，我們的案例資料統一採用XML 格式以文本的方式組織儲存，給開發和維護帶來諸多便利。另外，在栗老師上次介紹的工作流程軟體中，我們正是採用了類似於文中介紹的Freeciv 執行個體採取了資料（策略）與引擎（機制）分離的方法設計，伺服器維持共用狀態而用戶端專註於GUI 表現，流程的邏輯儲存在XML 檔案中，在伺服器啟動時讀取。在我設計的資料庫模組中，也運用了將資料庫基本函數與資料商務邏輯分層的設計方法，但按本文的觀點，我的設計有不合理之處，在具體操作的代碼上疊放的抽象層太多，以至於我在映像特徵提模數塊中程式調用層次達到四層，所以我的設計在透明性方面還得繼續改進。