倘若一個團隊裡恰好雇用到一名最糟的程式人，那麼最好的程式人原先只需花費一週完成的工作，他很有可能要花上28週，相當於半年多的時間，這差距可說是相當驚人。因此，有著高速開發能力的程式人當然是十分地吃香。 

打字速度直接影響開發效率 
那麼，你，做為一名程式人，究竟是屬於高生產力，或者是低生產力的呢？在本文中，我將試著探討影響程式設計生產力的諸般因素。 

撰寫程式碼的速度，無疑會影響到程式設計的生產力。而影響撰寫程式碼速度的第一個要素，很少人討論，但就我個人的觀點，覺得其實還挺重要的，那就是打字的速度。 

我有個很有趣的經驗，當年我小學畢業初學程式設計時，雖然還是個連26個字母都識不完整的小朋友，但老師第一堂課，就教我們如何熟悉自己的鍵盤，如何不看著鍵盤，快速地讓雙指在鍵盤上遊走，輸入所有想輸入的字元。 

打字速度，雖然看起來是一個在程式設計領域，很少有人談論到的因素，但無疑的，卻最直接影響到產出程式碼的速度。無論一名程式人思考的速度有多快，最終還是得透過鍵盤，才能讓程式碼從人腦傳遞到電腦。 

如果你有留意，我們在撰寫程式時，有時候速度的瓶頸是在思考，有時候速度的瓶頸是在打字。我的觀察，許多生產力表現優秀的程式人，他們對吃飯的傢伙──鍵盤，都是相當的熟悉，一旦寫起程式來，雙手快速地在鍵盤上飛舞，程式碼就一行行在畫面上出現。 

這並不是說，所有生產力高的程式人，都一定得練就一番快速打字的功夫，但是，打字速度快，絕對有助於更快速地產出程式碼。尤其當你思考的速度，勝過打字的速度時，腦中浮現一堆程式碼，但卻受限於手指移動的能力，難道不會感到無奈嗎？ 

此外，這也不是在暗示只要你打字夠快，寫程式就會夠快（因為你可能思考不夠快），有太多因素在支配著程式碼生產力了。即使你能高速的產生程式碼，也不代表這些程式碼都是有品質、可供使用的程式碼呀！ 

好的整合開發環境，可強化生產力 
除了打字之外，為了要更有效加速直接產出程式碼的速度，大多數的整合開發環境（IDE）都提供了一些輔助的機制，協助程式人更快速地產出程式碼。例如，程式碼的自動補齊（Auto-Completion），會自動偵測目前你可能要輸入的類別名稱或函式名稱，自動猜想並且可以幫你補齊，如此一來，便可以減少很多需要打字的時間。 

好的整合開發環境不僅會提供這類產生程式碼的協助，同時也提供了許多在撰寫程式碼時，所會需要運用到的機制，像是跳至某類別、某函式在程式碼中定義的位置之類，都能加快程式人撰寫程式碼的速度。 

因此，是否選擇了一個好的整合開發環境、是否熟悉所選用的整合開發環境，自然成了重要的因素。有一些開發速度驚人的程式人，對於自己所用的開發環境十分熟悉，他們搞懂整合開發環境所能提供的每一項有助於加快產生程式碼的協助，並且快速地運用它們。 

這些熟悉整合開發環境的程式人，早就把各種快速鍵運用得有如自己的手足一般，完全不需要思考或反應。能將整合開發環境所提供的機制發揮到淋漓盡致，自然能夠有更好的生產力。 

熟悉多種程式語言，便可針對情境挑選生產力最佳者 
倘若，不限單一程式語言的話，那麼，從中挑選出有生產力的程式語言以及搭配的應用程式框架，也會是決定生產力的重要關鍵。 

例如，這幾年來被公認在網站開發上，具有高速開發生產力的RoR（Ruby on Rails），它的設計相當符合開發網站的需求，因此能夠提高程式開發的速度。 

想要開發得更快，使用更有生產力的程式語言，以及搭配的應用程式框架，也會是一個決定因素。好比，你的需求是在Windows平臺上開發一個視窗應用程式，你的選項有C/C++搭配MFC及C#兩種。雖然說熟悉MFC的程式人，一樣有著很好的生產力，但我想，一般來說，利用C#開發使用者介面的生產力，應該還是會勝過MFC，因為不論是語言本身，或者是程式庫，新生代的C#以及.NET平臺，終究還是針對生產力提供不錯的改善。 

有時候，同時熟悉多種程式語言，有助於提昇生產力，便是因為當要解的問題不同時，你手上可以運用的語言工具比較多，便有機會從中挑選出最適合、最有生產力的程式語言。 

倘若你熟悉的語言受限，那麼選擇不多的情況下，想要憑藉著程式語言來加分，機會就比較低了。所以，在程式設計這個圈子裡，普遍認為優秀的程式人最好是兼通多種程式語言。 

這並不是說，專精一兩種程式語言不足以成為高手，而是說，當可用的工具變多時，可以針對不同的應用情境從多種語言中挑選最適合的。當生產力對你來說是重要的因素時，便可以挑選開發生產力較好的語言。 

程式框架好比巨人的肩膀，可節省開發時間 
好的應用程式框架或程式庫對於生產力加分不少，因為好的應用程式框架，通常瞄準特定的應用領域，例如使用者操作介面、網頁處理、資料庫資料處理，抽取出該領域在開發時的共通需求，成為可滿足這些需求的設計。 

立足在這些框架或程式庫上，好比站在巨人的肩膀上，可以省去許多時間。 

因為在該應用領域中，會不斷運用到的重複部分，都被應用程式框架或程式庫給做掉了。而且它們在設計時，幾乎都會考慮到通用性，因此可以滿足大多數開發的需求。 

簡單的需求搭配複雜的程式框架，反而拉長開發時間 
但是應用程式框架或程式庫，雖然設計的目的，是為了要節省開發的時間，但是，近來觀察，許多應用程式框架有越來越複雜化的趨勢，原因當然是為了希望涵蓋更多的應用需求，但是，這麼一來，不但提高了學習曲線，複雜化的結果，往往讓程式人無法從中得到提高生產力的好處。 

反而因為所面對的事物變複雜了，需要花更多的心力，去操控應用程式框架，也更容易迷惑、更容易犯錯，開發時間有時候反而拉長了，完全沒有得到運用應用程式框架應該要有的優點。 

這其實是一個滿重要的迷思。許多程式人其實沒有搞懂自己真正的需求，只跟隨著潮流走，當大家一窩瘋地使用某個應用程式框架時，好像不用就趕不上流行，就不是正宗的王道。 

倘若你的需求單純，應該挑選複雜度適宜的應用程式框架，而不是一味地追求最完整、威力最強大的框架。這麼一來，才真的不會因為應用程式框架本身的複雜度，使得生產力的提升打了折扣。