理论上，一个系统的设计如果有多种方案，应该是很容易决定出优劣的，但是现实往往不是这样，需要考虑很多种因素。

• 参与决策的人的设计风格不同，有的喜欢Properties式的无约定扩展风格，有的喜欢超级父类式的运行时多态风格，还有的喜欢根据功能不断增加的API不断对应增加的风格，当然还有其他的一些根据三种风格的变种的风格。
• 实现系统的人的能力和背景不同，某些很好的设计对于他们来说难度较大，因为实现的人不能充分的理解设计者的意图，最终好的设计变成糟糕的实现。
• 时间约束，项目的时间很紧，某些设计方案需要做比较多的架构和框架方面的东西才能做业务方面的东西，导致前期更高级别的人看不到项目的直接而且直观的结果。
• 需求的不确定，很多设计都是根据当前和可预见的需求来设计的，但是如果需求非常的不确定，很难决定那种设计更好，不同的关键需求的变更可能导致某些关键设计的失败。
• 技术风险，某些设计存在一些技术风险，设计还没有成熟的先例，在大规模系统情况下存在不可预见的技术瓶颈。

通过几年的实际工作，也参与了规模不一的多个项目，但是项目组的开发效率一直不高，一直都在思考这个问题的症结，最近换了一个公司，由于刚刚去，也不能修改比较核心的代码，就给他们修改bug，在修改其中一个比较有共性的问题时接触了很多他们原来写的代码，发现代码中充斥着很多完全相同或者几乎完全相同的代码，最典型的就是获得数据库连接以及关闭数据库连接的代码，有的类会封装一个自己用的方法，有的就是干脆每次重复，有的更是有相关的方法但是代码的其它地方却没有用，这个现象给了我比较大的触动，现在仔细想想，其实影响一个项目组的开发效率的很大的因素就是代码共享和知识共享太缺乏了。但是代码共享和知识共享又确实是比较困难的事情，共通的功能如何使用，需要什么约束条件，能够完成什么功能等等都需要有比较完善的文档，而一旦这样的功能多起来以后你要从这些功能中找到需要的功能有时候确实是比较困难的，特别是有些功能去查是否有现成的代码所花费的时间可能比自己写一个还多。

根据我的经验，有几个地方注意一下就可以比较好的解决： 
 
共通的内容要易于使用和理解，例如定义的方法名要比较贴切。 
要写比较详细的说明文档，例如给大家发邮件或者发布到内部使用的论坛系统中。 
在公布之前经过充分的测试，否则使用的时候总是有各种问题会导致大家不敢再用共通的代码。 
对于类似的功能有其共通的代码，例如使用struts的系统有自己的系统的顶层的BaseAction，在这个BaseAction中定义系统中的子类需要实现的业务逻辑方法入口，而BaseAction要实现structs要求的execute方法，并完成所有的共通任务，例如是否登录的检查，session是否超时等 
业务功能要比较少的关心杂项共通功能，例如定义logger，获取数据库连接，关闭数据库连接，异常处理等，这些功能都可以定义在BaseAction或者是系统的顶层基类中。 
  而且通过使用共通功能也可以很大程度提高系统的质量，因为通过这些年的实践发现，很多新人由于开始不理解系统的要求，很多地方就是先抄袭别人甚至完全拷贝别人的代码，如果别人的代码是有问题的，那么在没有出问题之前是很难被自己发现的，而到了发现的时候已经积重难返了，而通过顶层类的封装，底层的类的空间就狭窄了，犯错误的可能性就小多了，因为很多系统的共通要求在顶层类中已经实现了。

拿到一个新的任务的时候我们往往马上就开始干，特别是曾经接触过的内容，只要是自己感觉可以做，往往就不管三七二十一开始写代码，现在想想很不应该，拿到新的任务，先要研究一下难度，有没有难点和可能的潜在问题，什么样的方案比较好，灵活性、通用性以及可扩展性方面，另外就是看看系统中是否已经有其它的现成的代码。
每个项目我感觉应该有一个公共的功能库，不光是减轻开发的工作量，对于程序的稳定性，可维护性也是莫大的提高，但是往往有两个问题：
 一、不愿意用别人写的代码，自己总觉得自己的代码比别人好。
 二、不知道怎么用，因为没有文档，这个确实是开发人员的一个通病，喜欢写代码不喜欢写使用文档或者说明文档。