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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者簡介


Advertisement

更多 iThome相關內容