工作经验

我的业务基础平台开发之路(转)

这两年里好像从来都没有清闲过，很多时候连上论坛的时间都没有，最近才开始反思，开始彷徨，我做基础业务平台五年了，虽然不是在专注的公司来做的、，但是目标和方向不是仅仅支持本公司的业务，所以我们也认为是基础业务平台。

最近看到了一些关于业务基础平台的讨论，批评的多，赞成的少。给我印象最深刻的评价是“处理简单的事情更简单，处理复杂的事情更复杂”，但是大家大多还是认可业务基础平台是以后软件开发的方向，繁琐的传统项目开发迫使大家找一条更好的解决方案。业界一般认为业务基础平台是国内软件的首创，是对软件技术发展的重大贡献，是啊，我们除了使用美国、欧洲甚至日本的技术、框架之外，我们又做了什么呢，如果业务基础平台真的死了，无疑会打击创新软件的自信心，间接伤害到中国整个软件业，业务基础平台做好是普元们的社会责任，不仅仅是赚钱：）。

我03年来到北京，虽然换了两个单位，但是搞得都是平台。前三年在某高校的研究所，负责把原有的VB版本的平台改造成Java版本，这个VB版本的思想其实是来源于另外一个高校的研究所，并一直作为“制造执行系统”的支撑平台，有一定历史，应该跟思维加速(现在叫起步软件)差不多或者更早。这个平台有几个特点:
1， 限定了界面模式。界面必须以树为核心，点击树节点，对该节点进行维护，所有的数据维护必须依赖于这棵树。
2， 配置的思想。树的展示以及对树节点的维护页面都不用编码，都是配置出来的，配置数据存放在数据库中，配置数据和业务数据存放在同一个数据库中。
3， 数据绑定的思想。数据库中的字段直接绑定维护页面的td 上，并且定义字段的显示类型，例如录入框、下拉列表。一个维护页面只能绑定一个表，无法对多表进行操作。
4， 没有提供平台扩展接口，比如需要要做一个新的树的实现，或者对现有的树的实现进行改进，这是做不到的。当然即使现在，大部分平台也做不到：）。
5， 提供页面(在VB里是ActiveX)扩展机制。如果平台实现不了的功能，那么就须要手写页面。但是手写的页面和平台产生的页面基本不能交互。
6， 没有提供工作流的支持（制造执行系统基本也不需要，工序那部分一般来说用工作流不如用状态位控制方便）
这个平台还是跟很多主流平台和公司里面的框架还是有很大不同的。主要区别在于，它采用声明式编程的开发思路，有一个配置库，大部分主流平台都是采用产生式编程思路。主流平台基本上是工作流加表单（代码生成器生成），并且在大部分情况下表单并不好用，其实就是工作流加手写jsp。所以刚开始它没有工作流并不是坏事。
我所做的工作就是把VB版本翻译成Java 版本。应该说翻译的挺顺利。一个人两个月时间就翻译完了，那个时候刚到北京，还有爱情的滋润，工作效率比较高。翻译完之后，突然要应付一个863项目，搞一个工作流管理系统，我来北京工作之前的工作是参与工作流引擎开发的，现在也负责这一块，正好应付起来比较轻松。
工作之余，我就琢磨平台的改进，这个平台的核心就是配置库，它的设计思路就是把业务基础数据通过以树为核心的界面层维护起来，复杂的手动写页面。但是这样局限性太大了，这个平台只能局限于做“制造执行系统”，并且是特定行业的制造执行系统。
而我所在的研究所并不具备向该行业渗透的能力，而且接的项目比较杂。我准备开发一个新的版本，吸收它的一些思想，这个新版本在我一边搞工作流引擎一边搞出来的，大约也只用了三、四个多月时间，新版本有一些大的改进：
1， 配置模型不再以树为核心，而是以业务对象为核心，加强了配置的复用程度以及对业务的更好分类管理。
2， 在保留以树为核心的界面模式的基础上，增加了其它界面模式，比如在B/S 系统中常用的根据查询结果进行维护的界面模式。
3， 提供了一个类似Strusts的框架，可以在界面能满足要求而后台数据库操作不能满足要求的情况下，利用平台配置的界面，手动写Action类。
4， 提供了更为灵活的维护页面。
5， 把863的工作流以插件方式集成到平台中。
当新版本的平台写出之后，其实研究所还不知道：）。这时恰好要为一个合作单位的项目擦屁股，项目经理本来准备用VB改造后的平台，这时候我怀着忐忑不安的心情把新版本介绍给他，这个项目经理是一个非常牛的人，忙着博士后论文（并不是博士就一定牛，他是那种在博士里面出类拔萃的，对平台投入的精力并不多）。项目经理看到后应该是吃了一惊：）呵呵，对改进是十分赞许，最后拍板用了新版本，并且以后平台的开发维护都是我说了算他就不参与了：）。
这个研究所的主要是做一些国家掏钱的项目，对平台并不重视。在这个研究所后面两年多的时间里主要工作是对新版本的维护，支持项目开发。我一共支持了两个项目的开发，一个是上文说的擦屁股项目，另外一个是某汽车厂的“制造执行系统”。我在这两个项目的支持过程中也遇到了“处理简单的事情更简单，处理复杂的事情更复杂”这种情况，但是由于我的直接参与，这些问题也都迎刃而解，最终这两个项目也都获得了成功。当时我就意识到这种平台不适宜大规模推广，因为使用者不是平台的开发者，开发者也不可能支持太多的项目。
在维护版本，支持项目的同时，我陷入了新一轮的思考，这个新版本同样具有VB翻译版本的很多缺点，同样是处理简单的事情更简单，处理复杂的事情没有简单化。这个时候我在声明式编程和产生式编程两条路上徘徊过，最后还是认定了声明式编程。产生式编程太复杂，双向工程，可视化工具等等想想都头大,一个人的力量怎么都搞不定。声明式编程有一些产生式编程的无法拥有的优点：可以更好实现切面编程；引擎优化，而不影响配置数据；引擎的bug改进，意味这所有的相关bug都会改进等等。
声明式编程的核心是元模型。可能永远找到一个普适的元模型，只能做特定领域的元模型，特定领域的元模型不就是DSL了吗？我想无论什么东西，搞出来就行，我是一个工程论者，主要是基础太差：）。我选的领域可能太大了----基于数据库的开发领域。我认为既然sql 是声明式语言,html是声明式语言，为什么中间转换过程必须要用命令式语言实现？
寻找元模型的过程我大约花费了2年的时间，中间废弃了一个版本， 这个废弃的版本我已经开始用Java编码实现大半了。寻找过程中对我影响最大的是另外一个牛人canonical，我没见过他，他的博客对我影响非常大，http://canonical.blogdriver.com/canonical/catalog_2005.html。这两年中发生了好多事情，研究所一个哥们出去搞公司了，我结婚了，其实这个元模型的最后版本敲定就是在新房里，一个多月的时间，在云南，在丽江没怎么玩，全搞它了。
这个元模型的设计以及我后期引擎的实现都遵守了微内核、插件机制的原则。由于我面向的领域太过广泛，我认为零编码是不可能实现的。 为了实现的这个元模型的解析引擎，我实现了一个的O/R Mapping框架（类似iBatis），一个HMVC(层叠式MVC)框架。为什么重复发明轮子呢，因为我发现hibernate，ibatis,strusts它主要为命令式编程服务的，改造他们的成本远远超过自己写一个适合平台的实现。这个平台有一些特点：

