具再利用性的設計，將強化生產力

高生產力的程式人是十分受到歡迎的，因為對軟體開發而言，時間就是金錢，生產力和開發成本有密切的關係。因此，如何提高生產力，便成了程式人相當關心的一個議題。

在前文，我們提到了幾個影響到程式開發生產力的因子，從最基本的功夫──打字速度開始，到挑選好的整合開發環境、對整合開發環境的熟練程度、挑選有生產力的程式語言、合適的應用程式框架或程式庫……等，這幾項因素都對實際撰寫程式時的速度，有著深遠的影響。

善用既有程式庫，就省去重新造輪的時間
倘若你觀察那些撰寫程式速度飛快的程式人，你會發現他們通常已經累積了不少資產，而這些能夠在實際開發時，直接拿出來使用。

這些現成的「輪子」，時常就是一些日積月累的程式庫。它們多半是程式人依據過去一段時日的經驗，以及實務上可能會遭遇到的需求，逐一地磨練、萃取出來的。

由於程式人多半會持續在固定的幾個應用領域開發，而他們自己設計的程式庫，通常也就是針對這些應用領域整理出來的。具體地說，這些現成的「輪子」之所以寶貴，原因在於：一來，可能沒有其他人會為了你所遭遇到的應用領域，撰寫程式庫；二來，自己所設計的程式庫，使用起來會更為熟悉、更得心應手，撰寫速度也就能夠更快。

例如，倘若你的工作需要用到DirectShow技術，開發Windows或Windows Mobile的應用程式，雖然DirectShow已經是微軟針對多媒體應用而設計出來的一個應用程式庫，但是，在實務的開發中，程式人仍然會發現他們需要撰寫一些基於DirectShow、但更高階的程式碼，而且這些程式碼會一而再、再而三地使用到。

倘若，程式人在開發的過程中，能夠同時將這些程式碼，設計成為可以重複使用的程式庫，那麼，在日後遇到重複的需求時，直接從箱子裡拿出來，自然就有現成可以解決問題的工具了，那麼撰寫程式碼的速度便會加快許多。

程式寫得再快，都比不上直接用來得快
說實在的，相較於整合開發環境能夠提供給程式人的幫助，我相信，時時觀察會重複發生的需求、設計可重複使用的程式碼，能夠在生產力上帶來的幫助其實大得更多。

有一些厲害的高手，從來不使用整合開發環境，打字速度也不快，但開發起程式，他的速度可是一點不慢。其中的原因就在於，他們已經把會需要用到的零件都準備好了，一旦要開發新的系統，立即可以從「倉庫」裡拿出許多「零件」，省去從頭撰寫所有程式碼的力氣及時間。

這種差別是很大的，任你程式寫得再快，都比不上「不用寫」來得快。

把會重複使用到的程式碼，提取出來成為函式，似乎是每個程式人初學程式開發時就知道的事情，卻不是每個程式人都有辦法從中獲得驚人的生產力，而這中間的差距，就是優秀或平庸程式人之間的分野了。

觀察力強的程式人，會留意程式再次使用的可能性
那麼，差別究竟在那邊呢？首先，優秀的程式人會隨時隨地留意並且判斷，自己即將撰寫的程式碼，在未來是否有再次重複使用的可能性，使得他在撰寫程式時，保有程式碼的一般性，不致於寫死於眼前的應用。

觀察力和判斷力是很重要的一件事，很多程式人並不會主動關心自己目前正在撰寫的程式碼，是否在未來會有再度被拿出來用的可能性，於是，總是重複地在撰寫類似的程式碼，無數的生產力就在這裡被虛耗掉了。

只要能注意到這件事，伴隨著開發經驗的累積，所觀察到的重複需求越來越多，所寫下的可重複使用程式碼也越來越多。只要設計妥當，未來撰寫程式的速度就會越來越快。

設計能力也是決定生產力的重要關鍵
此外，設計能力也是決定生產力的重要關鍵。因為好的設計會具備「一般性」，也就是說，具設計能力的程式人所開發出來的產物，不會太過於局限，而是具有適度的彈性，能夠因應未來的變化。

優秀的程式人，並不會犯下所謂「過度設計（Over Engineering）」的錯，所謂「過度設計」是指過度擴張未來可能會應用的可能性，將程式碼設計得太有彈性，超出了可能會應用到的範圍。過度設計的缺點，是在設計程式碼時，要花費更多的時間，而且程式碼本身的複雜度又變得更高，運用起來將會更為費力（這意謂著更花時間，最後是否能節省到時間，還在未定之天）。而付出這些代價，最後卻是什麼都沒有得到──只有存在於想像、卻永遠使用不到的彈性。

優秀的程式人會拿捏其中的平衡點，考慮到近期需要的彈性，又保留未來方便擴充的可能性。等到真正的需求浮現，再逐一地利用重構的技巧，把需要的彈性添加上去。

所以優秀的程式人，會多花一點點時間，在開發應用程式的同時，整理、維護程式庫或類別庫，但又不致於因為程式庫或類別庫，耗去太多的時間。這中間的平衡點就是功力的所在。

除錯十分浪費時間，而使用既有的程式庫可強化穩定度
自己開發的程式庫和類別庫都有一個優點，就是這類的程式碼，都經歷過多個專案的實際考驗，所以相對而言，也具有一定的穩定度，比較明顯的臭蟲，也都被捕捉出來了。

寫一段全新的程式碼，花最多時間的地方，有可能不是在撰寫程式碼，而是在除錯。即使盡可能地為撰寫程式碼這個工作提升速度，但只要除錯的效率沒有改善，那麼整體的速度提升仍然有限。

這其實也帶到另一個重點，善用反複重用的程式碼，可以避免錯誤。因為解決錯誤是十分浪費時間的工作。

程式應採取容易理解的寫法，以利除錯
而即使是重頭寫過的程式碼也是一樣，要盡量採取單純、一目了然、不複雜、容易理解的寫法。有些程式人在撰寫程式時，喜歡賣弄炫技，會故意在程式碼中，運用一些語言或程式庫的冷門特性。

這些冷門特性當然有它存在的目的，但是有時候也充滿容易出錯的空間。一個使用不當，或者對這些特性不能全盤地掌握，那程式人所寫下的程式碼，就有可能產生連連不斷的「驚奇」。

著名的《Java Puzzles》一書，其中便整理了許多超乎想像的Java陷阱程式。你可以想像，這些程式的行為往往和讀者第一眼的直覺不同，一旦踏到了這樣的陷阱，得要花費多少功夫才能找到問題所在啊？這些時間換算起來都是可觀的生產力耗損呀！

撰寫程式時，盡量寫下平實、易懂、簡單、不複雜的程式碼。這樣的程式碼具有許多優點，其中之一就是不容易產生臭蟲，只要如此，就不會因為身陷不知所以然的程式陷阱中，虛耗許多光陰。

撰寫程式的速度，是由多個因子所共同影響的，我在上述內容中，試圖探討幾個影響到程式設計者生產力的因子。一般來說，高生產力的程式人，會兼顧大多數的因子，但他們通常都能巧妙地做出可重複運用的設計，並日積月累於慣用的工具箱中，以大幅地提升開發速度。