建立自用程式庫，節省重複實作成本

當我們談及軟體開發的生產力時，其實有相當多的因素在影響著。舉凡程式人本身的素質、所使用的程式語言、應用程式框架（Application Framework）的選擇、是否具備好的開發工具（例如IDE、程式碼產生器）、對開發環境的熟悉程度、開發方法論、甚至到更無形的團隊士氣，都會影響到軟體開發的生產力。

有些因素影響生產力甚鉅，例如程式人的素質、程式語言、應用程式框架的好壞等等。好的程式人和不好的程式人，生產力相差個幾十倍也不令人意外；而像C/C++之類的程式語言，與Java這種新興程式語言相較起來，使用起來，生產力也會有數倍的差距。至於像RoR（Ruby on Rails）這樣的應用程式框架，近來更是以快速開發著稱而廣為流行。

以更少的時間達成相同功能的開發
想要提高程式開發生產力，有幾個可能的途徑：一、精要、高階的抽象表述力；二、避免犯錯或者容易找出錯誤；三、自動化規則性的動作；四、避免做重複的事；五、打字速度快。

高生產力的程式語言、應用程式框架，之所以能帶來助益，無非是因為它們往往提供了更精要且高階的表述方式，使得程式人可以用更短的程式行來描述一件相對複雜的事情。

同樣地，高生產力的程式語言及應用程式框架，也能夠避免程式人犯下一些隱晦難解的錯誤。程式人們往往過於在意用於撰寫程式碼的時間，卻忽略了耗費在解決錯誤的時間。但是，事實上，當你在程式中埋下了隱晦難解的錯誤時，往往需要付出數十倍於撰寫程式碼的時間，或甚至更多時間，才有辦法加以解決。

對於下面的這件事也許你經驗豐富：只花了些許的時間，便完成了程式碼，但卻花了極為漫長的時間，才找到一時大意所埋下的地雷。預先的錯誤防範，或者事後的加速追蹤，都對開發生產力有極大的幫助。

倘若你既選用了生產力高的程式語言及應用程式框架，也盡可能地善用程式碼產生器，那麼想要顯著提升生產力的重責大任，大概就會落到如何避免做重複的事上頭。

釐清重複使用程式碼的各種可行性
物件導向的設計方法之所以大行其道，正是因為這個方法觀察到程式碼重複運用（Code Reuse）對生產力所帶來的好處。可是，大多數的程式人因為拘泥於物件導向，一想到程式碼的重複運用，往往直接聯想到透過繼承方式取得的重複運用。

然而，大多數情況下，除非我們設計的是應用程式的框架，或者是某種特殊應用的類別庫，否則設計的類別之間並不會存在太多或太複雜的繼承階層關係。

這自然意謂著，透過繼承而得到的重用程式碼數量，不致於太多，因此不太可能透過它提升非常多生產力。

可是，當你跳脫出「用繼承取得可重複使用的程式碼」的想法後，或許會發現到，重複運用許多在開發過程中會需要的公用程式，也是提高生產力的主要來源。

我留意到一個現象：現在的程式人多半都會利用現成的程式庫來協助自己加快開發的腳步，但程式人們鮮少建立自己的程式庫。這很奇特，因為在日積月累、諸多專案的開發經驗中，總是會查覺到，有一些程式碼片段，總是會一而再、再而三的重複發生。

你的系統中所會運用到的程式碼，依據來源大致上可以區分為三類：一、應用程式所專用，必須重新開發；二、現成的程式庫；三、並非前二者，卻又很頻繁地出現在各專案中。

在你的各個專案中，倘若有那種出現得很頻繁、又不存在於現成程式庫中的程式碼，卻未加以捕捉、整理，那麼，對你來說，這些程式碼等於是在每個專案中，都必須重新一一寫過。

再短的程式碼，重新實作都需要時間
以我的經驗來說吧，時常要在表示日期的字串與表示日期的物件（例如Java的java.util.Date）之間進行轉換。雖然像java.text.SimpleDateFormat已經提供了大部分所需的功能，但實際上的需求又多過於它所能提供的。例如，我希望可以自動猜測要轉換成Data物件的格式，究竟是yyyy-MM-dd或yyyy/MM/dd或yyyyMMdd，甚至要能允許可選擇性的提供時間部分（HH:mm:ss）或是不提供時間部分（註：yyyyMMdd與HH:mm:ss，為約定成俗的一種日期與時間表示方式，例如Java與C#）。雖然，這只是一個很小的功能，但是倘若沒有捕捉到這段程式碼重複發生的特性，因而未加以整理，那麼我就會在接下來的每個專案中，反覆地重新撰寫。

又好比，利用Java開發基於Swing的應用程式，我們時常需要將視窗、對話窗之類的元件置於畫面的正中央。這也許只需要十行左右的程式碼就能完成，但是同樣的道理，如果沒有留意到它的重複性，並加以整理，仍然得在大大小小的專案裡重新加以實作。

又好比，我們時常要把一個整數值，表示成中文的數字寫法（零、一、二、……）、把一個浮點數表示成百分比的字串呈現（例如：把0.75表示成75%）、將HTML中的所有Tag都去除，只留下文字……等等。

這些程式碼因為功能小，所以現成的程式庫大多沒有涵蓋，因為這些程式庫多半著墨在較完整的主題，例如像log4j乃是針對日誌記錄的主題而設計的程式庫。對於零零散散的重複需求，很少能夠找到現成的程式庫。

雖然重新實作的程式碼看似不多，但是因為它們都是需求重複性高的程式碼，因此重複實作的次數就多，對生產力造成的傷害當然就大。而且，對生產力造成的傷害還不僅於此，因為每次程式人都得重複寫下類似的程式碼，這些重新寫過的程式碼同樣可能出錯，同樣都需要被測試甚至耗費除錯的時間。兩項時間加總起來，許多寶貴的開發時間便因此暗自流失。

彙整常用的程式碼片段，建立個人或團體的公用程式庫
因此，我想給許多程式人一個建議：開始累積自己的公用程式庫（Utility Library）。

你不用追求一次到位，立即整理出一個好用的公用程式庫，只需要在開發的過程中，逐步觀察是否發生了重複性的程式碼片段。倘若有，便利用「重構（Refactoring）」中提煉函式或提煉類別的技巧，將它們從應用程式的程式碼中萃取出來，放到你自己的公用程式庫中。

如果是在一個開發團隊中，這個公用的程式庫應該是採取團隊共用的模式，相關的議題就會更多，包括：應該要制定一個維護公用程式庫的簡單流程，例如通知那一位協調者，如何撰寫說明文件、如何測試那些即將加入程式庫的公用程式以維護品質、如何確保不會對公用程式庫的其他程式產生副作用、如何管控公用程式庫的版本，以及管理已開發、開發中的應用系統之間的組態等。

善用公用程式庫是一門積小成大、聚少成多的學問。像是許多專案累積、沉澱後的公用程式碼，它們並不是程式人單憑想像寫下「疑似」會被重複使用的程式碼，而是真正通過實戰考慮的可重用程式碼。打造自己專屬的利器，使用起來也更順手，不是嗎？

作者簡介：
王建興
清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。