| 舍弃高效而取可配置性，这个话题自软件诞生就被人们一直的争论，每种选择都意味着有一定的优势，而另一方则意味着一种妥协。有时，开发人员必须编写简短的子程序，因为他根本就没有时间去编写复杂的程序，也许在计算机刚起步的年代，例如我上大学是2000--2004年之间，那时候计算机配置一条256M的内存就算是高档配置了，那个时候无论从内存使用还是CPU都是一个制约的因素，为此，很多程序为了高效不得不放弃一些灵活性。但是计算机发展到现在，特别是近一两年，硬件的性能基本是可以被忽略的（一般程序而言），所以，用现在的眼光来看待这个标题，就显得有讨论的必要性，任何一个人总要针对问题的两面性做出一个取舍，尽量满足那些往往自相矛盾的目标。而个人认为，舍弃高效而采用可配置性，是一个不错的idea，特别是基于J2EE的开发模式，特别是现在框架满天飞的Java世界，配置绝对可以占据Java编程的半边天。 很多架构师在架构项目时，都面临一个艰难的选择：高效与可配置性。几年前这也是折磨我的一大抉择，因为高效往往导致硬性代码的侵入，而选择可配置化却让软件不得不牺牲一定的性能损耗。高效意味着JVM是针对class的二进制直接运行，性能可能都小于1ms，从单纯的软件角度看问题，高效的软件的确有他的优势，然而，可配置性却意味着软件运行期间有很多不同的动态选择，这使得很多架构师考虑的天平偏移到可配置化一端倾斜。 标题中所提到的可配置化，是指的业务流程的关键点可配置化，而非传统概念的配置，例如基于SOA的bepl是基于XML文档描动态配置路由业务拼装的一种实现。还有就是一个简单的工作流引擎，也是基于XML文档话配置的一种流程描述，特别是作为ESB代替方案的 Apache-Camel 更是一种基于规则引擎的服务拼接器，包括大家熟悉的Spring IOC容器等，都是基于一定规则的配置实现。这些规则在一定程度上减少牺牲了软件运行期间的性能，但是带来的优势就是业务流程的可配置化，本人做过一些规则测试，利用spring框架的EL表达式 进行运算，平均耗时在30--60ms之间，具体看EL表达式的复制性与参与计算的java对象的复杂性。 在我看来，高效的方法意味着通常都是硬性编码的代码，无法在运行期间动态修改其运行规则。但是，软件的目的是为了实现现实生活中某种业务的模拟，业务的特性就是变化性，随着市场、时间等外界因素的作用，业务本身场场会频繁的发生变动，之前编写的代码是为了以后的复用，而不是为了实现定向固化的一种业务流程。如果，在未来的业务发展中，现有的代码通过配置的模式得到大量的复用，那么，他之前的辛苦就得到了良好的回报。该软件的未来版本可能略有变化，但是支撑软件运行的核心以及代码却得到了复用，而且对已经运行的代码是进行非侵入式的集成。在每次的产品升级，一般都是通过增加新的class以及新的规则配置实现增量式的升级，而尽可能的避免代码入侵方式的修改，每次代码合并都意味着一种痛苦。 可配置化的程序永远不会消失，随着时间的推移，他会被不同的业务流程所复用，从商业角度来看待这个问题，而是很显而易见的，这种模式可以缩短软件的TTM，从而降低其成本投资。可配置化的可以定义为产品，而硬编码的充其量也就是一个项目而已。 然而，对于一个可配置化这一目标而言，他仅仅完成了代码一半的工作，所有的应用程序都是由指令和数据构成的，投射到Java的世界就是程序都是一个个对象，程序的行为就是对象中封装的一个个方法。如何确保每个对象之间可以通过配置达到无缝集成，他们之间的参数是如何传递，如何保证现有配置的复用性以及面对未来业务配置的灵活性。这才是架构师所需要考虑去实现的一个问题。 本人打造的 legoo 内核，已经比较好的解决了上述问题，按照8/2法则，能解决80%的业务模型的框架就是一个好的框架，所以，一直坚信自己的框架会为企业带来绝对的优势。特别是面对产品研发类的公司而言，积累意味着复用，复用意味着降低成本，这种配置模式 从大处着眼就是SOA 的实现，往细节聚焦就是 本人的legoo 内核，其本质都一样，在不改变现有代码的基础上，完成业务流程的重组与代码的高度复用。 下班左腿由于风湿有点难受，下楼跑步N圈，依旧没有效果，看来要坚持了~~ 一身大汗，洗澡先，这篇文章就是在跑步的过程中酝酿的，一气呵成，冲凉去~~~~~~ |