当我们谈及软件开发的生产力时，其实有相当多的因素在影响着。举凡程序人本身的素质、所使用的程序语言、应用程序框架（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）」中提炼函式或提炼类别的技巧，将它们从应用程序的程序代码中萃取出来，放到你自己的公用程序库中。 如果是在一个开发团队中，这个公用的链接库应该是采取团队共享的模式，相关的议题就会更多，包括：应该要制定一个维护公用程序库的简单流程，例如通知那一位协调者，如何撰写说明文件、如何测试那些即将加入链接库的公用程序以维护质量、如何确保不会对公用程序库的其他程序产生副作用、如何管控公用程序库的版本，以及管理已开发、开发中的应用系统之间的组态等。 善用公用程序库是一门积小成大、聚少成多的学问。像是许多项目累积、沉淀后的公用程序码，它们并不是程序人单凭想象写下「疑似」会被重复使用的程序代码，而是真正通过实战考虑的可重用程序代码。打造自己专属的利器，使用起来也更顺手，不是吗？
想要提高程序开发生产力，有几个可能的途径：一、精要、高阶的抽象表述力；二、避免犯错或者容易找出错误；三、自动化规则性的动作；四、避免做重复的事；五、打字速度快。 高生产力的程序语言、应用程序框架，之所以能带来帮助，无非是因为它们往往提供了更精要且高阶的表述方式，使得程序人可以用更短的程序行来描述一件相对复杂的事情。 同样地，高生产力的程序语言及应用程序框架，也能够避免程序人犯下一些隐晦难解的错误。程序人们往往过于在意用于撰写程序代码的时间，却忽略了耗费在解决错误的时间。但是，事实上，当你在程序中埋下了隐晦难解的错误时，往往需要付出数十倍于撰写程序代码的时间，或甚至更多时间，才有办法加以解决。 对于下面的这件事也许你经验丰富：只花了些许的时间，便完成了程序代码，但却花了极为漫长的时间，才找到一时大意所埋下的地雷。预先的错误防范，或者事后的加速追踪，都对开发生产力有极大的帮助。 倘若你既选用了生产力高的程序语言及应用程序框架，也尽可能地善用程序代码产生器，那么想要显著提升生产力的重责大任，大概就会落到如何避免做重复的事上头。 厘清重复使用程序代码的各种可行性
面向对象的设计方法之所以大行其道，正是因为这个方法观察到程序代码重复运用（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）」中提炼函式或提炼类别的技巧，将它们从应用程序的程序代码中萃取出来，放到你自己的公用程序库中。 如果是在一个开发团队中，这个公用的链接库应该是采取团队共享的模式，相关的议题就会更多，包括：应该要制定一个维护公用程序库的简单流程，例如通知那一位协调者，如何撰写说明文件、如何测试那些即将加入链接库的公用程序以维护质量、如何确保不会对公用程序库的其他程序产生副作用、如何管控公用程序库的版本，以及管理已开发、开发中的应用系统之间的组态等。 善用公用程序库是一门积小成大、聚少成多的学问。像是许多项目累积、沉淀后的公用程序码，它们并不是程序人单凭想象写下「疑似」会被重复使用的程序代码，而是真正通过实战考虑的可重用程序代码。打造自己专属的利器，使用起来也更顺手，不是吗？