最近因为项目工期紧张，实在没办法，亲自捉刀，用了下公司的另外一个"开发平台"，过程可谓艰辛，可以用披荆斩棘来形容，最后还是没有做完，只做了个半成品，就放弃了。下面我来聊聊公司的的开发平台的一些事情。
公司成立以来，我知道的，大大小小有6个平台，说平台不是非常严谨，有的根本收不上是平台，顶多是开发辅助工具而已。为行文方便，都称之为平台把。6个平台大同小异，但又各有特点和缺点，我逐个说一下把。
一个是我参与的.net版本下的一个开发平台。大约是在2003年之后，慢慢做起来的，这个平台的特点有一下几点：
1、这个平台基于 .net 技术平台，界面是winform的，后台应用该服务器基于iis。这个平台基于开源的orm实现了一套ORM，类似hibernate 的一套中间层持久化，用起来还是很方便的，大部分操作不用写sql，甚至一些复杂的查询，用起来非常爽，真的非常爽，面向对象的crud，不限现在的，sql满天飞，一改数据结构，鸡飞狗跳的!。缺点就是效率有点慢，这是orm的通病，怨不得这个平台。
2、实现了很多基本的业务控件，小如业务日期，中到组织机构数，大到业务表单，都是可以通过配置出来，很多通用的功能都内置了，通过插件的形式进行功能扩展。简单的字典编辑，真的是0代码。
3、实现了一套非常完善的、科学的权限控制，可以说无所不能，从业务实体属性级别进行权限控制。客观讲，现在还没有出其右者。缺点是偶尔失效，权限的元数据需要手工配置的多，没有和业务实体的定义统一起来；再就是定义起来稍繁琐，没有实现可繁可简，在功能性和易用性上没做好平衡。
4、还实现了一个简单的负载均衡。
5、缺乏可视化的开发界面，比如定义模型，配置界面等等。全是手工写sql进行配置，也零星写了些辅助的小工具。
6，差点忘了，实现了一个比较强悍的工作流，比现在公司用的强太多，可配置型非常强，就是界面稍显的土一些。但是比现在用的工作流，动不动要开发人员介入，要强上百倍。
可惜是采用了。net平台，很少有大型的企业应用场景（公司主要客户采用linux系列的服务器和java平台，因此没有成长起来，夭折了）。
第二个，是基于这个版本，开发了套 web版的，后来又翻译成java版，就是当时煤炭用的那个版本，甚至工作流都翻译成java的了。可惜部门业务限制，也没有发展起来，可惜了。当时的小界面做的非常好。也是有两个技术上的大拿在做，ll和cj。我没用过。
第三个，是老板主抓的一个平台，基于模型驱动MD的思想做的，比较先进，bpms部门在做，是我的一个校友带头。后来也有了界面设计器，和可视化的建模工具。基于 hibernat.net 实现了一套orm，当然慢的缺点也么有解决。是基于bs的，我用这个平台做过2个项目，做的非常好。优点是开发复杂度比较低，缺点就是，orm，性能略低，再一个，他的模型库是本地xml文件，不能多人协同开发，这个个最大的败笔，估计是决策失误，后来没有资源，来不及改了。这个平台当时的目标比较宏大，要作为产品往外买的，可惜公司内部的问题，部门没有能存活下去，也夭折了。
第四个，就是现在的pso的前身，我们和pso一块讨论，不单独说了。pso发展了几个版本，swing的，flash的，现在是gwt的。swing版本没用过，后两个版本我都带过项目，对实现原理，具体编程非常熟悉。这个平台的特点是提供了比较好的界面设计器，而且是可自开发界面ui空间，思路比较好，类似于 .net的winform界面设计器的样子。拖放操作，属性配置，基于ui的事件编程，比较好上手，提供了简陋的服务编排（权称吧），前后台通讯的协议标准，后台服务的编写标准（也就是接口标准）。缺点是太不稳定，太粗糙，版本兼容差，很难升级，只能算是个半成品，最新的版本没用过，会有改善，但是估计好不到哪里去。优点是前后台一体化编程，开发效率还是比较高的（使用比较熟练的前提下。除了问题也是很难找原因）。值得一提的是，工作流简直惨不忍睹。只实现了个空壳，乏善可陈。理念先进，可惜具体实现的太差了。
第五个，是就是我前言说的smw，起点比较高，理念也行。但是bug很多，使用起来要小心翼翼，稍不注意就会犯错，而且错了很难找原因，“最好的做法就是重新做，找错误的功夫就做完了”，这是一个5年开发经验的人给我说的。有很多小技巧，否则你完全用不了，操作和交互太晦涩难懂了。但是看的出来，作者有一定的系统架构功底，系统分层，抽象能力比较好。但是毕竟是10多年前的东西了，一直没有发展。已经被后来人用的面目全非了。开发效率非常不高。它也提供了建模工具，包括数据建模，界面建模（界面设计），界面设计采用流失布局，可用性与pso稍逊。客户定制代码的开发用js，我看了看，没有很看懂，路子和 前面说的bpms类似，但是不如 bpms封装的好。可以看出，前端的设计和后端比较起来，功底就就差一些了。这个团队开发采用前后端分离（可能是团队的开发习惯，和平台无关），效率不高。和pso相比，后台的通用的实现模式也比较晦涩，旁门左道比较多，没有采用业界比较常用的设计模式和实现模式，不容易上手。
总结一下以上的几个平台，套路差不多，数据建模（创建数据库表结构），单据建模（设计表单布局，和数据的关系），然后实现了或多或少的适用于某些特定该业务场景的固定的逻辑，然后就是菜单，权限，功能，工作流等等。
看了以上的介绍，你一定不理解，为啥一个做软件的公司20年了，还做不出一个好用的开发平台（好用的标准就是能拿出去卖，就像炎黄盈动的工作流产品，帆软的报表产品等（这两家公司发展时间比我们还短）），还是苦逼的做项目，实在不应该是作为一个“技术公司”的应有的样子。原因是什么呢？
1、缺乏顶层设计。
公司没有一个统一的规划，或者高层设计，打算要做一个平台。就是说现在的平台不是设计出来的，是在日常的项目中慢慢积累起来的，有个比较nb的开发人员，有想法，目的是解决局部的平时开发中的难题，就凭一己之力，做了个东西出来，慢慢就用开了。不是说积累不行，而是说要有意识的去做平台。这应该是公司意志，而不是个人意志。
2、缺乏持续优化的机制
开发出来了，大家也在用，但是没有成立一个组织或者强有力的组织，持续去完善他，先前的设计师地位也高了，不屑于做具体的工作，后继者能力又不行，一个是改不了，在一个改，也没有贯彻先前的优秀的设计理念。么有随着新的技术，新的设计思想，持续进化。你想想，找一群应届生来开发平台给公司几百个5年+的开发人员用，屁股想也是不对的。连设计模式，框架，事件，都没有搞清楚，更没有实际业务经验，不知道需要什么，闭门造车，肯定不能做出好用的东西。
而且，听不得批评，甚至压制对系统善意的批评和建议。一线员工人微言轻，或者能力有限，或者意识不到不好（这是最可怕的，吃着窝窝头，不觉得那吃，还以为全世界都在吃窝窝头）。
我曾经问过很多一线开着对系统使用的感想。大部分是一边抱怨一边用，无奈。为啥不反映呢？1是人微言轻，没人听，2是说反映了也没人改（没有资源改），3是没有意识到问题，4是忍气吞声惯了，“习惯就好了”这是他们的口头语。
3、开发力量分散
本来近1000人的开发队伍，应该能开发出一个很好地产品了，但是事实就是没有。这个和高层的组织有很大的关系。
公司事业部制、项目制，造成各自为战，各怀心思，都为了完成自己的任务，拿到奖金，极少有精力管公司5年之后，考虑其他部门。丛林法则，想当初，.net，bpms就是因为这个才混不下去。
做产品，做平台，一定要有顶层设计，然后有一批有思想，严谨的，高水平的业务人员，架构师，技术人员去做。差不多，马马虎虎，这种心态是做不出好项目和好产品的，可惜，上面说的“差不多思想”，占据了主力，占据了公司的思想阵地。
4、老大不当回事
老大沉迷于具体的事务，或者在商务上，或者在项目交付上，乐此不疲，没有意识到平台的重要性，差不多就行，我们能吃苦！没有看过其他优秀公司的产品，沉醉于已经取得的成绩，还以为自己的平台不错。因为他已经不具体做开发工作了，使用中的种种问题，各种不便，他体会不到，甚至被蒙蔽。
5、老大缺乏魄力和野心。
老大就狠不下心来做这个事情，瞻前顾后，怎么能做好。首先是没有这个意识，不重视，如果再没有这个魄力，过多平衡各方利益，考虑各方的感受，更做不好。
一个差得平台的负面影响很大，比如：
1，影响士气。破窗效应，破罐子破摔，差不多 等不良风气蔓延。你平台都这样，还指望我能开发出什么高质量的系统？
2，员工得不到提高。曾经与离职回归的员工，一部分原因是出去混不了，只能回来。
3，带坏了员工。比如错误的组件、事件命名，错误的概念（比如掩码，监听，事件等等比比皆是），这都是“坏味道”，误导了年轻的员工。
4，更重要的是，极大降低了开发效率，而且质量得不到保证，加大了项目的成本。
我们公司的发展，就像自然界里的植物一样，自然生长，没有园艺师管理，修剪施肥，所以说以后有所改变，很难啊。除非来个思想大变革，但是可能吗。
好在现在意识到平台的重要性的，开始统一平台（阻力还是比较大的，这反应了老大的优柔寡断），但是我感觉决心和力度还是不是非常大，平台的发展依然不容乐观，应该是没有找到正确的方法。有人的地方就有江湖，一点不假啊，做技术的也不纯粹了。
一声叹息。