由于最近接手了一个有关于ActiveX的产品的维护工作，使得我有机会重拾已丢下一年多的COM技术，同时也有机会重新审视技术的变迁历程，以及蕴含在其中的某些思想，这种感觉就好像回过头来看自己走过的道路。所不同的是，回首自己的人生路，成败得失一幕了然；而技术的发展虽然依然遵循优胜劣汰的法则，但优劣之间的界限好像并不那么明显，反而有些使人迷茫。比如说复用。
软件复用一直被视为改善软件工程的重要手段，人们期望通过复用以前的代码或组件，来提高生产率，改善产品的质量。软件复用一般又分为源码级复用和二进制级复用。对于源码级复用，现在已经发展出很多重要的设计范式（paradigm）从各个不同的方面提供支持。比如OO通过对数据与处理数据的函数进行封装来达到class的复用，而GP通过分离数据结构以及处理这些结构的方法与数据的类型之间的联系，来使数据结构和方法得到复用。对于二进制级的复用，目前也有非常成熟的组件模型，比如COM、CORBA等。而且，现在也有了一些非常优秀的指导软件复用的理论，如Design Patterns等。以上这些都说明，软件复用勿庸置疑是软件设计中一种非常重要的思想，我们每个人在写代码的时候都应当充分考虑我们的代码的复用性，这一直是我遵循的信条之一。但是，现在我有些迷茫了。
还是先说说我最近接手的工作吧。我接手维护的产品是一组写于数年前的ActiveX controls（代码中最早的注释可以追溯到公元1997年，看到这行注释时，我首先想到的竟然是那首叫做“我的1997”的歌曲），由于年代久远，除了产品的使用手册之外，没有任何关于代码的文档，我只能靠源码和其中零零碎碎的注释来揣摩前辈们的意图。我得承认，这些代码中虽然夹杂了许多不同的人由于各种原因而做的修改，但代码的整体结构还是很好的。
为了从最大程度上满足复用的要求，这些前辈们从ATL2.1上发展出一套自己的ActiveX control库（暂且叫做BLib吧），来负责处理control的属性、接口、事件以及消息等，这套库简化了ATL窗口编程的复杂程度，修正了当时存在于ATL2.1中的某些错误，这个库在当时应该很好用（我只是猜测，因为其中的大部分代码我还没看懂L）。基于BLib库的产品的逻辑与UI是分开的，大部分的逻辑错误并不需要改动库代码。
然而，BLib库现在维护起来却好像并不轻松（也可能是我的水平有限）。在我看来，现在它具有几个明显的不足：
1、 由于是基于早期的ATL2.1发展而来，而目前流行的编程环境（VC6或者VC.NET）都已经不再支持ATL2.1了，因此BLib库不得不自己带上ATL2.1的源码，这看起来有些落伍。同时使得基于这个库的所有产品都无法轻易地迁移到更高版本的ATL上，因此无法直接从ATL的升级中受益。（即使现在已经是ATL7.0了，我还不得不想办法去搞ATL2.1的帮助文档。）
2、 由于要尽量支持复用，BLib库几乎对每个ATL中比较重要的部分都做了扩展。由于缺乏相应的文档，这使得阅读、维护这些代码成为了一件比较艰难的事情，很多时候那些扩展代码看起来与ATL中的代码只有一些细微的差别，使人很难理解。
3、 事实上，BLib库也并没有被真正的复用过。这个库建立的初衷也许就是为了以后的产品都基于这个库构建吧。但在这组ActiveX control产品建立的过程中，微软在98年推出了ATL3.0，这一下子使得这个库显得有些落伍。而发展出这个库的前辈们或者离开了公司，或者加入了别的项目，没有人来进行迁移工作。天长日久下来，后面的项目就都没有使用BLib库了。
在阅读和维护这些代码的过程中，我不由的总在想，Joshua Kerievsky说，在设计初期过多的考虑设计模式会引起过度设计。那么，在设计时过多的考虑复用性会不会引起过度设计呢？或者说，我碰到的这种情况算不算是一种过度设计呢？在我看来，如果不是过多的考虑了复用性，对于这样一组ActiveX control，完全没有必要发展一套库来完成，只需要使用ATL本身就能够完成了。这样，向更高版本的ATL迁移就不会成为一个问题。BLib库的维护成本是很高的（我的个人感受），如果是基于它做了很多产品，那么花些成本去维护是有意义的。然而只是一套产品，这个代价未免显得有些太高了。
因此，我有些迷惑了。代码的复用一直以来被我个人认为是设计编码过程中应当着重考虑的一个方面。因此，这些前辈们在开发产品的过程中基于复用的考虑发展一套库出来也是相当合理的做法，换作是我，我也会选择写一个库作为后续产品的基石的（也许会心有余而力不足L）。但是，发展一个库出来必然增加代码的维护难度，更何况这个库还是基于另外一个经常升级的库。从一个维护者的角度来看，我却宁愿代码少一些复用性，而多一些易维护性。毕竟我更关心如何快速理解程序中的逻辑，找出错误所在。这是一对矛盾，To be or not to be，我们该如何取舍呢？我们无法确知明天会怎样，我们今天写的代码，明天是否会被用在其他的地方。那么我们该如何确定复用对于我们代码的重要性呢？Refactoring to Patterns可以减少由Design Patterns引起的过度设计，那么有没有Refactoring to Reusable之类的方法，来减少由复用引起的过度设计呢？
上面记录的是我近期的一些迷思，欢迎讨论和拍砖J
