?? 當我們談及軟件開發的生產力時，其實有相當多的因素在影響著。舉凡程序人本身的素質、所使用的程序語言、應用程序框架（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網絡電話都在他的涉獵范圍之內

轉載于:https://www.cnblogs.com/phcis/archive/2008/01/10/1033086.html

總結

以上是生活随笔為你收集整理的【转】建立公用程序库，提升软件开发生产力的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。