再短的程序代码，重新实作都需要时间

以我的经验来说吧，时常要在表示日期的字符串与表示日期的对象(例如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)」中提炼函式或提炼类别的技巧，将它们从应用程序的程序代码中萃取出来，放到你自己的公用程序库中。

如果是在一个开发团队中，这个公用的链接库应该是采取团队共享的模式，相关的议题就会更多，包括：应该要制定一个维护公用程序库的简单流程，例如通知那一位协调者，如何撰写说明文件、如何测试那些即将加入链接库的公用程序以维护质量、如何确保不会对公用程序库的其他程序产生副作用、如何管控公用程序库的版本，以及管理已开发、开发中的应用系统之间的组态等。

善用公用程序库是一门积小成大、聚少成多的学问。像是许多项目累积、沉淀后的公用程序码，它们并不是程序人单凭想象写下「疑似」会被重复使用的程序代码，而是真正通过实战考虑的可重用程序代码。打造自己专属的利器，使用起来也更顺手，不是吗?