1， 形成了声明式业务对象的概念。充分利用面向对象的思想进行配置。声明式业务对象也是整个平台的微内核。
2， 单表、多表（支持异构数据库）的增删改可以配置实现；单表、多表多条件查询也可以自动匹配查询字段。
3， 声明式事务，呵呵有点像Sping。
4， 声明式批处理（需要核心辅助插件支持）。
5， 声明式号码生成。例如学号的规则是学院+年级+6位流水号。
6， 声明式前后台校验规则，后台提供更强大的校验手段。
7， 声明式离线锁。
8， 插件式界面层结构。平台为界面提供了一套缺省实现，可以实现大部分常用界面的配置。统一的接口可以快速对界面个性化和集成比较好的界面组件，比如你可以集成fins的GT-Grid,然后在其它地方都可以配置复用，而不再写繁琐的代码。
9， 伸缩性比较好。可以把平台作为lib包或框架来使用，比如只使用它的O/R Mapping部分，号码生成部分等。
10， 可扩展性比较好。你可以利用平台提供的API为平台写业务插件，对自己的业务进行封装，提供声明式调用。
11， 声明式业务对象的服务都缺省提供Json方式的Webservice，平台提供方便的js 函数调用这些服务。（插件方式提供xml方式的WebService）。
12， 基于Parter模式的组织结构及权限验证模型，可以非常方便集成其它的组织结构，这也是平台可以嵌入式使用的原因。
13， 对Oracle ，DB2 ，MySql等提供自动分页方言支持。
14， 完善的元模型体系，元模型可以通过装饰扩展自我局部完善。
15， 异构数据库支持。两个协作的声明式业务对象可能来自不同的数据库，而对用户是透明的。
16， 对平台开发程序员开放大部分代码（除了内核），其它的如工作流引擎，界面层缺省实现，核心辅助插件，Ajax 库等全部开放。


