(3) 没有自我重复，但重复别人。指一个功能有很好的免费开源框架或者标准可以依据，但设计开发时没有采用，而重新发明轮子，导致不能重用已有的标准或开源框架的优势。

    记得几年前参加的一个企业信息管理系统的产品开发，该产品从底层MVC框架开始开发，还开发了界面UI控件、自己的XML流程引擎实现等，然后才是在这个基础上开发该企业的信息管理系统。最后结果如何可想而知：投入产出比失衡，以失败告终。这是一个典型的"没有重复自己，但重复标准或免费成熟框架"的例子。

    在商业中的专业分工、竞争优势理论和软件架构思想有很多相通之处。一个开饭店的，不应该去种大米、白菜或养猪，而应该抓住自己的核心竞争优势，开好饭店。相同的，种菜的、养猪的，也不应该无缘无故跑去开饭店。除非他们各自都想转行，进入另外的专业化分工领域，同另外领域内公司竞争。

    在软件业中也是一样的道理，每个产品都有其核心竞争力，每个产品都应该把握住本产品的核心竞争力，并投入最大的人力物力去经营。而对于其它的标准、辅助工具、框架或产品等，应该持开放的态度，复用已有的标准、成熟框架或产品。当然，除非你想重新定位你的产品。

    这种类型的错误技术人员经常会犯，但作为产品的架构设计师，应该尽量杜绝这种错误的发生。

    (4) 开发过程中信息重复，如软件过程中用到的工具（项目管理系统、开发工具、测试计划及用例、Build工具、版本管理工具等）之间的信息重复；还有软件过程中各种角色的沟通重复，如开发人员报告进度给开发组长、开发组长又重新报告进度给项目经理等。如下图所示：

    对这一类型的自我重复，一个集成的协作平台能解决问题。基于这个协作平台，软件过程中所有角色、工具和流程都能无缝的协作，消除了信息重复和沟通重复，加快开发效率。如下图所示：所有的工具无缝集成，消除了信息重复；所有的角色都基于一个协作平台，能够实施反映产品的状态、信息、各种历史记录等，极大降低了沟通重复。

    (5) 缺乏重构导致自我重复。这一种自我重复是最幼稚且低级的重复，但在很多产品的代码和文档也大量存在。一个功能在不同模块中重复拷贝使用、对象继承和组合关系混乱、文档关系混乱等都属于这一类的问题。

    对于这一类型的自我重复，对软件进行持续重构是唯一的好方法。代码重构具体请参考《重构》这本书；至于文档重复，大家不妨把《重构》的思想应用于文档，也必有所得。