程式碼架構的可讀性

一般當我們在軟體開發領域談到「可讀性（readability）」這個詞彙時，我們通常指涉的是一片程式碼片段對讀者而言，是否容易閱讀及理解。它可以說是撰寫程式碼時需要考慮的重要特質。

具可讀性的程式碼有很多優點，首先，它比較容易維護及修改。很多時候，我們不敢修改一段程式碼，有部份原因是因為我們沒把握自己是真的了解它。容易理解的程式碼，讓讀者更有信心、也更有機會正確的加以修改。就算不是後續接手的維護者，而是原作者，在經過一段時日之後，面對可讀性不佳的程式碼，或許自己也都缺乏信心。

其次，具可讀性的程式碼不容易滋生程式碼的臭蟲。因為具可讀性的程式碼通常邏輯簡明清晰，不會錯綜複雜，因此程式設計者不易犯錯，自然不容易暗藏臭蟲，即使有了臭蟲的存在，在具有良好可讀性的程式碼中臭蟲通常比較容易被察覺，除錯起來也簡單多了。因此，程式碼的可讀性和開發的效率以及品質息息相關。因為，不容易犯錯的程式碼，對開發的生產力而言十分的有助益。

當然，對於想要推展「集體程式碼共有（Collective code ownership）」的開發團隊而言，團隊中程式碼的可讀性更是十分重要，因為那是程式碼想要集體共有的基礎條件。倘若程式碼片段只有特定的成員才能讀懂，那麼，豈不是將這段程式碼隔離在其他成員之外，此時，要如何談程式碼的集體共有呢？

程式碼的撰寫風格要一致、單純，並使用共通的語彙或概念
正因為程式碼的可讀性如此重要，程式設計者愈來愈重視這項特性，也時常可以看到各種討論，探討改善程式碼可讀性的方法及技巧。總的來說，有幾項基本的原則對於提高程式碼可讀性，是很有幫助的。

首先是「一致性」的原則。當我們在編寫程式碼時，程式語言的語法通常提供了很大的彈性，允許程式設計者自由揮攦，甚至展現出個人特有的風格。但正因如此，每個人的習慣及風格可能不盡相同，或是存在頗大的差異，甚至同一個程式設計者自己都沒有固定的習慣及風格。而「不一致」就是可讀性的天敵。

「不一致」代表沒有一個「吾道一以貫之」的中心思想，它使得讀者沒有辦法在既定的一致性規則下進行推演，沒有辦法在明白簡單扼要的規則之後，輕易套用在程式碼中的任何一處。這些不一致，可能發生在程式中的命名慣例、排版規則、甚至是註解的風格，都會大大影響到程式碼的可讀性。

有利於可讀性的另一個基本原則是「單純」。單純的東西不複雜，當然也不容易產生誤解、也不容易令人感到混淆，因此，不容易讓人犯錯，即使有錯也很容易看出來。有些程式設計者喜歡賣弄炫技，使用很取巧的方式來撰寫程式，使得讀者必須花上好長一段時間，才能搞懂程式碼的企圖，甚至還不見得能了解。這樣除了滿足自己或是展現個人技巧之外，對可讀性其實是會造成傷害。

最後要提的基本原則是「共通的語彙或概念」。在極限編程（eXtreme Programming）中，也提到了「比喻（metaphor）」這個實務原則，便是利用一些比喻來描述系統中的元素，藉以讓眾人更容易了解，同時可以形成統一的用語，讓大家都用同樣的方式去理解相同的概念。

如果，程式碼中運用了成員們都共同理解的語彙或概念，那麼基於這些語彙或概念所寫下的程式碼，自然而然就很容易了解。當然，「共通的語彙或概念」也意謂著這些語彙或概念，在成員間的理解是一致的。

站在架構的角度來看程式碼的可讀性

對軟體程式可讀性的討論，目前似乎大多偏重在程式碼這個層次上，就像前幾段文字所提及的，像是程式要有一致的命名慣例、程式碼中所使用的名稱要具有意義……等等。我想這是從比較微觀的觀點來看待軟體程式的可讀性。事實上，我認為程式的可讀性，還可以從更巨觀的觀點來切入。

何謂巨觀呢？你可以回想看看，當你試圖著閱讀、探索從來沒有接觸過的一整個系統的程式碼時，對你而言，首先要理解的是散布在系統中的每一片段程式碼？多半不是，因為對你而言，整個系統的大圖像及脈絡在你的腦中都尚未建立，此刻將關心的焦點直接放到程式碼片段層級（像是單一個函式或單一個類別），似乎有點言之過早、見樹不見林的感覺。

在這樣的階段中，你會想先了解什麼呢？你一定會想先了解整體的「架構」。所以，其實在此時刻影響我們的，並不是特定程式碼片段的可讀性，而是「程式架構的可讀性」。即使從微觀的觀點，每一小段程式碼分開獨立來看都有不錯的可讀性，也不意謂著從巨觀的觀點來看，整體的程式碼就很容易閱讀、很容易理解，因為其架構可讀性可能不夠理想。有優良可讀性的程式，不僅講究每個片段的容易理解，也會重視在架構層次上是否容易理解。事實上，你還是可以看到架構可讀性不好的程式碼。

「架構可讀性」這個名詞，是我自己在本文中所定義的。我從過去的經驗中得到了以上的想法，不過目前還沒有找到可用的類似名詞，因此就自己照著這個想法如此定義了。它的意思基本上是指一個系統的程式架構是否容易令閱讀者理解，就像單一程式碼片段的可讀性那樣。只不過，對程式碼片段的可讀性要求，是希望了解這段程式碼本身的作用。但是，對程式碼架構的可讀性要求，則是希望理解系統架構運作的方式，包括像是各個程式碼片段之間的關係究竟為何，以及它們是如何進行互動，以完成系統所需的各種操作情境。

當我們談到程式碼可讀性的時候，不僅應該從微觀的觀點來看程式碼片段的可讀性，也應該從巨觀的觀點來看程式碼架構的可讀性。不論是微觀或巨觀，都是可讀性的一部份，必須二者兼具才能提供足夠好的可讀性。而想要提高巨觀可讀性的基本原則也很相近，像是保持一致、單純易懂、以及共通的語彙或概念等等。

應用程式框架與程式架構可讀性的關係
現代軟體開發，時常會運用一些現成的應用程式框架，這對架構可讀性來說通常是好事。怎麼說呢？因為應用程式框架為應用程式提供了現成、既定、可重複使用的基礎建設，使得應用程式得以在此之上進行開發。它等於是定義了一個上層的架構，讓應用程式在這個大的架構之下，發展自己的部份。

像是許多Java的Web應用程式開發者會使用Struts，而Ruby的Web應用程式開發者則會使用RoR。

你可以想像，倘若你本身就是一名Struts的開發者，對你而言，想要了解另一個使用Struts開發的應用程式，起碼在最上層的架構上不會有太大的問題，因為在Struts應用程式中，它所依循的MVC設計模式，以及在此模式下的角色以及互動的方式及行為，都是你已經了解的。了解了這個應用程式框架，就理解了最上層的架構。你只要專注心思在這架構之下的次級架構即可。

如果應用程式在框架下的次級架構，也能把握提高可讀性的基本原則，而不是雜亂無章或是複雜難以理解，那麼就更能讓閱讀者在深入閱讀程式碼片段之前，先在腦中建立起系統整體的大圖像，更快理解系統究竟是如何運作的。