三年时间其实很短，最新的平台还没彻底完工的时候，合同到期了。老板有背景，说继续跟着他干，把我户口解决了。我没答应，出去搞公司的哥们知道我搞了两年最新的平台，力邀我加盟他的公司， 加我后共三个股东，我答应了。这个公司没有投资，确立了以做项目养平台的发展方向，以做项目赚的钱维持平台的开发和推广。从加盟公司到现在两年多的时间了，应该是项目做的还可以，我们以极低的价格外接项目，项目额的5%-30%吧。我们也招聘了几个人，我是既做项目，又做平台维护，还要做技术支持，还要客串管理，第一年我们就接了接近200万的单子，折合到原价500万以上吧。这些项目除了有一个是甲方公司发生重大变故之外都获得了成功。
我们做的外包多是整体外包，以承包方的身份直接跟客户接触，有一个单子挺搞笑，这个单子是某部委的重点信息化项目，我们做的过程中主管部长批了n次。我们帮着承包方打下的单子，因为刚换部长，一般人也不敢折腾，我们用平台快速搭建了一个DEMO,招标会上独此一家，所以顺利中标，中标后这家公司经过“认真评估”后以承包价的15%发给了我们：（。这个项目需要集成CA，由于是全国的项目需要很USB KEY,最后发现他们购买KEY的钱竟然比我们拿到的还要多，就好比造了一个房子，有很多房间，购买房间钥匙的钱竟然比造房子的还贵，欲哭无泪啊。无论怎么说，那么多项目确实锻炼了平台，也发现了执行引擎的一些问题，但是元模型一直没有改动过。做的这些项目大部分80%都可以配置实现，剩下20%难啃的骨头，用平台提供的api也变得简单了，这是唯一让人欣慰的。
     世事难料，我加盟的第二年也就是今年，公司股东发生了矛盾，一个小公司，股东矛盾那是致命的。10.1我休息了几天，我突然发现我手上的元模型还是原来的，没有改进，平台还是没有帮助，还是没有手册，有两个兄弟公司用我们的平台，其中一个已经威胁说不用了，连帮助都没有，一个很简单的插件开发摸索了好长时间，我忙的一塌糊涂也支持不过来，最后还是我抽空用QQ支持他搞定的，没有开发文档，一页正式文档都没有：（，言传身教对本公司的员工还可以，对其它公司的就不行了。
经过最近两年的风风雨雨，我发现做项目养平台那是不现实的。小公司是很脆弱的，需要精心呵护。如果想做一件事情，最好不用采用曲线的方式，曲线往往回不到直线上来。平台还想继续做下去，也许做不下去了，在这个浮躁的社会坚持一件事情实在太难了。