軟體元件的使用

Google時代的程式撰寫 我是透過 jserv 的網站知道這篇文章。這個問題其實一直在我腦海揮之不去，軟體元件的重複利用的可行性太低。這問題要從元件的 coding style 說起，使用別人的程式碼，最讓人頭痛的，其實是 style 的不相容，軟體系統有單一 style 才能發展出自己的特色，讓閱讀者模式可尋。然而，每個 programmer 各有自己的 style，這使的許多人寧可重寫，也不願使用現成的元件。

介面的設計

有人認為，只是拿來用而已，管他寫成什麼樣，以獨立目錄和其它 source 分開就好了。問題是，coding style 也包函介面的定義。每個 programmer 都有自己習慣的參數順序，變數取名方式。直接使用別人的 code，即使只是呼叫，也無異是讓別人的 style 混雜在自己的 style 裡。這是有潔僻 programmer 所無法忍受的，也是 code reader 最大的困難。我們大腦並不適合快速的在不同的 coding style 間轉換，每次 coding style 的切換，對大腦都是一種負擔，造成閱的中斷。我們喜歡流暢的 source code，正如我們喜歡流暢的文章。試想，一篇文章如果拆成數段，每段都由不同的人寫，你是否還能行雲流水？

重新包裝

一般的作法是重新包裝元件的介面，也就是寫一層 wrapper，呼叫要使用的元件，而 programmer 的 source 則透過 wrapper 使用該元件。這似乎是可行的。但，這隱含著重大的困難；寫個 wrapper 有時要花的功夫，不下於重新寫過。我們雖然都覺的 wrapper 是很漂亮的解答，然而卻沒人想寫 wrapper。

包裝過度

使用別人的元件，另一個問題是「包裝過度」。自從 OO 氾濫以來，已經演變到什麼東西都要包裝成 object/class。OO 原本是要解決 couple 的問題，但往往因 programmer 的不求甚解，而造成更多的 couple。最明顯的說是一堆 framework，往往要將資料以不同的 class 封裝，進而強迫使用者也要使用該 class，讓大家都和這些 class 產生 couple。如果讓多個不同來源的元件相互合作，那我們必定要寫一堆的 glue code，在這些 class 之間轉換。基於偷懶的心理，這些 code 一定散佈在四處八方。於是，一堆資料間轉來轉去，我們如何期待別人記得每一個 class 的功用!

簡單就是美

簡單的藝術 提到，簡單就是美。介面的設計也是這樣，能使用 array 的，不要自以為高超的使用 linked list。能使用 x, y 的，不要使用 vector 或 point。能使用 pointer 的，也不要俏的使用 STL 的 iterator。這些都會造成使用上的困難，很少人只使用單一來源的元件。這些俏招，只會 programmer 的工作量；不斷的轉換。

功能簡單

每個元件的功能一定得簡單，單一性。越是多功能，這樣的元件就越難使用。功能越多，表示選項越多。選項越多，表示 programmer 要花更多時間去了解，如何使用正確的參數，或選擇正確的 class 等等的。功能越雜，也代表更多相關性。這使的 programmer 必需注意到更多的相關功能，才能達到簡單的目的。例如，你只是要使用 encode 和 decode 以 MIME encoding 的資料，卻可能被迫使用一整套 parse MIME message 的元件，並傳遞許多參數，以選擇正確的編碼。

範例程式

範例程式是瞭解元件用法的最快方式，許多元件提供了一堆文件，但 programmer 卻往往有看沒有懂。往往簡單幾行範例，效果比一長篇解釋好多了。雖然我在 windows 上 coding 的機會屈指可數，但我發覺許多人在看 MSDN 的說明時，都只看範例程式。範例程式提供一個元件的外觀和使用方法等資訊，programmer 可以很快的瞭解元件的外觀，而不必直接接觸到細節。

OO 的使用

前面提到，有些人不管什麼都要包成 class。這樣看起來很精巧，但使用卻不方便。object 的目的，是將 state (data) 和 behavior 包裝成單元，收煉 source 的範圍，以方便管理和了解。但有些東西真的只是單純的 data，沒任何 behavior。而有些東西只是單純的 behavior，而沒有 state。面對這樣的情況，沒有必要硬是將 quick sort 或 serial number 包裝成一個 class。單純的 function 或是 structure，更能減少 programmer 的負擔，也更易融入各種 style。

結論

KISS (Keep It Simple and Stupid)